альтернатива пользовательским событиям

[Zebestov]

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

лучше так:
GameOver extends flash.events.Event

а еще лучше так:

public class GameOver {...}

всё, никакого extends

Если в коде диспатчится нативный Event, то GameOver является всего-навсего хранителем констант — типов события, всяких там

public static const KAPETS:String = 'kapets';
public static const NE_SOVSEME_KAPETS:String = 'neSovsemeKapets';

Наследование от Event (не забываем при этом переопределить метод clone) как правило необходимо, если мы хотим добавить заветный data:*, чтобы событие еще и таскало за собой до конечного обработчика какую-то важную информацию.

[Sevil]

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

а еще лучше так:

public class GameOver {...}

всё, никакого extends

Если в коде диспатчится нативный Event, то GameOver является всего-навсего хранителем констант — типов события, всяких там

public static const KAPETS:String = 'kapets';
public static const NE_SOVSEME_KAPETS:String = 'neSovsemeKapets';

Наследование от Event (не забываем при этом переопределить метод clone) как правило необходимо, если мы хотим добавить заветный data:*, чтобы событие еще и таскало за собой до конечного обработчика какую-то важную информацию.

А зачем переопределять clone(), если, допустим, я каждый раз создаю новый эвент dispatchEvent(new CustomEvent(CustomEvent.MY_TYPE)); ?

а в CustomEvent у меня будет public var data:Object ={}; Куда я могу запихнуть всё что мне нужно, а конструктор будет принимать Object как второй аргумент dispatchEvent(new CustomEvent(CustomEvent.MY_TYPE, {data: param}));

[Zebestov]

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

А зачем переопределять clone()?

Об этом можно почитать в документации.

[amesqit]

С событиями разобраться довольно просто. У нас есть 2 объекта Исполнитель и Заказчик. Заказчик нанимает исполнителя на определенную работу и знает о нем только то что он ее делает. Исполнитель не знает о заказчике ничего, для него работа и есть работа, пришло задание и он его делает. Нам надо дать знать Заказчику, что Исполнитель выполнил задание таким образом, чтобы Заказчик не стоял рядом с Исполнителем следя за каждым его шагом, а также чтобы Исполнитель после выполнения заказа не бежал искать заказчика чтобы передать ему результат, т.к. это выходит за пределы их роли, вот тут на помощь приходят события. Функция addEventListener - Исполнитель рядом со своей мастерской вешает корзину, на которой написано название события "Окончание работы" и Заказчик кидает туда конверт в котором содержится обработчик этого события. Функция dispatchEvent - Исполнитель завершая работы над заданием подходит к этой корзине и распечатывает конверты по очереди запуская обработчики событий. Функция removeEventListener - если заказчик вдруг решит по какой-то причине умереть, то ему желательно забрать свой конверт у Исполнителя, чтобы тот не пытался вызывать обработчик мертвого Заказчика, т.к. о Заказчике ничего не известно кроме его обработчика, так же забрать конверт надо, если результат просто перестает интересовать. Пользовательские события - это та же корзина, но принимать она может только оговоренные коробки, бандероли и другие предметы рассчитанные на результат выполненной работы, чтобы корректно выполнился обработчик, т.к. этот обработчик ждет результат строго определенного вида. Надеюсь это сочинение упростит понимание, а не запутает

[udaaff]

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

[amesqit]

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

Добавлено через 9 минут
Хотя тут больше всего, конечно, подходит термин Подписчик, т.к. заказчику, который инициализировал весь процесс может быть вообще не интересен результат. Это тем более говорит о том, что Исполнитель не должен никак взаимодействовать с Заказчиком.

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

[udaaff]

и в корзину может кинуть конверт любой, кто знает о существовании исполнителя

Технически, знать о конкретном исполнителе необязательно, учитывая, что конвертики можно подсовывать не только определенному почтальону, но и в наглую занести прямо на главпочтамт (подписка не на целевой фазе), то знать местного почтальона нам не обязательно.

[amesqit]

Если мы зашли так далеко, то почтальона может убить каждый получатель письма, чтобы остальные подписанные на сообщения от Исполнителя не получили события. События - это очень просто)