Хорошее MVC

[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. Хотя как вариант можно сделать отдельную триаду для хинтов. Триада эта будет на том же уровне что и триады башен с врагами. Т.е. в подчинении контроллера уровня. И тогда получится что контроллер башни получает от вьюхи башни "На_Меня_навели_мышкой", чешет затылок, ибо не знает что с этим делать, и диспатчит дальше. Контроллер уровня получает это событие, дергает контроллер хинтов "слышь чувак, а покажи как мне хинт для вот этой башенки" и все довольны.

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

[Dukobpa3]

Сообщение от Kidd002

То что ты хочешь сделать - это не простейший пример.

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

Сообщение от Kidd002

По поводу описания:
Первое что бросается в глаза это то, что у тебя модель имеет какую-то декоративную функцию.

Ну для меня модель - это сугубо база данных.
Контроллер - AI, калькулятор. Вью - морда, а модель - БД. Для того чтобы узнать в каком месте рисоваться - вьюха спрашивает координаты у модели. Для того чтобы получить операнды для расчетов логики - контроллер спрашивает данные у модели.
Исходя из этого модель не имеет публичных методов (в том числе и протектед) а имеет только пачку геттеров-сеттеров. Контроллер видит и то и то, а вью только геттеры. Плюс в каждом сеттере висит dispathEvent("changed param #xxx") - который слышат все желающие, и все кто от этого зависят - подстраиваются. Например контролер поменял координаты башни, модель отмаячилась, а вьюха услышала об этом и перерисовалась.

Сообщение от Kidd002

Зачем контроллеру хранить модель у себя? Пусть он поместит ее в модель уровня.

Принципиальной разницы не вижу. Ссылка на модель все-равно имеется. Если я помещу модель в модель уровня, то будет дублирование в некоторых моментах привносящее удобство, возможно.

Сообщение от Kidd002

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

Я просто упустил эту ссылку дабы не усложнять схему. Но да, ссылка есть, как минимум вью должна слушать события модели, а так же иметь доступ к геттерам модели.

Сообщение от Kidd002

Далее: вьюшки могут создавать не только контроллеры. Можно сделать так, чтобы вьюшка уровня слушала свою модель на предмет добавления/удаления моделей башен и сама добавляла/удаляла себе соответствующую вьюшку.

А вот это уже интересно, хотя как по мне - вносит некую путаницу в четкую систему, в которой контроллер решает всё. Хотя в пользу производительности наверное стоит на это идти в некоторых случаях.

Сообщение от Kidd002

На второй диаграмме ты зачем-то дублируешь параметры moveable и size. Но ведь раз и контроллер, и представление имеют ссылки на модель, то они всегда могут получить эти параметры из нее.

Просто копипаста из первого варианта схемы. На параметры не обращайте внимания. Всё что там нужно было увидеть, это квадратики и наследование между класса "Mxx", "Vxx", "Cxx".

Сообщение от Kidd002

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

Видимо да. А когда она будет нужна, в таком случае? Можно пример?

Сообщение от Kidd002

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

Хм. наверное таки да. Я упустил триаду окна.
будет наверное так в итоге:
- Триада окна
-- триада уровня
-- триада интерфейса
-- триада доп-элементов(возможно и без нее)

Сообщение от Kidd002

Так пусть моделью хинта будет модель башни.

Это кстати да. Я так же упустил что можно клонировать нужные модели, или же вообще передавать существующие ссылки.

Спасибо за ответы.

Добавлено через 49 минут
помедитировал на "типовую схемку из википедии".

- Контролер содержит в себе модель и вью.
- вью содержит в себе модель.
- контроллер слушает вью.
- вью слушает модель.

т.е. касательно башни это будет выглядеть примерно так:
- V: "контроллер, Враг на горизонте"
- C: "вьюха, взять на прицел, заряжааай!!!"
- V: "Заряжаю"
- V: "Контроллер, Заряжено!"
- C: "Вьха, Огонь! Модель, у нас минус снаряд."

Вторая ситуация:
- V: "Ахренеть, нас враги атакуют"
- C: "Модель, делай минус 10 хп
- M: "Сделано, осталось 90%
- V: "Поняла, рисую анимацию потерпания от ударов".
......
- V: "Контроллер, они до сих пор атакауют"
- C: "Модель, делай минус 10 хп
- M: "Сделано, осталось 60%
- V: "Поняла, рисую анимацию пожара".
......
- V: "Контроллер, а они еще атакауют"
- C: "Модель, делай минус 10 хп
- M: "А хрен вам, овердамадж получили. Нету у нас больше хп"
- V: "Поняла, взрываемся. Контроллер, слышь, чувак, взорвались мы".
- C: "Товарищ Майор, мы взорвались"
- ParentC: "МодельУровня, делай минус башню. ВьюУровня - убери мусор"

//****************
Пральна я понимаю? Просто охота уже разобраться чтоб сразу и навсегда. Потому могу флудить глупыми вопросами.

[terbooter]

А почему у вас вьюха определяет что ее бъют?

Добавлено через 10 минут
Применительно к вашему примеру игры жанра TD, я бы построил архитектуру так:
Есть модель (не один класс, а пакет), в которой все происходит, что должно происходить на экране,
только виртуально. То есть обновляются координаты врагов и наносится урон башням.
А вьюха (тоже не один класс =)) просто обновляет визуальное представление соответственно текущему состоянию модели.

Контроллеры вижу тут примерно такие:
- Юзер, что-то кликнул (строим башню, выходим в меню, пауза и тд)
- Обновление всей модели на единицу времени

И еще,

Контролер содержит в себе модель и вью

Не совсем верно говорить "содержит", тк это подразумевает агрегацию,
а у тут более общий случай - композиция.

[Psycho Tiger]

Видимо я зря писал статьи про эмвэцэ.

[terbooter]

Psycho Tiger, нет не зря. Стиль подхвачен верно =)

"А хрен вам, овердамадж получили. Нету у нас больше хп"