запуск событий одного класса во множестве

[in4core]

Не знаю как правильно назвать тему, извиняйте.

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

StaticClass.addEventListener(...)

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

StaticClass.dispatcher = internalDispacther;
internalDispatcher.addEventListener...
А в каждом новом классе internalDispatcher = StaticClass.dispatcher;

Этот самый вариант 2, видимо самый и убогий.
Но вариант 1, тоже не блещет, где то говорилось и обсуждалось , что статик в этом случае не есть тру.
Так вот интересно ваше мнение,
1. имеет право на жизнь статик в данном контексте ?
2. если не статик, то как ?
Архитектруа

ServerClass
....
function onGetData(data) {  ???.dispatchEvent(...) }
//
SomeOtherClass
...
???.addEventListener(ServerClassEvents.SOME_EVENT... )
...
SomeOtherOtherClass и т.д.
 
???.addEventListener(ServerClassEvents.SOME_EVENT... )

[Цветкофф]

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

package
{
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class ServerDispatcher extends Sprite 
	{	
		public function dispatcherServerEvent() 
		{
			dispatchEvent(new Event(ServerClassEvents.SOME_EVENT));
		}		
	}
}

SomeOtherClass.as

package
{
	import flash.events.Event;
 
	public class SomeOtherClass extends ServerDispatcher 
	{		
		public function SomeOtherClass() 
		{
			addEventListener(ServerClassEvents.SOME_EVENT,someFunction)
		}			
		private function someFunction(e:Event):void 
		{
 
		}
	}
}

SomeOtherOtherClass.as

package
{
	import flash.events.Event;
 
	public class SomeOtherOtherClass extends ServerDispatcher 
	{		
		public function SomeOtherOtherClass() 
		{
			addEventListener(ServerClassEvents.SOME_EVENT, someSomeFunction)
		}			
		private function someSomeFunction(e:Event):void 
		{
 
		}
	}
}

примерно как то так)))

[Wolsh]

Обсервер?

[Dukobpa3]

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

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

[in4core]

Обсервер?

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

ExchangeRate.getInstance().registerObserver(this);

уже статика вообщем то

[Wolsh]

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

уже статика вообщем то

Наоборот, классический синглтон. Могло выглядеть и как

Server.notifier.addListener(this);

Еще раз – если использовать готовую систему оповещений через события, то вопрос сводится к "статик или синглтон". Обсервер это альтернативный третий вариант. Я просто внес разнообразие в твой выбор. Хотя и так видно, что ты уже выбрал статик и размышляешь только о том, прятать диспатчер за статическим фасадом или выставить его в общий доступ. Если спрячешь, то получишь неясность с target/currentTarget (EventDispatcher не делегируется на Класс, только на интерфейс, а у Классов не может быть интерфейса))). Если это не пугает, то почему бы и нет. Прятать хорошо. Прятать "сервер" – тем более)) По крайней мере никакой злодей не заставит твой диспатчер разослать ложные сообщения.

[Psycho Tiger]

Что-то ничего не ясно. EventDispatcher и есть Observer.

[Wolsh]

EventDispatcher и есть Observer.

Ну не совсем. Обсервер предполагает наличие у подписчиков единого для всех метода, описанного в интерфейсе. Нотифаер тупо вызывает этот метод (при этом в базовой схеме никакого объекта вроде Event не отдается). Регистрируются не методы-обработчики, а сами экземпляры-подписчики. Их просто уведомляют, что нотифаер изменился, а они могут запросить данные по своим нуждам. EventDispatcher это конкретизированный обсервер, со своей специфической реализацией. То есть он – обсервер, но обсервер – не он.

[Dukobpa3]

Сообщение от Psycho Tiger

Что-то ничего не ясно. EventDispatcher и есть Observer.

Ты уже во второй или третьей теме отстаиваешь эту идею.
Или в блоге каком-то, не помню.

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

[in4core]

Wolsh спасибо я тебя понял.