MVC: Контролер нарушает принцип единой ответственности?

Принцип Единой Ответственности гласит, что «класс должен иметь одну причину изменения».

В паттерне MVC работа Контроллера заключается в том, чтобы быть посредником между представлением и моделью. Он предлагает интерфейс для представления отчетов о действиях, выполненных пользователем в графическом интерфейсе (например, позволяя представлению вызывать controller.specificButtonPressed()), и способен вызывать соответствующие методы в модели для манипулирования данными или вызова их операций (например, model.doSomething()) ,

Это означает, что:

• Контроллер должен знать о графическом интерфейсе, чтобы предложить View подходящий интерфейс для отчета о действиях пользователя.
• Также необходимо знать логику в модели, чтобы иметь возможность вызывать соответствующие методы в модели.

Это означает, что у этого есть две причины для изменения : изменение в GUI и изменение в логике бизнеса.

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

И если бизнес-логика в модели изменится, возможно, придется изменить контроллер, чтобы вызвать правильные методы в модели.

Поэтому у контроллера есть две возможные причины для изменения . Это нарушает SRP?

Если вы продолжите, следовательно, рассуждать о SRP, вы заметите, что «одиночная ответственность» - это на самом деле нечеткий термин. Наш человеческий мозг каким-то образом способен различать разные обязанности, а множественные обязанности можно абстрагировать в одну «общую» ответственность. Например, представьте, что в общей семье из 4 человек есть один член семьи, ответственный за приготовление завтрака. Теперь, чтобы сделать это, нужно сварить яйца и тостовый хлеб и, конечно, приготовить здоровую чашку зеленого чая (да, зеленый чай лучше). Таким образом, вы можете разбить «приготовление завтрака» на более мелкие кусочки, которые вместе абстрагируются от «приготовления завтрака». Обратите внимание, что каждая часть также является обязанностью, которая, например, может быть передана другому лицу.

Возвращаясь к MVC: если посредничество между моделью и представлением - это не одна ответственность, а две, то каков будет следующий уровень абстракции, объединяющий эти две? Если вы не можете найти ни одного, вы либо не правильно его абстрагировали, либо его нет, что означает, что вы все правильно поняли. И я чувствую, что это имеет место с контроллером, обрабатывающим представление и модель.

Если у класса есть «две возможные причины для изменения», то да, это нарушает SRP.

Контроллер, как правило, должен быть легковесным и нести единоличную ответственность за манипулирование доменом / моделью в ответ на какое-либо событие, управляемое GUI. Мы можем рассматривать каждую из этих манипуляций в основном как варианты использования или функции.

Если в GUI добавлена ​​новая кнопка, контроллер должен измениться только в том случае, если эта новая кнопка представляет какую-то новую функцию (то есть, в отличие от той же кнопки, которая существовала на экране 1, но еще не существовала на экране 2, и тогда добавлено на экран 2). Для поддержки этой новой функциональности / функции также потребуется соответствующее новое изменение в модели. Контроллер по-прежнему несет ответственность за манипулирование доменом / моделью в ответ на какое-либо событие с GUI-интерфейсом.

Если бизнес-логика в модели изменяется из-за исправляемой ошибки и требует изменения контроллера, то это особый случай (или, возможно, модель нарушает принцип «открытый-закрытый»). Если бизнес-логика в модели изменяется для поддержки какой-либо новой функциональности / функции, то это не обязательно влияет на контроллер - только если контроллеру необходимо предоставить эту функцию (что почти всегда имеет место, в противном случае зачем ее добавлять в модель предметной области, если она не будет использоваться). Таким образом, в этом случае контроллер также должен быть модифицирован, чтобы поддерживать манипулирование моделью домена новым способом в ответ на какое-либо событие, управляемое GUI.

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

Контроллер не нарушает SRP. Как вы заявляете, его обязанность заключается в посредничестве между моделями и представлением.

Это , как говорится, вопрос с вашим примером является то , что вы зафиксируете контроллер методов логики в представлении, то есть controller.specificButtonPressed. Называя методы таким образом, связывает контроллер с вашим GUI, вы не смогли должным образом абстрагировать вещи. Контроллер должен выполнять определенные действия, т . Е. controller.saveDataИли controller.retrieveEntry. Добавление новой кнопки в GUI не обязательно означает добавление нового метода в контроллер.

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

Из статьи Википедии о SRP

Мартин определяет ответственность как причину изменения и приходит к выводу, что у класса или модуля должна быть одна и только одна причина для изменения. В качестве примера рассмотрим модуль, который компилирует и печатает отчет. Такой модуль может быть изменен по двум причинам. Во-первых, содержание отчета может измениться. Во-вторых, формат отчета может измениться. Эти две вещи меняются по разным причинам; одно основное и одно косметическое. Принцип единой ответственности говорит о том, что эти два аспекта проблемы на самом деле являются двумя отдельными обязанностями и поэтому должны быть в отдельных классах или модулях. Было бы плохим проектом соединить две вещи, которые меняются по разным причинам в разное время.

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

Знание того, что объект имеет метод, доступный для вызова, не то же самое, что знание его функциональности.

Единственной обязанностью контролера является контракт, который является посредником между представлением и моделью. Представление должно отвечать только за отображение, модель должна отвечать только за бизнес-логику. Ответственность за преодоление этих двух обязанностей лежит на контролерах.

Это все хорошо, но немного отойти от научных кругов; Контроллер в MVC обычно состоит из множества меньших методов действия. Эти действия обычно соответствуют вещам, которые может сделать вещь. Если я продаю продукты, у меня, вероятно, будет ProductController. Этот контроллер будет иметь такие действия, как GetReviews, ShowSpecs, AddToCart и т. Д.

Представление имеет SRP для отображения пользовательского интерфейса, и часть этого пользовательского интерфейса включает кнопку с надписью AddToCart.

Контроллер имеет SRP, позволяющий узнать все виды и модели, участвующие в процессе.

В контроллере AddToCart Action есть определенный SRP, позволяющий знать всех, кто должен быть вовлечен при добавлении товара в корзину.

Модель продукта имеет SRP моделирования логики продукта, а модель ShoppingCart имеет SRP моделирования, как элементы сохраняются для последующей проверки. Модель пользователя имеет SRP для моделирования пользователя, который добавляет вещи в свою корзину.

Вы можете и должны повторно использовать модели, чтобы сделать свой бизнес, и эти модели должны быть связаны в какой-то момент в вашем коде. Контроллер контролирует каждый уникальный способ, которым происходит соединение.

Контроллеры на самом деле несут только одну ответственность: изменяют состояние приложений на основе пользовательского ввода.

Контроллер может посылать команды на модель для обновления состояния модели (например, редактирование документа). Он также может отправлять команды в связанный с ним вид для изменения представления модели (например, путем прокрутки документа).

_{source: wikipedia}

Если вместо этого у вас есть «контроллеры» в стиле Rails (которые манипулируют активными экземплярами записей и тупыми шаблонами) , то, конечно, нарушается SRP.

С другой стороны, приложения в стиле Rails изначально не являются MVC.