|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
23.01.2013, 12:17 | #1 |
Новичок
Джуниор
Регистрация: 23.01.2013
Сообщений: 3
|
Как построить связи между объектами
Всем привет!
Для меня до сих пор загадка как правильно построить связи между объектами, т.е. логику приложения. Например, имеется архитектура MVC или подобная, понятно как строить модель/представление, их надо сделать максимально инкапсулированными, и тут нам приходят на помощь паттены построения объектов: фабрика, DI и т.д. . И так у нас построена вся инфраструктура приложения, запускается стартовый контроллер, когда нажали кнопку старт (win app) или зашли по URL - создаются объекты, вызываются методы и все ок. Дальше мы расширяем задачу: надо (допустим у нас игра и есть 4 юнита и консоль), когда третий юнит остановится вывести сообщение "третий юнит не может стоять". Понятно, что к моменту остановки в программе имеется 4 объекта юнитов и 1 консоль, и можно внести следующие изменения: 1. Напрямую из класса юнита, метода остановки, обратится к классу консоли. 2. Напрямую из класса юнита, метода остановки, обратится к классу контроллера и в нем проверить условия, и вызвать консоль. 3. В классе юнита, в методе остановки, вызвать событие, допустим unit:stop, делегировать его на контроллер, а из контроллера так же как и в п.2 4. Использовать паттены типа цепочка, наблюдатель и т.д. Пункт 4 не учитываю, так как это, по сути, повторение п.1-3. П. 1-2 захламляют код, и устанавливают сильные связи, и вообще прямые сообщения типа модель-модель, это, мне кажется, что то не то. Остается событийное программирование, но тут нужен глобальный диспетчер объектов .. все же мне кажется это неплохой вариант: модели дают всю бизнес-логику, view - отображение, а контроллеры - связи между объектами, логично что контроллеры вызываются в ответ на события, внутренние, либо внешние. Т.е. получается только один приемлемый вариант установки связей между моделями? Извиняюсь, что получилось много текста и воды, но по другому не смог. Если кто что может посоветовать - буду очень благодарен. |
23.01.2013, 12:42 | #2 |
Старожил
Регистрация: 31.05.2010
Сообщений: 13,543
|
Общая схема построения игр. Есть модель игрового пространства. Есть Класс (можно структура) юнита. В этой структуре (единственной), отражается тип юнита, его координаты, принадлежность группе и т.д.. При создании юнита, он включается в кеш юнитов.
За этой все бадягой следит супервизор, в котором заложены правила поведения юнитов, а так-же проверяется их местоположение на "карте мира", вот, пожалуй, и всё.
Пиши пьяным, редактируй трезвым.
Справочник по алгоритмам С++ Builder |
23.01.2013, 13:40 | #3 |
Старожил
Регистрация: 16.12.2011
Сообщений: 2,329
|
Юнит является полноценным независимым механизмом (объект класса).
Он действует согласно собственной бизнес-логики. И принимает решения на основании собственного внутреннего состояния. Юнит ничего не знает о внешнем мире. Далее два варианта: 1. Вызывающая сторона может проверить состояние юнита. Опросить его: Ты остановился? Если да - как то отреагировать, например вывести на дисплей "юнит остановился". 2. Мой любимый. Механизмы делают свою работу. Если они достигают некоторых состояний, то они испускают сообщение куда то в эфир. Например "я третий юнит, и я остановился". Механизм не знает о том, куда именно он испускает сообщение, и что с этим сообщением будут делать. Ему все равно. Его дело - испускать сообщения, сигнализируя о своих состояниях, и работать дальше. Пример: Код:
|
23.01.2013, 19:16 | #4 |
С++, Delphi
Форумчанин
Регистрация: 24.11.2012
Сообщений: 495
|
Если язык С, то какие там классы?) вы что?) В принципе... для скорости игры я бы посоветовал не писать на С++, ибо вес кода большой и тратный по времени... конечно... сейчас везде шейдеры. считают шейдерами... рисуют там же.... поэтому здесь уже уместно писать классы... создать юнита общий класс для всех... у которога одна программа... т.е. шейдер... для отрисовки... логику считают там же ибо 700 ядер на самой дешёвой видюхе... это вам не соцпроц.. это как говно в такт.
//---- Тем болеее если писать на С, то у вас меньше заморочек с доступностью..... то нельзя это нельзя..... правда в одну каску большую прогу... написать будет трудновато. Поскольку доступность есть externы везде... где надо. и всё... как работает одному богу известно... ибо это как провода имеют свойство путаться... Классы придуманы как мне кажеться для решения тяжеловесных задач... тем более все уходят на шейдер... там и помине нет классов.
Если помог, тут весы есть , Вам не сложно, а мне приятно.
Последний раз редактировалось Perchik71; 23.01.2013 в 19:21. |
23.01.2013, 22:56 | #5 |
Новичок
Джуниор
Регистрация: 23.01.2013
Сообщений: 3
|
Огромное спасибо за ответы.
Я че то затупил, думал что будет сложно поддерживать прямые связи, между объектами, когда у системы будет много состояний и обширная бизнес-логика. Но Smitt&Wesson, открыл глаза, что логику описывают те же классы, допустим, супервизор, в его обязанность входит слежение за юнитами и т.д. И это действительно, при поддержке оптимальной архитектуры, не дублирует, не засоряет код, и со связями все норм, короче все ок _Bers, написал, по сути, концепцию состояний, которые легко поддерживать и повышается восприятие логики, это то как я писал логику серверных взаимодействий (это метод мне тоже очень нравится), но так как она куда слабее логики, допустим игр, хотел спросить применимо ли это к большим проектам (хочу уйти в игрострой). Оказывается применимо. Спасибо всем, вроде разобрался. |
24.01.2013, 01:36 | #6 | |
Форумчанин
Регистрация: 22.12.2011
Сообщений: 378
|
Цитата:
Если в шейдерах нет классов, это не значит что их не желательно использовать. По сути игра состоит из множество объектов. Юнит - объект, карта - объект, даже банальный выстрел - это тоже объект, а объект это естественно отдельный или наследованный класс со своими свойствами. Я думаю что на С++ писать игры куда удобнее чем на С. А шейдеры, если я не ошибаюсь, занимаются графикой, а не описанием свойств объектов
Большинство хороших программистов делают свою работу не потому, что ожидают оплаты или признания, а потому что получают удовольствие от программирования.
|
|
24.01.2013, 12:56 | #7 | |
С++, Delphi
Форумчанин
Регистрация: 24.11.2012
Сообщений: 495
|
Цитата:
Если помог, тут весы есть , Вам не сложно, а мне приятно.
|
|
24.01.2013, 15:05 | #8 | |
Старожил
Регистрация: 13.07.2012
Сообщений: 6,342
|
Цитата:
|
|
24.01.2013, 15:48 | #9 | |
Старожил
Регистрация: 16.12.2011
Сообщений: 2,329
|
Цитата:
Таким образом с++ компилятор, это на самом деле транслятор на язык си, и компилятор си. Всякие изворачивания с друзьями - это последствия ущербной архитектуры. ООП очень удобен в использовании. Если конечно, уметь его готовить. |
|
24.01.2013, 16:13 | #10 | |
C++ hater
СтарожилДжуниор
Регистрация: 19.07.2009
Сообщений: 3,333
|
2_Bers
Цитата:
I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. (c)Alan Kay
My other car is cdr. Q: Whats the object-oriented way to become wealthy? A: Inheritance |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Как построить связи между объектами | andrey_rtv | Общие вопросы по программированию, компьютерный форум | 2 | 04.04.2013 18:07 |
Связь между объектами в php | dr.Chas | PHP | 5 | 04.10.2011 09:58 |
По поводу связи кнопки с объектами | Tador | Общие вопросы Delphi | 2 | 27.11.2010 20:24 |
Как посмотреть связи между таблицами в php? | Alar | WordPress и другие CMS | 2 | 15.11.2010 11:21 |
как переключаться между объектами в сцене? | lerka | Мультимедиа в Delphi | 5 | 19.03.2009 14:45 |