Хорошее MVC

[Psycho Tiger]

Сообщение от Котяра

Не, это не о том..
Pop Pull - система оповещения - берём данные самостоятельно.
Push - посылаем вместе с событием.
вот тут на примере java

А, всё, понял. Пример даже излишен, объяснения хватает заглаза ) Спасибо.
Только вот:

Представление может запросить у модели (POP-операция) недостающие в событии данные.

Всё таки pop или pull?

[dimarik]

Ошибся. Правильно pull. Спасибо что поправили.

[cleptoman]

ребят, пытаюсь повернуть мозги в сторону MVC, накидал кое-какой примерчик.
чего хотел - сделать возможность на ходу менять вьюшки деталей робота без особого вреда для здоровья (setter/getter). наказякал по этому случаю класс Robot.
вопрос - насколько тут все криво?

сорсы
пощупать

[Kidd002]

cleptoman:
1. На мой взгляд стоит класс Robot сделать вьюшкой-наследником Sprite, а управление с изменением модели выделить из Main (WASD) и Robot(мышка О_о) в отдельный класс-контроллер. А то у вас получается что Robot выполняет функции и представления, и контроллера.

2. Не уверен что параметр moving в TracksModel - настолько важная информация, чтобы хранить ее в модели.

3. Ну и SPEED лучше хранить в модели (RobotModel или TracksModel)

[cleptoman]

спасибо, буду дальше репу морщить.

[terbooter]

Назрел такой вопрос.
Кто создает контроллеры?

Рутовый класс создает главный контроллер, который создает модель (у меня модель создается полностью) и вьюшку (отдельные элементы у меня создаются по необходимости)
Модель не имеет ссылок ни на контроллеры ни на вьюшку, только диспатчит сигналы
Вьюшка получает ссылку на модель и строится по паттерну компановщик.

Инстанцировать контроллер во вьюшке нельзя, тк 1) контроллер нужно инициализовать (передать ссылки на необходимые сабжекты), 2) неправильный расход ресурсов.

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

Вопрос. Где и как создавать контроллеры?

[Psycho Tiger]

Кто создает контроллеры?

Контроллеры.

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

Вполне нормально )

Модель не имеет ссылок ни на контроллеры ни на вьюшку, только диспатчит сигналы

Аха.

Вьюшка получает ссылку на модель и строится по паттерну компановщик.

Необязательно. Вьюшка строится по паттерну Composite только из за того, что так устроен ФП (компоновщик = Composite? Я перевод плохо знаю )), а так MVC по бОльшему счету привязан только к обсерверу.

Инстанцировать контроллер во вьюшке нельзя, тк 1) контроллер нужно инициализовать (передать ссылки на необходимые сабжекты), 2) неправильный расход ресурсов.

Вьюшка - отображает. У неё едва мозгов на это хватает, куда ей контроллеры? )

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

У вьюшки только одна ссылка - на модель.

Вопрос. Где и как создавать контроллеры?

В контроллерах. Контроллер создаёт модель и вьюшку. А может создать ещё один контроллер, который тоже создаст и модель, и вьюшку. Чаще всего он же передаёт младшему контроллеру ссылку на себя - чтобы тот мог подёргать у него некоторые методы)

[Dukobpa3]

Наконец-то осилил... Нафлудили мама не горюй

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

1. Есть главнй класс приложения.
2. Он создает главный контроллер себя отдает этому контроллеру ссылкой в качестве контейнера вьюх
3. Главный контроллер делает главную вьюху и пихает ее в этот контейнер
4. Главный контроллер делает главную модель (главная модель по сути хранит в себе текущий стейт и знает какое сейчас окно открыто + игровая доп-инфа по типу - сколько уровней пройдено, какой уровень следующий и т.п.)
//********************
после этих действий можно считать что мы стартонули.

