Множественное наследование

[i.o.]

Показываем:

package  
{
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.events.IEventDispatcher;
 
 
	public class MyIEventDispatcher extends Object implements IEventDispatcher
	{
 
		public function MyIEventDispatcher() 
		{
			_eventDispatcher = new EventDispatcher( this );
		}
 
 
 
		private var _eventDispatcher:EventDispatcher;
 
 
 
		public function dispatchEvent( event:Event ):Boolean 
		{
			return _eventDispatcher.dispatchEvent( event );
		}
 
		public function hasEventListener( type:String ):Boolean 
		{
			return _eventDispatcher.hasEventListener( type );
		}
 
		public function willTrigger( type:String ):Boolean 
		{
			return _eventDispatcher.willTrigger( type );
		}
 
		public function removeEventListener( type:String, listener:Function, useCapture:Boolean=false ):void 
		{
			_eventDispatcher.removeEventListener( type, listener, useCapture );
		}
 
		public function addEventListener( type:String, listener:Function, useCapture:Boolean=false, priority:int=0, useWeakReference:Boolean=false ):void 
		{
			_eventDispatcher.addEventListener( type, listener, useCapture, priority, useWeakReference );
		}
 
	}
 
}

[semenyakinVS]

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

предпочитайте композицию наследованию классов"(с) Банда четырех.

Кто это сказал? Плохая идея.

Задача: "Человек - наследник безмозглой обезьяны. У него есть мозг".

Реализация в таком вот подходе:
"Человек - оболочка с обезьяной внутри. Плюс у него есть мозг".

Реализация в подходе наследования:
"Человек – следующие звено в развитии обезьяны. У него есть мозг."

По-моему, второе звучит более логично.

Привожу сравнительную характеристику собственного производства.

«Наследование-включение»:
«+»
1. Возможность реализовывать функции-провайдеры в наследнике («Декоратор»). Таким образом мы можем запретить к использованию некоторые методы отца (Тут следует заметить, что то же самое можно реализовать и в подходе наследования, но в таком случаи это будет менее естественно для данного подхода).
2. Можно множественно наследовать там, где множественно наследовать нельзя.

«-»
1. Минус - громоздкий код («Декоратор» всегда громоздок).
2. Уничтожение одного из подходов к построению логики кода. Таким образом мы не сможем никак выделить архитектурой родственность между объектами.

«Наследование-наследование»:
«+»
1. Реализует стандарт С++.
2. Изящно – нет лишнего кода.
3. Минус один уровень вызова через точку.

«-»
1. Сложно представить. При неправильном подходе может вызвать захламлённость структуры.
2. Требует умения думать абстрактно.

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

Вообще почитайте "Приемы объектно ориентированного проектирование - паттерны проектирования". Глава введение, раздел "наследования и композиция".

Я читал книгу по шаблонам авторства Гамма. Почти все книги по паттернам рассматривают java-подобные подходы к архитектуре, где множественное наследование заменено интерфейсами.

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

В результате программист зависит не от логики, а от реализации компилятора...

Множественное наследование присуствует в стандарте С++. Любой компилятор под него обязан реализовывать множественное наследование.

Думаю, Страуструп дураком не был.

[Psycho Tiger]

Кто это сказал? Плохая идея.

Я рад что наконец-то Вы пришли и сказали нам, что GoF`ы были не кем-то, кого стоит знать. =)

[semenyakinVS]

А кто это?

Через некоторое время:

Почитал. Ясно... А какова их мотивация?

[Psycho Tiger]

Вы тут описывали нам Декоратор. Так вот он тоже с приставкой GoF.

[expl]

Почитал. Ясно... А какова их мотивация?

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

А разработчики as3 видимо посмотрели на Java, С#, D, ... и решили что и as3 без множественного наследования обойдется
Считается что оно проблемы создает

[JackFromChaos]

Пример реализации EventDispacher с помощью композиции:
Удалил, потому что пример был выше, просто чет не заметил его...
P.S.
На написание ушло не более 1 минуты... Медленнее чем просто унаследоваться, но не так уже и страшно...


Добавлено через 7 минут

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

Думаю, Страуструп дураком не был.

Страуструп при создании стандарта С++ 2.0 от множественного наследования избавился... Хотя шанс, что этот язык когда нибудь появится в реальности, не так уж и велик...

[Dukobpa3]

Имхо множественное наследование - это геморрой)))

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

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

Добавлено через 1 минуту
И вся ветка кажись завязалась вокруг диспатчера, с ним вообще проблем не вижу, та и примеров накидали кучу уже.

[JackFromChaos]

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

Я читал книгу по шаблонам авторства Гамма. Почти все книги по паттернам рассматривают java-подобные подходы к архитектуре, где множественное наследование заменено интерфейсами.

Я конечно изеняюсь, но в книжке Гаммы, Хелма, Джонсона и Влиссидеса(все таки из было четвера), все примеры были на с++ и ориентирована она была на с++ прежде всего... но это так, к слову...

[i.o.]

JackFromChaos, зачем писать точно такой же код, если он уже написан в посте номер 21?