Можно ли позволить контроллеру наследовать представление при применении шаблона MVC?

Question

Я нахожусь в процессе изучения шаблона MVC в «практике», что означает, что я пытаюсь понять, как реализовать его в любом конкретном приложении Java. Я просто стал немного умнее через другой вопрос Я только что спросил, и вот мое продолжение.

Для шаблона MVC присущ тот факт, что модель не должна знать ни о представлении, ни о контроллере. Однако и контроллер, и представление должны знать друг друга, так как контроллер, скорее всего, должен обновить представление, а представление должно отправлять действия пользователя в контроллер. Я понимаю, что обычно реализуют контроллер, используя шаблон стратегии, что означает, что контроллер является поведением представления. Независимо от того, как на это смотреть, вид и контроллер довольно переплетены.

Теперь я знаю, что нужно отдавать предпочтение композиции, а не наследованию. Однако, имеет ли смысл создавать проект, в котором контроллер наследует представление. Я в основном думаю о том, что не нужно писать много методов доступа и мутатора в представлении, а скорее определить все компоненты с защищенными ключевыми словами, чтобы подклассы могли получить к ним доступ.

Можно подумать, каким образом представление должно уведомлять контроллер, когда происходит пользовательский ввод. Моя идея состоит в том, чтобы иметь действия, соответствующие каждой кнопке в контроллере. Тогда это будет просто вопрос регистрации правильного действия (в контроллере, который является подклассом) с соответствующей кнопкой (в представлении).

Я собираюсь стереть разделение интересов? Будет ли это по-прежнему паттерном MVC или я направляюсь к чему-то совершенно другому (и того хуже)?

Все отзывы приветствуются!

Answer 1

Когда ваш контроллер расширяет представление, в смысле Java, ваш контроллер представляет собой представление "is-a".Так что можно с уверенностью сказать, что в этом случае вы нарушаете шаблон mvc.

Answer 2

Не слушай этих грязных парней. Похоже, великий план для меня.

Вот сделка.

Тот факт, что представление Controller "is-a" является полной, полной деталью, которая не важна для реализации. Пока ничто, использующее Контроллер, не использует его как Представление, тогда кого волнует иерархия классов Контроллера?

Теперь, спуская его из представления, теоретически среда разработки не сможет "защитить вас" от "случайного" использования контроллера, когда требуется представление. Это просто накладывает на вас бремя быть более осторожным.

Делает ли это ваш Контроллер более зависимым от Представления, чем если бы он имел с ним отношение "имеет"? Сорта. Это делает более трудным «поменять» представление на другое, хотя и похожее представление позже, но вы можете использовать это событие в качестве мотивации для проведения рефакторинга из отношения «есть» к «имеет».

Возможно, делая это, вы просто "ленивы", но я полагаюсь на Ларри Уолла о программистах и ​​лени.

С точки зрения моделирования, это просто не так уж важно, честно говоря, за исключением педантов. Оперативно это не имеет значения.

Answer 3

@ Ян Галински прав.Если вы посмотрите на пример и рисунок , процитированный в предыдущем вопросе, вы увидите, что Controller имеет-* View и его1009 * имеет 1011 *, а View просто имеет Model (сплошные стрелки).Controller прослушивает View, а View прослушивает Model (пунктирные стрелки).

Приложение: ВТаким образом, вы можете увидеть взаимно-однозначное соответствие между диаграммой классов и кодом.

Answer 4

Не ходите туда - это превратится в архитектуру M-VCS (Model-ViewControllerSpaghetti).

В принципе, я бы сказал, что пользовательские входы (включая кнопки и другие элементы управления) принадлежат не представлению, а контроллеру (или уровню GUI, в котором имеет- контроллер), в то время как view only отображает модель.

Было бы разумно, чтобы графический интерфейс вашего контроллера был знаком с представлением и уведомил его о том, что модель была обновлена ​​и что она должна повторно отобразить модель. Никаких аксессоров и мутаторов не требуется.

Answer 5

Нет, я не думаю, что это нормально, для меня это звучит очень плохо.это может быть полезно в некоторых ситуациях, но это точно не MVC.