Архитектура событийной модели. Варианты подписки на события.
 

+его пример EventDispatcher.
Так же читал темы на форуме и переводного Мука. Пришел к тому, что вариантов подписки может быть несколько:
1. Прямая подписка на событие:
объекты(ы)EventDispatcher --> событийный объект(Event,..)
2. Косвенная подписка:
объект(ы)EventDispatcher -->объектыEventDispatcher --> событийный объект(Event,.)

Только вот смысл 2го варианта не пойму.

Второй вариант - это всплывающие события?
Если да, то это просто часный случай обычных событий, собственно, сделано для удобства, когда, например, вместо того, чтобы добавлять 1000 слушателей к дочерним объектам, вы добавляете 1 к родительскому и в нем определяете кто из детей вызвал событие. Это получается дешевле в смысле производительности / количества написаного и скомпилированого кода.

Пока нет практического опыта, так что ничего сказать не могу. А в Муке зациклился на главе о событиях не отображаемых - дальше не читал.
Возможен ли такой вариант: на панеле есть несколько элементов, которые должны изменяться в результате щелчка по панели; все элементы панели подписываются на событие щелчка по ней?
Или такое невозможно и всем элементам нужно подписываться напрямую?

вместо того, чтобы подписывать все элементы панели на клик. Можно создать класс MyButton(унаследованный, например, от Sprite), в котором определить переменную id как идентификатор нажатой кнопки.
А на панели поставить слушатель на клик, обработчик которого может выглядеть подобным образом:
Да, и вот еще пример.

Значит вариант реалистичен.. В модели я не могу понять такую вещь: зачем нужен "промежуточный" класс EventDispatcher, когда можно было бы подписываться прямо в событийном объекте? Например, получать ссылку на событийный объект, а затем вызывать метод регистрации? Изначально бы сделать в Event подобный функционал, а потом наследовать со всеми характеристиками события..

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

Да понимаю я разницу: в Event плеер ложит характеристики события, а EventDispatcher реализует механизмы подписки и оповещения. Не могу только понять, зачем нужен посредник. От этого какое-то "проскальзывание" в понимании модели..

Ничего не могу с собой поделать. Если не понимаешь механизм того, что своял - какое же может быть наслаждение?

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

Некорректно выразился. Хотел сказать, что функционал подписка-оповещение вынесен в отдельный класс, вместо того, чтобы реализовать его в Event. Для меня это нелогично, но я не профессионал, поэтому хочется узнать причины такого шага, чтобы повысить свой уровень.

1. Что быстрее произвести 5 палок колбасы или 10? Очевидно, что 5-ть.
2. Допусти вам в месяц хватает 5-ти палок колбасы, чтобы наесться. Что делать с другими 5-тью? Положить на склад и заморозить (чтобы не протухли). В итоге имеем нерациональное использование рабочей площади и колбасу с ухудшенным вкусом и потерянными полезными качествами после разморозки.

Вы же пытаетесь эти два пункта объединить в связке Event+EventDispatcher.