Далее
0. У главной модели есть какой-то стейт по-умолчанию (майн-меню к примеру)
1. Главный контроллер глядит что у нас там в модели за стейт, в зависимости от этого создает триаду нужного экрана (майн меню, игровой экран, хайскоры, etc). Вьюху от этой триады засовывает в подчинение главной вьюхе, сам же подписывается на контроллер окна.
2. Вьюха этого окна диспатчит события на действия пользователя, события эти получает и обрабатывает контроллер окна.
3. Как только контроллер окна получает от вьюхи событие ченж_стейт - он диспатчит его дальше.
4. Ченж_стейт от контроллера окна получает главный контроллер. В ответ на это событие он зашибает эту триаду окна и создает другие (например были в главном меню и перешли в окно хайскоров, зашибли майнменю, и создали триаду хайскоров)
//*******************
Так, собственно с логикой Главного контроллера вроде разобрались. Он у нас такой типа крутой, по мелочам не разменивается и решает только глобальные вопросы (в данном примере только ченж_стейт)

Если я тут нигде не протупил - то поидее всё понятно, если же протупил то поправьте. А вопросы у меня дальше.

А теперь собственно самое интересное.
Мы заходим в игровой экран. А тут всё интересно. Возьмем по минимуму:
Делаем тавердефенс. Три вида башен. Пять видов врагов. Три уровня. Всё.

1. После того как главный контроллер получает событие смены стейта на игровой экран он убивает текущий экран и создает игровой (он в момент смены стейта уже знает какой уровень надо открыть, заранее запрашивая себе "правильную модель" с сервера или из файла или откуда там надо.)
2. Получает он данные из этого некого места, пихает их в свежесозданную модель. Прикручивает к ней ее персональный контроллер. Создает по этой модели вьюху и пихает эту вьюху в главную вьюху.
(получается с такой структурой задачей основного класса является только стартонуть это всё а потом быть контейнером для главной вьюхи. Главная вьюха является родительской для всех остальных.)

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

Но в определенный момент у нас начинают появляться на уровне враги. Мы начинаем строить башни. Начинается рубилово-мочилово.
А вот здесь я в ступоре (хотя хз, сейчас напишу как я понимаю, а вы поправите, если бред)

1. По клику на "Создать башню №1" - вьюха уровня диспатчит событие "Создать башню"
2. Ее слышит контроллер уровня.
3. В ответ он создает триаду новой инстанции башни. Вьюху кидает внутрь вьюхи уровня. Модель хранит у себя. Контроллеру башни позволяет заниматься логикой башни(ну к примеру в контроллере башни всякие там таймеры и тригеры типа раз в 1 сек перезарядка, а если враг ближе чем 50 пкс - то стрелять)
3.1. ну и дальше башня живет своей жизнью.
3.2. Контроллеру уровня на башню пофигу пока она(либо ее модель, если обнаружит что хп==0; либо вьюха, если юзер тыкнет в кнопку "под снос") не задиспатчит что-то типа "Меня поламали".
3.3. Но на всякий случай контроллер уровня башню слушает, потому что может быть получено какое-то событие типа "на меня навели мышкой" при этом контроллер уровня должен отобразить над башенкой окошко с доп-инфой (или этот функционал висит на контроллере + вью башни? Если так то схема получается следующая - вьюха понимает что на нее навели мышью, никуда ничего не диспатчит и сама на себе выводит окошко инфы.)
4. когда контроллер уровня получает от башни заветное "Меня поламали" - он сносит триаду этой башни. Если надо, вносит в какой-то реестр разбитых башен - т.е. в модель уровня. Ну малоли, хайскоры от этого будут зависеть или еще чего.

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

//**********************
Вот примерно так я себе это вижу.

А теперь вопорсы:
1. Что-то мне подсказывает что я слишком наворотил со вьюхами. В чем роль этого контейнера вьюх? А то у меня получилось что этот контейнер вьюх держит в себе только одну вьюху - главную. Тут короче где-то дублирование. Или я суть главной вьюхи не уловил, или же суть главного класса.
2. Ну и вот это всплывающее окошко - кто его показать должен? Вьюха башни или вьюха уровня? Насколько я понимаю то вьюха башни это какой-то спрайт или Мувик с анимацией самой башни. Стоит себе, привязана к координатам. Ну а чтоб это окошко выглядело так как охота чтоб оно выглядело - то надо его показывать в дисплейОбъекте уровня (ну чтоб за мышкой двигалось и в таком духе).
2.1. Хотя как вариант можно сделать отдельную триаду для хинтов. Триада эта будет на том же уровне что и триады башен с врагами. Т.е. в подчинении контроллера уровня. И тогда получится что контроллер башни получает от вьюхи башни "На_Меня_навели_мышкой", чешет затылок, ибо не знает что с этим делать, и диспатчит дальше. Контроллер уровня получает это событие, дергает контроллер хинтов "слышь чувак, а покажи как мне хинт для вот этой башенки" и все довольны.

