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

Всем привет!

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

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

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

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

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

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

0

Необязательно событием, можно и через интерфейсный класс. С точки зрения юнита это примерно так
Базовый класс Interface имеет только то что нужно Unit'у который не знает консоль это или что другое. А сама консоль может напр наследовать Interface и реализовывать печать и др

1

Вот тут есть простое описание MVC и MVP с примером. Может поможет.

0

А вам не кажется, что это не очень практично писать внешнюю логику по отношению к объекту в его методе, т.е. можно сделать так:

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

0

Сообщение от andrey_rtv Т.е. получается теперь метод unit::stop выполняет помимо своих основных функций еще и связывающие (внешние) функции, мне кажется это быстро приведет к запутыванию логики программы, нет?

Здесь можно отталкиваться от того "кто решает". Напр если "остановиться или нет" решается в методе unit::stop, то оттуда и надо уведомлять остальных. И какой-то способ аккуратно уведомить должен быть (сигнал, событие, интерфейс).

Можно навесить контроллер, тогда unit::stop возвращает bool, а контроллер уже решает. Ну это определяется резонами полезности контроллера, просто так его заводить нет оснований.

1

Теперь проясняется: в любом случаи надо из метода уведомлять систему о том что метод совершен. Это можно делать по-разному: событиями, через интерфейс ..
Я так понимаю, лучше делать, чтобы метод напрямую никаких команд не отдавал: либо события, либо интерфейс через DI, либо еще что то

0