Еще один пост об ответственности MVC, кто должен знать что?

Question

Думаю, карточная игра ...

Компьютер атакует человека с помощью карты.В ответ игрок перемещает карту в виде, чтобы побить ее.

В этом сценарии, пожалуйста, подтвердите, что:

(1) Это нормально, что View знает,где на экране «область приземления», не спрашивая своего контроллера

(2) Это нормально для View, чтобы знать, где находится карта «защитника» на экране, не спрашивая своего контроллера

Если представление знает о том, кто является как атакующим, так и защитником, (3) нормально ли для вида определить, может ли атакующий победить защитника?

Если этоне в порядке, (4) это нормально для вида для класса другой, чем контроллер для этой информации (например, класс Utils), или это всегда должен быть контроллер?

(5) Было бы лучше вместо этого послать метод делегата на контроллер, указывающий, что "карта атакующего приземлилась на карту защитника", и ожидать логического значения, будет ли атака успешной?

Answer 1

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

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

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

Еще один хороший источник проектной интуиции - тестирование и симуляция. Если вы хотите запустить некоторые автоматические тесты или игровые симуляции, вы должны отделить игровой код от ввода и вывода внутри модели. Когда логика распространяется на весь MVC, тестирование и симуляция игры причиняют боль и напоминают вам, что что-то не так.