//**********************

Короче моск пухнет уже, жду ответов Спасибо)

Добавлено через 30 минут
Перечитал еще раз.

У меня тут видимо слегка путаница с общением между родительским контроллером и детьми.

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

[Dukobpa3]

Да)) в довершение ко всему меня интересует наследование.
Простейший пример. Есть какой-то шаблонный клас юнита. От него наследуются все остальные юниты. Если делать "Как обычно" - то получится что-то вроде:


А если делать чтоб всё по правильно-мвцшному, то видимо что-то примерно такое?:

Ну не без того что к примеру каких-то две модели у нас окажутся идентичными, то получится "сэкономить" на классах (хотя тут уже впору будет задуматься, а стоило ли разбивать на разные классы вместо того чтобы сделать одну триаду "юнит", а в нем просто unit.type = (1 || 2 || 3) ).

Я прав насчет второй диаграммы?

З.Ы. Пунктир - "наследует"; Стрелка с ромбиком - "Содержит в себе".

[Kidd002]

То что ты хочешь сделать - это не простейший пример. Нужно будет много раз переделывать чтобы реализовать все эффективно. Но если есть время и желание - то ОК.
По поводу описания:
Первое что бросается в глаза это то, что у тебя модель имеет какую-то декоративную функцию.
Я придерживаюсь этой схемы:

В ответ он создает триаду новой инстанции башни. Вьюху кидает внутрь вьюхи уровня. Модель хранит у себя.

Зачем контроллеру хранить модель у себя? Пусть он поместит ее в модель уровня.
Затем на диаграммах показано что вьюшки не имеют ссылки на модель. Да, можно заставить модель и представление общаться через контроллер, но здесь пусть лучше вьюшки знают что они отображают. Тогда если модель изменится - вьюшка сразу об этом узнает и обновится.
Далее: вьюшки могут создавать не только контроллеры. Можно сделать так, чтобы вьюшка уровня слушала свою модель на предмет добавления/удаления моделей башен и сама добавляла/удаляла себе соответствующую вьюшку. Контроллер уровня может поступать так же с контроллерами башен.
На второй диаграмме ты зачем-то дублируешь параметры moveable и size. Но ведь раз и контроллер, и представление имеют ссылки на модель, то они всегда могут получить эти параметры из нее.
По вопросам:

1. Что-то мне подсказывает что я слишком наворотил со вьюхами. В чем роль этого контейнера вьюх? А то у меня получилось что этот контейнер вьюх держит в себе только одну вьюху - главную. Тут короче где-то дублирование. Или я суть главной вьюхи не уловил, или же суть главного класса.

В твоем случае главная вьюха действительно не нужна. Пусть ее роль выполняет главный класс.

2. Ну и вот это всплывающее окошко - кто его показать должен? Вьюха башни или вьюха уровня? Насколько я понимаю то вьюха башни это какой-то спрайт или Мувик с анимацией самой башни. Стоит себе, привязана к координатам. Ну а чтоб это окошко выглядело так как охота чтоб оно выглядело - то надо его показывать в дисплейОбъекте уровня (ну чтоб за мышкой двигалось и в таком духе).

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

2.1. Хотя как вариант можно сделать отдельную триаду для хинтов. Триада эта будет на том же уровне что и триады башен с врагами. Т.е. в подчинении контроллера уровня. И тогда получится что контроллер башни получает от вьюхи башни "На_Меня_навели_мышкой", чешет затылок, ибо не знает что с этим делать, и диспатчит дальше. Контроллер уровня получает это событие, дергает контроллер хинтов "слышь чувак, а покажи как мне хинт для вот этой башенки" и все довольны.

Зачем делать триаду для хинтов? Например хинт отображает информацию о башне. У башни есть модель, в которой она полностью описана. Так пусть моделью хинта будет модель башни.
Контроллер интерфейса (контроллер хинтов или сразу вьюшка интерфейса) получает событие от какой-нибудь вьюшки "на меня навели", смотрит какая у этой вьюшки модель (если она вообще есть), создает соответствующий хинт, дает ему модель этой вьюшки и засовывает хинт в вьюшку интерфейса. Как-то так.