Правильное применение принципа разделения интерфейса в моей диаграмме UML
Контекст: студент объектно-ориентированного программирования, изучает принципы SOLID и пытается применить их в своем школьном проекте. Создание веб-сайта, похожего на Indeed, для подачи заявок на работу с использованием формы Windows и веб-приложения. Необходимо использовать шаблон проектирования, который состоит из уровня представления, логического уровня и уровня доступа к данным. Попытка применить сегрегацию интерфейса в той части, где пользователи веб-приложения могут отправлять приложения (запросы на работу), а администратор может реагировать на эти приложения в форме Windows.
Это была моя начальная диаграмма UML:
У меня есть один класс на уровне доступа к данным для выполнения CRUD в Sql. Интерфейсы находятся на логическом уровне, а контроллеры будут использоваться на уровне представления, один для winsform, а другой для веб-приложения.
И это был отзыв моего учителя:
- AppController должен реализовывать отдельные интерфейсы.
- Фронтенд выбирает правильный интерфейс исходя из своих требований (Требования пользователя или вакансии).
- См. AppController как таковой.
- Теперь есть сложная конструкция с двумя выделенными контроллерами, которые сводят на нет преимущества разделения интерфейсов.
Поэтому я изменил его следующим образом:
И я чувствую, что это правильная причина
- У меня есть два отдельных интерфейса
- Я использую контроллеры, которые мне нужны, в зависимости от того, для winsform или веб-приложения.
Кроме того, в интерфейсе я буду использовать контроллеры, поэтому:
для веб-приложения Контроллер ApControllerForU = новый ApControllerForU (новый SendingApplicationDal());
для формы Контроллер ApControllerForV = новый ApControllerForV (новый ReactingToApplicationDal());
Так что я думаю, что мои рассуждения оправданы ... но не очень уверен. Можете ли вы сказать мне, правильно ли это?
@qwerty_so У меня есть вопрос .. Если я поместил все реализации в один контроллер, то контроллер имел бы доступ ко всем методам, и я подумал, что разделение интерфейсов связано с тем, чтобы избежать слияния нерелевантных методов. Это потому, что моя первоначальная идея состояла в том, чтобы разделить интерфейсы методов для приложения, один для winsform, а другой для веб-приложения. Я что-то пропустил? Я обновил свою диаграмму UML. Не могли бы вы взглянуть на это еще раз, пожалуйста, если вы не возражаете?
Ответы 1
Основная цель Принципа разделения интерфейсов состоит не в том, чтобы умножать интерфейсы путем их ненужного разделения; речь идет о том, чтобы избежать слияния операций интерфейса, которые не всегда актуальны и необходимы. Другими словами, речь идет о разделении интересов.
Два ваших отдельных интерфейса ISendingApplication и IReactingToApplication наследуют интерфейс IApplication. Это означает, что и SendingApplicationDal, и ReactingToApplicationDal должны реализовать все методы IApplication. Вопрос: релевантны ли GetApplication() и UpdateApplication() в обоих случаях, и более того, все ли аргументы этих методов релевантны в обоих случаях (к сожалению, мы не можем видеть)? Если ответ «нет» на любую часть вопроса означает, что вы не соответствуете требованиям интернет-провайдера.
Кстати: кажется, что ваш интерфейс бизнес-логики использует шаблон активной записи, который реализован в DAL. Этот архитектурный шаблон подходит только для более простых доменов. К сожалению, несмотря на то, что вы добавили различие между интерфейсами, вы не показываете в бизнес-логике очень различную природу между обновлением приложения в качестве заявителя и реакцией на приложение. Администратор должен отреагировать, и ему не должно быть позволено изменять/фальсифицировать другие элементы приложения. Таким образом, речь идет не только о предоставлении метода, но и об определении контракта, на который могут полагаться пользователи интерфейса. Следовательно, в своем дизайне вы одновременно усложняете дело с дублированием, но в то же время для основной операции вы упрощаете, сводя их к простому UpdateApplication(), т.е. техническому обновлению какой-то записи в БД.
@ jaco0646 Я переформулировал, чтобы устранить неоднозначность.
@Christophe Привет, как вы упомянули, методы в IApplication не имеют значения в обоих случаях. Поскольку у меня есть два интерфейса, я думаю, что в конечном итоге мне пришлось создать два Dal на уровне доступа к данным, чтобы использовать отдельные интерфейсы, как я понимаю. У меня проблемы с пониманием: теперь, если у меня есть два Дала, мне также придется создать два контроллера, что противоречит тому, что сказал мой учитель... Я обновил свою диаграмму UML, не могли бы вы взглянуть на нее еще раз? время пожалуйста? Спасибо.
@ullieiseenstupidhond12 (в качестве общего принципа для SO старайтесь в будущем избегать обновления диаграмм после предоставления ответов или, если вы это сделаете, делайте это в отдельном разделе «редактировать». Причина в том, что изменение может сделать аргументы недействительными. ответчиков и сделать его движущейся целью, которая менее полезна для других пользователей SO). Ваша обновленная диаграмма выглядит намного лучше. Основное преимущество заключается в том, что теперь у вас есть два объекта предметной области, определенные интерфейсами. Это оставляет возможность реализовать объект предметной области, используя активную запись, а также другие шаблоны DAL, не влияя на .../...
.../... бизнес-логика. Кстати, тот факт, что есть один контроллер, не обязательно плохо. Это зависит от модели архитектуры (например, в традиционном MVC есть один контроллер; в Entity-Boundary-Control есть один элемент управления для каждого варианта использования и т. д.)
Вы даже не вникли в первый пункт вашего учителя. В основном вы просто убрали цвет.