Хорошее MVC

[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, нет не зря. Стиль подхвачен верно =)

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

[Dukobpa3]

Стиль не подхвачен, стиль в оригинале, так что попрошу

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

Ок тогда вопрос. Кто это определяет?

Хотя вьюха жеж не понимает что ее бьют, она просто видит что враг близко, она ж тупая. Сиськи большие, а размер моска обратно пропорционален размеру сисек.

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

//**********************
Путаница опять Получается в таком случае лучше не плодить кучу контролеров на каждую башню и каждого врага, а попытаться обойтись одним контролером уровня. А там он уже будет глядеть: "враг1 на расстоянии выстрела башни1. Отдать башне1 команду стрелять". А башни и враги будут просто суб-вьюхами одной большой вьюхи уровня. Модели же башен и врагов будут просто суб-моделями модели уровня(ну типа в модели уровня где-то массив башен, и массив врагов.)

[Psycho Tiger]

Контроллер вертит моделями и определяет, были ли столкновения или нет. Заносит в модели инфу, если было столкновение.

[Dukobpa3]

Походу вкурил.

У меня были шоры на тему того что триада должна быть триадой.
Ну а теперь Вывод таков: надо не бояться делать к примеру один контроллер на пачку вьюх и пачку моделей.
И в то же время одна вьюха может быть целой триадой.

Как-то так. Вроде теперь всё ясно. Спасибо. (ну если я со своими выводами ошибся, то готов продолжить дискуссию)

[Psycho Tiger]

Ага, верно. Ровно как и вьюха может сосать 3-4 модели, так и один контроллер может отдавать приказы 3-4 вьюхам, так и контроллер может слушать 3-4 вьюхи, так и контроллер может менять 3-4 вьюхи.

И в то же время одна вьюха может быть целой триадой.

Триадой я бы её не назвал. Просто "компонент" для триады.

[Dukobpa3]

Просто "компонент" для триады.

Хз. Попытался возразить да передумал. Тут чтоб дальше продолжать предметный разговор нужно уже конкретно архитектуру приложения рисовать. А это не один час работы.

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

Оценка расстояния это ведь логика, потому этому действию место в контроллере. Башне ведь проще прошерстить 9 клеток (3х3) и сделать свой маленький массив из, к примеру, 3-х мобов в области своей видимости, нежели контролеру уровня каждый кадр шерстить всё поле и делать перерасстановку сил из 10-и башен и 40-а врагов.
//********************

Короче суть ясна. А дальше уже под каждое конкретное приложение своя архитектура нужна.
//********************
А если так глобально, то мне импонирует данная система) Куда удобнее работать с 10-ю классами по 50 строк каждый чем с одним классом на 500 строк

[cr0w312]

Привет всем, тему не осилил(прочитал все, но в башке - каша), поэтому спрашиваю, контроллер(предположим игры) создает контроллер игрока, уровня и врага. Контроллер игрока в свою очередь создает модель игрока и вьюшку игрока, с уровнем и врагом - также, дальше что? модели ни про свои ни про чужие вьюшки не знают, расчет движения игрока/врага происходит в контроллере игры? Как устроить проверку столкновений? Или я путаю теплое с мягким?
ЗЫ. Код приводить не надо, тезисно.