Как часто вы используете обсерверы, синглтоны и прочую глобальную муть в проектах
 

Я в крупных использую.
Сейчас на одном маленьком попробовал без этого. Остался доволен. Но это в проекте с парой десятков классов не считая внешних фреймворков.

В чем-то посерьезнее я думаю довольно-таки сложно наладить коммуникации.

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

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

Поделитесь своим опытом и соображением на эти темы.

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

Практически не использую. Разве что какой нибудь логгер. Изредка EventBus из as3commons и Lang оттуда же.

Вот сейчас использую в проекте основанном на Gaia. И то не синглтон, а мувик который приспособил под это дело. Это такой костылище! Но иначе контролировать все пэйджи нельзя. :( Уродская система. Совершенно её не вкурил. Заказчик, просто, настаивает на решении именно на платформе Gaia...

@Котяра, а можешь поделиться идеями насчет самой структуры?

Я тут вижу три варианта:
1. контроллер общается с дочерним (скорее внучатым, ибо дочерний можно сеттерами или функциями напрямую дергать)
2. Контроллер общается с родительским контроллером(или дедушкой)
3. Общение с одноуровневым.

Как это реализовано?

Добавлено через 1 минуту
Гайя насколько я знаю сделана под флешИДЕ ? Тогда да, грабля, неудобно. Но я такие случаи не рассматривал, я даже баннеры в ФД писал:)

Как же сейчас все это гладко и красиво сделано в Tide (от GraniteDS). Я уже так привык, что гляда на все свои старые телодвижения, содрагаюсь. Правда, это не чистый флеш, а флекс, но вроде при желании можно приспособить (да и исходники есть).
Удобно, что осваивать его и серверный Спринг начал примерно параллельно, поэтому принципы DI (IoC) понимал и на клиенте, и на сервере.

Возможно, сорри за оффтоп, но это близко к вопросу ТС о синглтонах - фактически Injection - одна из реализаций, только завуалированная красиво и кодом поддерживать не надо - фреймворк сам берет это на себя.

Ну ДИ это одна из реализаций "глобальной мути" когда всё везде доступно и пофигу на иерархию. Так что не оффтоп.

Не знаю как раньше, но сейчас проект создается параллельно FlashIDE+FD или FlashIDE+FB. Но её главное неудобство не в этом. В ней объекты-страницы являются настолько автономными, что по сути представляют
собой не отдельные объекты, а отдельные программы общающиеся через крайне ограниченный интерфейс скрытый где-то в недрах фреймворка. Ну и на фига?! Спрашивается. Для любителей "в шкафу и на лыжах"?
Может я чего-то в ней не до понял (всего неделю с ней работаю), или, просто, в этом конкретном проекте она нужна как собаке пятая нога, но жутко бесит... :(

EventDispatcher - это Observer. Display List - это Composite. Очевидно, что использую.
Или речь про не нативные?

Я вот тоже очень удивился увидев вопрос про Observer.

Я думаю не про нативные. Даже не знаю, чем EventDispatcher похож на Observer.

Он не похож... это он и есть. Аналогия проста:
registerObserver - addEventListener
unregisterObserver - removeEventListener
notifyObservers - dispatchEvent
---
Так что реализация Observer-а во flash смысла не имеет. Он уже есть.

Обсервер все таки более глобален, если верить вики. Если сделать синглтон(или статиком) от ЕвентДиспатчера, накидать в него инфы, о которой он будет рассказыать и на него подписываться отовсюду, то да соглашусь евентдиспатчер станет обсервером. Хотя я в паттернах не очень.

Нет, нет и еще раз нет. При чем здесь синглтон? С какой стати вы смешиваете эти шаблоны?
Я даже вам по схемке раскидаю. По той что в вики:

Observable - EventDispatcher
Observer - Function

Соответственно ConcreteObserverable это конкретный класс реализующий EventDispatcher, а Observer это конкретный метод вызываемый в качестве обработчика. EventDispatcher это просто одна из возможных реализаций шаблона Observer.

А Вы читал пример на AS3, который в той самой "вики"? Там круть!
Если экземпляра нет - то конструктор выкидывает исключение. То есть получить экземляр, ну хоть убейся, не получится. Так что лучше забить на wiki и читать форум =)

Ндааааа... ForeverAloneton

Там вообще-то стандартный синглтон.

Речь идет конечно про ненативные. ЕвентДиспатчер даже с бабблингом передает только по дисплейлисту, А как например заставить общаться между собой контроллеры на разных уровнях, через диспатчи во вьюхах? Не всегда удобно. Если без вьюх то на ивенты получится подписаться только родителю на дитя. Чтобы это обойти пишутся разного рода обсерверы.

