Композиция: обращение вверх по иерархии

[Akopalipsis]

Добавлено через 15 минут
Пользовательские события - это когда Вв класс создаете, как у Вас в примере.
Слушаете Вы его так:

addEventListener(MyEvent.СТРОКОВАЯ_КОНСТАНТА,handler);

а посылаете вот так:

dispatchEvent(new MyEvent(MyEvent.СТРОКОВАЯ_КОНСТАНТА));

так будет выглядеть слушатель:

private function handler(event:MyEvents):void
{
 
}

В примере, который показывали выше нет собственного события, там только собственная константа.
Событию абсолютно без разницы, какую ему константу дадут, лишь бы только String.
Смотрите в чем разница:

addEventListener(GameEvents.REMOVE_CHILD,handler);

dispatchEvent(new Event(GameEvents.REMOVE_CHILD));

private function handler(event:Events):void
{
 
}

Так будет выглядеть класс с константой:

package 
{
	public class GameEvents 
	{
		public static const REMOVE_CHILD:String = "remove_child";
	}
}

И вот когда Вы послали в ребёнке событие удаления, в родителе поймали и удалили того, кто послал:

private function handler(event:Event):void
{
	var child:DisplayObject = event.target as DisplayObject;
	removeChild(child);
}

Надеюсь не где не запутался.

[Dukobpa3]

child.addEventListener(GameEvents.REMOVE_CHILD, handler);
//**********************
private function handler(event:Event):void
{
	var child:DisplayObject = event.currentTarget as DisplayObject;
	removeChild(child);
}

В любом случае подписываемся не на себя, а на чилда.
А в подписках я бы рекомендовал реже использовать таргет и чаще карентТаргет. КарентТаргет - это на кого подписывались. Таргет, это от кого прилетело. В данном случае совпадет. Но При условии бабблинга события, могут быть сюрпризы, потому рекомендую вырабатывать привычку подписки таки на карентТаргет. И таргет использовать только там и именно там, где это необходимо исходя из задачи (например без этого не обойтись с многослойными интерфейсами и бабблингом, или же со всякими там редиспатчами по дереву моделей).

В остальном всё верно.

[Akopalipsis]

А в подписках я бы рекомендовал реже использовать таргет и чаще карентТаргет.

Dukobpa3 Спасибо! Учту! я просто не когда currentTarget отличающийся от target не видел, но Вы обьяснили причину и мне понятно. Баблинг ещё не разу не использовал

[a7s1h1]

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

Смотрите в чем разница:

Спасибо за подробное объяснение. Ловля отправителя - очень полезная штука!
Я попробовал, как Вы объяснили - всё работает так же, как и раньше, когда я делал через MyEvent.
В чём же отличие способов, кроме того, что в одном случае мы при распространении события создаём экземпляр собственного класса MyEvent, а в другом - стандартный Event?

[Dukobpa3]

В чём же отличие способов, кроме того

Мвахах
Да собственно в этом и есть отличие
Зачем вам свое событие для такой мелочи? Свое событие надо создавать если в нем будут передаваться какие-то особенные данные или в таком духе. А если просто имя - так стандартного за глаза. И свою константу добавить и ок.

[a7s1h1]

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

Свое событие надо создавать если в нем будут передаваться какие-то особенные данные или в таком духе.

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

[Dukobpa3]

Правильно но не для всех ситуаций.
У нас есть еще стандартное событие DataEvent. У которого есть одно дополнительное поле data:String. Вцелом для подавляющего большинства событий со своими данными - этой строки дополнительной хватает.
Даже если передать одну цифру очков переведенную строку, выглядеть будет не так красиво как со своим событием, но обойдемся без доп-класса. А вцелом я адепт мвц и стараюсь в событиях ничего никуда не передавать. Если что-то нужно передать, это можно зафиксировать в модели. Отправляем событие, получаем событие, видим что в модель нужно заглянуть и посмотреть на новые данные. Вполне ок схема.

А сам список констант по ситуации можно хранить в глобальном классе-списке констант, как был в примере у Akopalipsis, можно в классе, который диспатчит это событие (удобно и правильно так делать если это событие не диспатчит никто другой)

[Котяра]

А сам список констант по ситуации можно хранить в глобальном классе-списке констант

Это плохо.
Разовью холивар.
Бывает, что заводят констаны в классе публикующем событие.
И любой, кто подписывается на это событие (константу), тянет весь класс.
Я сторонник заведения отдельного класса события, ничем не отличающегося от Event, кроме списка констант. Это позволяет в хороших иде генерить хэндлеры именно этого события и генерить ошибки, если приходит совпадающее строковое имя эвента, но другого типа.

[Dukobpa3]

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

Не хочу холиварить, скажу только что сам так раньше делал, потом отказался ибо оверхед.
В итоге в основном юзаю дефолтные события. Константы храню в отдельном классе ибо хреново если:

любой, кто подписывается на это событие (константу), тянет весь класс

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

[spirit2]

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

А то при определенном кол-ве классов, классиков и прочих сущностей, сложно становится контролировать это всё.

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