Отделение логики от отображения.
 

Здравствуйте, задумал сделать независимый класс World и класс View отвечающий за отображение его содержимого. Ко всему прочему, в целях экономии ресурсов и облегчения возможного последующего портирования на другие языки, мною было принято решение отказаться от использования AS3 событий в классе World. Все шло просто прекрасно, но я столкнулся с затруднениями пытаясь заставить класс View реагировать на происходящее в World. Содержимое World представлено объектами, хранящимися в массиве, View на основе этого массива создает для каждого объекта World DO и помещает его на сцену. Не понятно только как сделать, что бы при добавлении/удалении из массива World объектов View узнавал об этом и соответственно добавлял и удалял со сцены необходимые DO. Очень не хочется заставлять World заботиться о нуждах кого бы то ни было. Есть ли у кого нибудь соображения на этот счет?

Чем-то мне ваш метод напоминает шаблон Facade, синглтон что-ли?

Зря вы отказались от событий, было бы проще и красивее.

Вы можете сделать во view какой-нибудь setter, в который будете пихать свой массив при обновлении.
Соответственно view должен на это реагировать перерисовкой

MVC-то чем не пришелся?)))

тоже думал спросить, чем фреймверки не подошли.

Но раз человек даже от событий отказывается, то куда тут уж фреймверки :)

strangedk, подозреваю, что Wolsh говорил не фреймворке.

Странно, что вы именно EventDispatcher выбрали как осложнение для портирования на другие языки, реализация этого класса на других языках не такая уж и трудоемкая задача по сути. Ничего в нем магического вроде нет.

NSNotificationCenter
 

В принципе, если вам нужно своё решение, можете использовать самописный аналог эплового (NSNotificationCenter). Через него можно диспачить что угодно, в том числе изменение представления и модели.

Если нужно - есть моя реализация этой штуки на джаве, переделаете с минимальными изменениями.

Решил все же оставить события. Логика диспатчит, а отображение слушает. Потеря производительности - минимальная, удобство - максимальное:) Хотя, необходимость добавлять в код логики, код для отображения все равно огорчает.
Столкнулся с другой проблемой:
View помещает на сцену DO в зависимости от типа объектов в World Т.е. нужно как то отличать мяч от коробки и подгружать для каждого объекта соответствующее ему изображение. Может ли кто нибудь предложить, что нибудь кроме свойств-идентификаторов у объектов и switch в отображении?

Меня это больше удивляет.

Я когда давно делал редактор мебели еще на as2 решил сильно не заморачиваться и впихнуть фабрику вьюшек в модель, это выглядело бы в as3 так:
Спрашивается: зачем тогда вообще разделять модель и вид? - А у меня 2 вида было - один изометрический - другой - вид сверху. Чтобы логику не копипастить и в 2-х местах не обновлять.
А ведь один вид может сейчас быть - а в другой не быть - т.е. не получается на виде данные хранить (и на каком из 2-х? - они оба исчезают периодически).
Да и разобраться в логике, не обременённой видом проще.

Хотя, конечно, в классическом MVC модель ничего не должна знать о виде. Но, это практика - какой подход оптимален - тот и надо использовать, а не думать как там правильно блогеры советуют (они сами могут много об абстракции рассуждать, а строчить код, на 50% состоящий из синглтонов - рассказывать то всякое можно :) )

Если фабрику/тип объекта в логику не пихать, то альтернативой свитчу может быть карта/хеш-таблица "тип модели" - "фабрика вьюшки/тип вьюшки"
Впринципе, можно и свитчём - главное, чобы он в одном месте был, а не 10 похожих по всему коду (Если его удастся сделать одним - то в принципе получится то же самое, что и с хеш-таблицой)

P.S. Стало интересно код посмотреть - а то на словах можно такого насоветовать :)

Мне кажется PlutDem спрашивал совершенно о другом.
О том что вот у нас в Модели есть список табуреток и тумбочек с координатами.
И теперь во Вьюхе надо эти табуретки и тумбочки отобразить.
То есть, увидев в списке "табурет", надо создать экземпляр класса Табурет — Модель ведь хранит не ссылку на готовый экземпляр Табурета во Вьюхе, а только запись о нем. И как быть далее во время жизни этого табурета уже после его создания, когда Вьюха обновляется от Модели, от тех же записей, но теперь табурет уже есть, и должен быть как-то связан с записью в Модели)). Ну я так понял вопрос.

Может быть он действительно это имел в виду.

Вроде нормальный подход:
- вюхе - ссылку на модель в конструктор при создании
- вюха слушает свою модель и изменяется
- если пришло событие от модели, что надо пододвинуть вьюху модели "model123", то возможны 2 варианта:
1. вьюха сама пододвигается, слушая событие модели "надо пододвинутся"
2. более главная вьюха находит в Dictionary мелкую вьюху по модели и сама двигает вьюху.
(добавлять ссылку на вьюшку в модель нельзя - вьюшек может быть куча - перс на главной карте, на уменьшенном макете, в диалоге, например, - а модель одна)

Остальное, видимо, в мега-треде Хорошее MVC
Ну или больше кода нужно сюда, чтобы общаться по конкретике

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

А что, у Героя есть метод "съесть героя"?
Если так нравится абстракция, что Вы не можете передать герою ссылку на его собственную сущность, и он до конца игры не знает, герой он или чудовище, то может быть у такого Героя не должно быть методов "ударить мечом", а у монстра — "съесть героя"? Ведь у Сущности может быть только абстрактный метод атаковать.
А уж как именно происходит атака, заложено мультипликатором в ПредставленииГероя и ПредставленииМонстра.

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

согласен с димариком

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

Добавлено через 1 минуту
волш вообще философ

Философия в комиксах
Вложение 28304

Это ты в чем такие красивые рисуночки фигачишь? )

В гугл-документах, ныне гугл-диск :) Бесплатно и удобно.