Как построить связи между объектами

[andrey_rtv]

Всем привет!

Для меня до сих пор загадка как правильно построить связи между объектами, т.е. логику приложения.

Например, имеется архитектура MVC или подобная, понятно как строить модель/представление, их надо сделать максимально инкапсулированными, и тут нам приходят на помощь паттены построения объектов: фабрика, DI и т.д. .
И так у нас построена вся инфраструктура приложения, запускается стартовый контроллер, когда нажали кнопку старт (win app) или зашли по URL - создаются объекты, вызываются методы и все ок.

Дальше мы расширяем задачу: надо (допустим у нас игра и есть 4 юнита и консоль), когда третий юнит остановится вывести сообщение "третий юнит не может стоять". Понятно, что к моменту остановки в программе имеется 4 объекта юнитов и 1 консоль, и можно внести следующие изменения:

1. Напрямую из класса юнита, метода остановки, обратится к классу консоли.
2. Напрямую из класса юнита, метода остановки, обратится к классу контроллера и в нем проверить условия, и вызвать консоль.
3. В классе юнита, в методе остановки, вызвать событие, допустим unit:stop, делегировать его на контроллер, а из контроллера так же как и в п.2
4. Использовать паттены типа цепочка, наблюдатель и т.д.

Пункт 4 не учитываю, так как это, по сути, повторение п.1-3. П. 1-2 захламляют код, и устанавливают сильные связи, и вообще прямые сообщения типа модель-модель, это, мне кажется, что то не то. Остается событийное программирование, но тут нужен глобальный диспетчер объектов .. все же мне кажется это неплохой вариант: модели дают всю бизнес-логику, view - отображение, а контроллеры - связи между объектами, логично что контроллеры вызываются в ответ на события, внутренние, либо внешние.
Т.е. получается только один приемлемый вариант установки связей между моделями?

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

[_Bers]

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

Если попроще: классы ничего не знают о существовании друг о друга.

Таким образом, компонент можно запросто выдернуть из архитектуры, и разрабатывать/тестировать отдельно в сферическом вакууме.

Для компонентов критично не зависеть друг от друга. Но при этом, им нужно как то взаимодействовать.

Например: Модель, и её возможные представления ничего друг о друге не знают, но каким то образом должны уметь обмениваться друг с другом сообщениями.

Достигается это множеством различных способов, суть идеи которой: программирование в терминах сообщений. Иногда это ещё называют "событийно-управляемой моделью", или "машиной сигнального состояния".

Суть простая:

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

Улавливают сообщение подписчики. Например, графические представления модели.
Они ничего не знают о самой модели, и откуда пришло сообщение.

Они просто тупо и бездумно реагируют на сообщение. Например, получив сообщение "перерисовать экран", графическое представление тупо перерисует экран.

Сообщение может содержать внутри себя любые нужные данные, которые могут потребоваться для корректной обработки сообщения

Связи между компонентами пробрасываются в головном модуле в точке создания самих компонентов.

Если заинтересовало, то для языка с++ я могу с выдержакми из кода обрисовать самую простейшую машину сигнального состояния, и продемонстрировать её в действии.

[pu4koff]

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