Я же говорю в шаблонах слаб. По вики-примеру на АС3 я и сделал умозаключение (отсюда и синглтон). Причем не ради спора, а чтобы разобраться самому. Просто я думал что Обсервер это какой-то всегда глобальный хранитель данных, который рассказывает всем наблюдателям об их изменении.

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


:о)) Не заметил.

Ну здесь бабушка надвое сказала. :о)

ЕвентДиспатчер как раз и есть одна из реализаций обсервера, только это абсолютно не сферический обсервер в вакууме, а очень даже специфический заточенный под исплей лист.

В массе своей обсервер понимается именно как что-то глобальное с синглтоном.

Например сделать EventBus. Все контроллеры получат экземпляр EventDispatcher и будут гонять события через него. На любой уровень. Баблинг без DisplayObject'ов тоже реализуем.

Ну как я понял никто не мешает сделать синглтон от ЕвентДиспатчера и получить ConcreteObserverable

Контроль количества экземпляров можно сделать и без синглтонов. Синглтон просто один из способов.

FileReference - DisplayObject?
LoaderInfo - DisplayObject?
URLLoader - DisplayObject?

Причем тут дисплей лист?

это что? Всунуть в базовый класс контроллера какой-то статик дисплейОбжект и им диспатчить и на него подписываться?

Бабблинг?

Хоть вики, хоть форум - ко всему нужно относиться критично. Но форум явно в приоритете.

Не обязательно. Его может раздавать и главный контроллер при создании дочернего, либо инжектор добавит при регистрации, если используется IoC, либо... Короче, способов много.
Причем тут баблинг, к вашему утверждению? Где вы видели обязательную реализацию баблинга у обсервера?

Баблинг не баблинг, но я не согласен что EventDispatcher

По критике? :о)

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

Тогда можно быстро найти ответ как в вики. ;о)

Тема вообще началась с вопроса а не утверждения. Утверждение только в том что диспатчер в базовой реализации ас3 не всегда удобен, так как все его плюшки становятся доступными только для дисплей листа. Без дисплей листа мы уже теряем как минимум тот же бабблинг. О том что диспатчер не является обсервером я ни разу не сказал, сказал только то что его реализация довольно-таки специфична.

Но мне кажется чем использовать такой бубен со стандартным диспатчером проще таки реализовать свой обсервер для контроллеров.

Добавлено через 1 минуту
А за отсутствие тегов минус в карму:) Автоматом. Сам поначалу ставил потом понял что я такой почти один) Перестал париться.

Монопенисуально. Чем проще?

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

З.Ы, Если уж плясать от добавления дисплей обжекта в контроллер то можно и хостом диспатить, на хост триады у контроллера ссылка то есть. И тот самый хост как правило добавлен в дисплейлист родительского хоста. А я например стараюсь каждой триаде выделять отдельный контейнер, получается то же четкое дерево хостов как и самих контроллеров.

При чем тут вообще DisplayObject? EventDispatcher не является DisplayObject, верно только обратное утверждение.
Фазы событий вообще используются только для DisplayObject. Если у вас контроллеры (внезапно) не являются потомками DisplayObject, то их придется эмулировать.
Концепция EventBus это реализует.

А с чего бы контроллерам были дисплейными? Вьюха дисплейОбжект, а модель и контроллер нет.

Добавлено через 1 минуту
ну вот при этом же:

вьюха не обязательно DisplayObject

Это я у вас спрашиваю, с чего бы?

Непонятно откуда вопрос возник:) Я ни разу на это даже не намекал)

Я привел цитату, откуда возник этот вопрос. Возможно я вас неправильно понял.

Ну не важно. А что скажете на тему диспатча ивентов хостами из контроллеров?
Всё-таки идея сохранения структуры дерева мне интересна. Чтоб не пихать глобальных евентБусов или же своих обсерверов.

Получится тот же event bus, только менее гибкий, т.к. шин событий может быть и несколько.

Резюме: единственный минус нативных событий - в отсутствии их нативного бабблинга вне DisplayObject.

За всю мою жизнь требовалось бабблить событие не из вью... ну раза 2-3. И то контроллерами. И я без тени презрения забаблил их из контроллера по ветке вью. Реальный случай когда нужен бабблинг по моделям мне до сих пор не встретился.

Кстати, мне до сих пор кажется, что синглтон используют ради его глобальности и только. Типа просто static - нуб, а если синглтон - то это паттерн, и не нуб )

Уходите от предрасудков, господа. Делайте так как удобно и положите на названия. Тут дело не в выборе слова.