Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Алгоритмы > Model/View для объектов со сложным поведением.


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

Объясните, пожалуйста, как выглядит диаграмма классов в таких случаях.

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

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


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

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

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

Вообще - о чем разговор то? Если цель - написать самому игровой движок - то разумнее начинать с исследования готовых https://github.com/showcases/game-engines. Если цель - понять что такое ООП - то можно и тут рассуждать  smile

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

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)