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

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

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

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

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

Это сообщение отредактировал(а) Mechatronic - 4.6.2016, 12:44

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

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

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

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

Это сообщение отредактировал(а) Mechatronic - 4.6.2016, 21:37