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

[andrey_rtv]

Всем привет!

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

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

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

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

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

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

[Smitt&Wesson]

Общая схема построения игр. Есть модель игрового пространства. Есть Класс (можно структура) юнита. В этой структуре (единственной), отражается тип юнита, его координаты, принадлежность группе и т.д.. При создании юнита, он включается в кеш юнитов.
За этой все бадягой следит супервизор, в котором заложены правила поведения юнитов, а так-же проверяется их местоположение на "карте мира", вот, пожалуй, и всё.

[_Bers]

Юнит является полноценным независимым механизмом (объект класса).

Он действует согласно собственной бизнес-логики. И принимает решения на основании собственного внутреннего состояния. Юнит ничего не знает о внешнем мире.

Далее два варианта:
1. Вызывающая сторона может проверить состояние юнита. Опросить его: Ты остановился? Если да - как то отреагировать, например вывести на дисплей "юнит остановился".

2. Мой любимый. Механизмы делают свою работу. Если они достигают некоторых состояний, то они испускают сообщение куда то в эфир. Например "я третий юнит, и я остановился".

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

Пример:

Читатель получатель_сообщений;  //получает от юнитов сообщения, и как то на них реагирует

Юниты юнит; //собственно наш робот

//механизм связи. умеет нацеливаться на любые функции, или методы
//и производить их отложенный запуск
Связь связь(получатель_сообщений, &Читатель::Если_остановка);

//Теперь, когда юнит достигнет внутреннего состояния "остановка", он проверит состояние связи. И если связь есть - испустит сигнал
юнит.Событие_остановка = связь;

//У получатель_сообщений дернется метод Читатель::Если_остановка()
//И он в свою очередь может организовать реакцию на это событие
//Например: прикажет графической системе отрисовать сообщение "робот остановился"

[Perchik71]

Если язык С, то какие там классы?) вы что?) В принципе... для скорости игры я бы посоветовал не писать на С++, ибо вес кода большой и тратный по времени... конечно... сейчас везде шейдеры. считают шейдерами... рисуют там же.... поэтому здесь уже уместно писать классы... создать юнита общий класс для всех... у которога одна программа... т.е. шейдер... для отрисовки... логику считают там же ибо 700 ядер на самой дешёвой видюхе... это вам не соцпроц.. это как говно в такт.
//----
Тем болеее если писать на С, то у вас меньше заморочек с доступностью..... то нельзя это нельзя..... правда в одну каску большую прогу... написать будет трудновато. Поскольку доступность есть externы везде... где надо. и всё... как работает одному богу известно... ибо это как провода имеют свойство путаться... Классы придуманы как мне кажеться для решения тяжеловесных задач... тем более все уходят на шейдер... там и помине нет классов.

[andrey_rtv]

Огромное спасибо за ответы.

Я че то затупил, думал что будет сложно поддерживать прямые связи, между объектами, когда у системы будет много состояний и обширная бизнес-логика.
Но Smitt&Wesson, открыл глаза, что логику описывают те же классы, допустим, супервизор, в его обязанность входит слежение за юнитами и т.д. И это действительно, при поддержке оптимальной архитектуры, не дублирует, не засоряет код, и со связями все норм, короче все ок

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

Спасибо всем, вроде разобрался.

[kineziz]

Сообщение от Perchik71

Если язык С, то какие там классы?) вы что?) В принципе... для скорости игры я бы посоветовал не писать на С++, ибо вес кода большой и тратный по времени...

и чем же он тратный то по времени?. Кстати на С++ вес исполняемого файла очень маленький по сравнению с другими языками (если без MFC)

Сообщение от Perchik71

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

Если в шейдерах нет классов, это не значит что их не желательно использовать. По сути игра состоит из множество объектов. Юнит - объект, карта - объект, даже банальный выстрел - это тоже объект, а объект это естественно отдельный или наследованный класс со своими свойствами. Я думаю что на С++ писать игры куда удобнее чем на С. А шейдеры, если я не ошибаюсь, занимаются графикой, а не описанием свойств объектов

[Perchik71]

Сообщение от kineziz

и чем же он тратный то по времени?. Кстати на С++ вес исполняемого файла очень маленький по сравнению с другими языками (если без MFC)

Если в шейдерах нет классов, это не значит что их не желательно использовать. По сути игра состоит из множество объектов. Юнит - объект, карта - объект, даже банальный выстрел - это тоже объект, а объект это естественно отдельный или наследованный класс со своими свойствами. Я думаю что на С++ писать игры куда удобнее чем на С. А шейдеры, если я не ошибаюсь, занимаются графикой, а не описанием свойств объектов

Вес С++ кажется меньшим, но на самом деле на языке С ещё меньше. Объектная модель много весит, много использует памяти, и нет обширного доступа к методам... из-за этого приходиться изворачиваться и придумывать друзей, наследников итд... Иерархия наследований весит куда не меньше... и трата по времени связи с кучей вызовов конструкторов.... Шейдеры первые были только для графики... сейчас в шейдере есть всё, что необходимо для написании логики... так же в самой последней версии Есть уже Математический шейдер... для описании просчётов матиматики помимо процесса... игрушку лишь тормозить перекачка данных с видюхи и обратно.... поэтому обычно одним шейдером рисуют всё и сразу. что бы было меньше перекачек.

[waleri]

Сообщение от Perchik71

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

Это зависит от того, что именно из С++ использовать. Если делать все тоже, что и в С, только средствами С++ то вес будет точно такой же а сделать все будет гораздо легче.

[_Bers]

Сообщение от Perchik71

Вес С++ кажется меньшим, но на самом деле на языке С ещё меньше. Объектная модель много весит, много использует памяти, и нет обширного доступа к методам... из-за этого приходиться изворачиваться и придумывать друзей, наследников итд... Иерархия наследований весит куда не меньше... и трата по времени связи с кучей вызовов конструкторов....

Объектная модель не весит ничего. Сначала исходный код будет приведет к виду c-style, а потом дело довершит компилятор си.

Таким образом с++ компилятор, это на самом деле транслятор на язык си, и компилятор си.

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

[pproger]

2_Bers

Таким образом с++ компилятор, это на самом деле транслятор на язык си, и компилятор си.

с разморозкой. так работал только CFront. у крестов свой компилятор лет 20 минимум