Модераторы: maxim1000
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Model/View для объектов со сложным поведением. 
:(
    Опции темы
Mechatronic
Дата 4.6.2016, 10:39 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 73
Регистрация: 28.3.2010

Репутация: нет
Всего: нет



Здравствуйте, уважаемые знатоки smile
Пытаюсь изучать ООП и у меня появился вопрос: как взаимодействуют Модель и Представление в случае, когда элемент модели - объект с иерархической машиной состояния (конечным автоматом)?
Например, игра жанра RPG вроде Diablo II : юнит, должно быть, имеет состояния вроде БИТЬ, ИДТИ, БЕЖАТЬ. В свое время, состояние бить, наверное, имеет вложенный конечный автомат с состояниями вроде РАЗМАХ, УДАР. Если конкретно в диабле такого нет, то точно есть игры, когда во время размаха характеристики юнита, например, уязвимость, меняются. И тут не понятно вот что: следуя идеологии ООП, и основной и вложенный конечные автоматы должны быть скрыты (инкапсулированы). Как же тогда Представление знает, что и когда отрисовывать, особенно, когда юнит замахнулся, когда вернул меч на исходную?

Объясните, пожалуйста, как выглядит диаграмма классов в таких случаях.
PM MAIL   Вверх
ksnk
Дата 4.6.2016, 12:03 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


прохожий
****


Профиль
Группа: Комодератор
Сообщений: 6810
Регистрация: 13.4.2007
Где: СПб

Репутация: 7
Всего: 383



Цитата(Mechatronic @  4.6.2016,  10:39 Найти цитируемый пост)
 следуя идеологии ООП, и основной и вложенный конечные автоматы должны быть скрыты (инкапсулированы).

View, очевидно, получает от модели ВСЮ необходимую для отрисовки информацию, но и только. Методы и свойства, управляющие поведением модели вьюшке не нужны. 
Например, если используется 3D моделирование - view обязана получить от модели координаты основных реперных точек персонажа (голова, руки, ноги, торс, оружие), построить по ним массив полигонов, навесить на полигоны нужные текстуры в зависимости от состояния персонажа и отдать все это добро на рендер. Если фигурки маленькие - второй раз полностью перестраивать полигональный массив не обязательно, достаточно его немножко сдвинуть...
То есть каждый конкретный view знает, что его моделью должен быть персонаж такого-то класса и знает, какие свойства этого персонажа нужны для отрисовки. Обычно, это фиксируется как интерфейс.




--------------------
Человеку свойственно ошибаться, программисту свойственно ошибаться профессионально ! user posted image
PM MAIL WWW Skype   Вверх
Mechatronic
Дата 4.6.2016, 12:37 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 73
Регистрация: 28.3.2010

Репутация: нет
Всего: нет



ksnk, спасибо за ответ!
Вероятно, я еще не достаточно проникся духом ООП smile 
Ведь если этот абстрактный интерфейс будет доступен всем, в крупной команде может возникнуть соблазн кому-то из разработчиков других модулей (кроме юнита и его представления) привязаться к информации о состояниях и подсостояниях юнита,что приведет к невозможности безболезненно поменять  набор состояний, изменив только юнита и его представление. Или такие случаи только code review должны контроллироваться?

Или в таком случае используется множественное наследование, чтобы один интерфейс был доступен игровым объектам - Модели, другой Представлению?

Это сообщение отредактировал(а) Mechatronic - 4.6.2016, 12:44
PM MAIL   Вверх
ksnk
Дата 4.6.2016, 18:12 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


прохожий
****


Профиль
Группа: Комодератор
Сообщений: 6810
Регистрация: 13.4.2007
Где: СПб

Репутация: 7
Всего: 383



Интерфейс для общения вьюшки с моделью и интерфейс внутриигрового взаимодействия моделей друг с другом разный. Просто по тому, что цели разные.

Вообще - о чем разговор то? Если цель - написать самому игровой движок - то разумнее начинать с исследования готовых Game Engines. Если цель - понять что такое ООП - то можно и тут рассуждать  smile

Надеюсь, это не MVC паттерн обсуждается?


--------------------
Человеку свойственно ошибаться, программисту свойственно ошибаться профессионально ! user posted image
PM MAIL WWW Skype   Вверх
Mechatronic
Дата 4.6.2016, 19:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 73
Регистрация: 28.3.2010

Репутация: нет
Всего: нет



ksnk , цели просто написать игру ради игры нет.
Изучаю ООП и, так как имею довольно много свободного времени, правда пишу игры.
Смотрел примеры разработки игр на стандартных движках, по которым есть какие-то статьи, и то, что попадалось, весьма не интересно с точки зрения ООП. Самостоятельно изучить код самого движка без пояснений мне, пожалуй, пока не под силу. Надо начинать с чего-то меньшего. Сейчас вот этот вопрос заинтересовал smile
Паттерн MVC, как и другие паттерны, на сколько понимаю, имеет в первую очередь академическое значение и цели его непременно повторить в чистом виде не должно быть.
Вообще мне кажется, что здесь более подходит что-то вроде сигналов и слотов, или сообщений. Но не знаю, как бы это выглядело smile

Это сообщение отредактировал(а) Mechatronic - 4.6.2016, 21:37
PM MAIL   Вверх
Google
  Дата 18.9.2019, 01:48 (ссылка)  





  Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Алгоритмы"

maxim1000

Форум "Алгоритмы" предназначен для обсуждения вопросов, связанных только с алгоритмами и структурами данных, без привязки к конкретному языку программирования и/или программному продукту.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, maxim1000.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Алгоритмы | Следующая тема »


 




[ Время генерации скрипта: 0.0608 ]   [ Использовано запросов: 20 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.