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

[yorlin]

Сообщение от switcher!

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

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

Хотели красиво сказать, а получилось как то нелепо, тут скорее всего лучше так: Есть колбаса и есть тот кто ее развозит, а вопрос автора: почему не объединить колбасу и развозчика и получить саморозвозящуюся колбасу. Но и этот пример не подходит, так как вопрос более тонкий, чем колбаса

[silin]

саморазвозящаяся колбаса:

public class MyEventer extends EventDispatcher
{
	private var _event:Event
	public function MyEventer(event:Event) 
	{
		_event = event;
	}
	public function dispatch():void
	{
		dispatchEvent(_event);
	}
}

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

Добавлено через 3 минуты
event это одноразовая посылка, создается по месту исходя из конкретных условий, после доставки и извлечения информации убивается
eventDispatcher универсальный рассылщик таких посылок
какая польза от объедения их в одном флаконе не очень понятно

[switcher!]

1. быстрее создать объект с 5-ю свойствами, чем с 10-тью.
2. если в обработчике нам нужны только данные о событии, то зачем туда пихать методы и свойства EventDispatcher?
колбасу развозит среда выполнения флэш, т.е. FlashPlayer, а не связка из Event+EventDispatcher

[wvxvw]

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

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

Ну вот представьте, у вас есть 2 экземпляра одного и того же класса, они оба диспатчат событие "change" но разница в том, что один из экземпляров его диспатчит 1 раз в минуту, а другой - 10 раз в секунду. А вы просто подписались на событие "change", теперь:
- 599 вызовов обработчика собыя будут "мимо".
- один лиший слушатель при перечислении всех слушателей, которое это событие должно оповестить.
- лишняя логика в обработчике событя по вычислению, а кто же его вызвал.

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

Вот такой например вариант "подписки" на изменеие ширины:

public function set widthListeners(value:Vector.<Function>):void
{
	for each (var f:Function in value)
	{
		if (_widthListeners.indexOf(f) < 0)
			_widthListeners.push(f);
	}
}
 
public override function set width(value:Number):void
{
	for each (var f:Function in _widthListeners)
	{
		f(super.width, value);
	}
	super.width = value;
}

[Felicast]

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

отделение данных от логики - это тру путь

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

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

[TommyLee]

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

2 экземпляра одного и того же класса, они оба диспатчат событие "change" но разница в том, что один из экземпляров его диспатчит 1 раз в минуту, а другой - 10 раз в секунду.

EventDispathcer может не единожды пройтись по своему списку? То есть отправить приемникам событие не один раз? В описании EventDispathcer не нашел каких бы то ни было настроек диспетчеризации, кроме useCapture в addEventListener.

Felicast, есть недоделанное ТЗ на прораммку для собственных нужд, чтобы реализовать нужно построить архитектуру. Если строить ее без учета модели событий AS3 - как привык, то потом переделывать придется.
з.ы.
Никак не могу отвыкнуть от событийной модели с++ билдера, делфи - с отсутствием подписки и написания кода в самих методах-обработчиках. Здесь это приемники событий, разрозненные по своим объектам и связанные с событием только через EventDispathcer. А он сам - то ли просто механизм подписки-оповещения, то ли такой же объект-подписчик, как и приемники событий..

[Котяра]

Методы обработчики были в AS2 (onEnterFrame, onRelease, итп)
Слава богу что от них ушли.
EventDispatсher - это базовый объект рассылающий события,
Sprite, MovieClip - тоже рассылают события, но они не наследники EventDispatсher, просто реализуют IEventDispatсher
при добавлении addEventListener к какому нибудь объекту-диспатчеру мы сопоставляем событие и ф-цию-обработчик. (внутри это может выгледять, как двумерный хэш список, или хэш список массивов ф-ции.. или еще как..)
В момент наступления события ( внутреннего, вроде клика, или пользовательского в момент вызова dispathEvent) объект проходится по списку слушателей и вызывает ассоциированные ф-ции передавая им возникшее событие (данные)

[wvxvw]

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

EventDispathcer может не единожды пройтись по своему списку? То есть отправить приемникам событие не один раз? В описании EventDispathcer не нашел каких бы то ни было настроек диспетчеризации, кроме useCapture в addEventListener.

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

Сообщение от Котяра

Методы обработчики были в AS2 (onEnterFrame, onRelease, итп)
Слава богу что от них ушли.
EventDispatсher - это базовый объект рассылающий события,
Sprite, MovieClip - тоже рассылают события, но они не наследники EventDispatсher, просто реализуют IEventDispatсher

Откуда такая информация? По документации как раз наследуют а не имплементят.
А по поводу таких обработчиков, как в AS2 - а почему такая увереннось, что это плохо? Я, например, обратил внимание, что в 50% случаев мне этот событийный объект не нужен, т.е. не используется в функции-обработчике. Вообще вуглядит глупо, вызвали функцию с аргументом, и вообще проигнорировали аргумент. Вообще, было бы конечно идеально, если бы разработчик мог сам решать какая сигнатура должна быть у слушателя, но, раз уж у нас арсенал средств ограничен, то уж что есть...

[Felicast]

Никак не могу отвыкнуть от событийной модели с++ билдера, делфи - с отсутствием подписки и написания кода в самих методах-обработчиках.

ну чтож опишу разницу между делфи, c# и as3 (может что то будет не так, но смысл должен быть понятен):
возьмем обработку клика по кнопке:
делфи:

procedure TForm1.buttonClick(Sender: TObject);
begin
	MessageDlg('Hello', mtInformation, [mbOk], 0);
end;

{где-то инициализируем кнопку}
myButtun.OnClick := buttonClick;

C#:

private void buttonClicked(object sender, EventArgs evArgs)
{
	MessageBox.Show("Кнопка была нажата");
}

/*где-то инициализируем кнопку*/
myButtun.Click += new System.EventHandler(buttonClicked);

as3:

private function clickHandler(event:MouseEvent):void
{
	trace("hello");
}
 
/*где-то инициализируем кнопку*/
myButton.addEventListener(MouseEvent.CLICK, clickHandler);

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

[Котяра]

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

Откуда такая информация? По документации как раз наследуют а не имплементят.
А по поводу таких обработчиков, как в AS2 - а почему такая увереннось, что это плохо? Я, например, обратил внимание, что в 50% случаев мне этот событийный объект не нужен, т.е. не используется в функции-обработчике. Вообще вуглядит глупо, вызвали функцию с аргументом, и вообще проигнорировали аргумент. Вообще, было бы конечно идеально, если бы разработчик мог сам решать какая сигнатура должна быть у слушателя, но, раз уж у нас арсенал средств ограничен, то уж что есть...

По поводу Sprite имплементит а не наследует - погорячился.. (но не суть важно)
А вот что единая ф-ция обработчик это плохо, я уверен на 100%. дело даже не в передаче эвента в ф-цию обработчик, а в куче неудобств при переопределении одной единственной onRelease, переделегировании событий и.т.п.
да и оставшиеся 50% ( по вашим рассчётам), требующие данных события - это совсем не мало)