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

[JackFromChaos]

Сообщение от i.o.

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

Сорри... А слона то я и не заметил

[i.o.]

у вас существенное упущение - не хватает this'а. Должно быть так:

_eventDispatcher = new EventDispatcher( this );

если хотите, чтобы target в событиях ссылался куда нужно, а не на _eventDispatcher

[JackFromChaos]

Сообщение от i.o.

у вас существенное упущение - не хватает this'а. Должно быть так:

_eventDispatcher = new EventDispatcher( this );

если хотите, чтобы target в событиях ссылался куда нужно, а не на _eventDispatcher

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

[i.o.]

Конечно понял, просто сразу прояснил ситуацию

[semenyakinVS]

Хорошо. Объясняю откуда взялась такая приверженность к множественному наследованию.

Пусть у нас есть большой проект (нам всё равно, какую иерархию он имеет, но он ОЧЕНЬ большой). В определённый момент возникает необходимость сделать графический трасировщик (box2d в тестовом режиме). При этом хочется, чтобы трасировщик оставался в парадигме дисплейных списков (иерархичность тестового отображения, родительские отображения передаются в детей, а главный класс иерархии передаёт всё дерево на сцену).

Выход...

Создаём класс (если бы делал на С++, объявил его виртуальным) с функцией

graphTrace(parentSprite:Sprite):void

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

Но тут оказывается, что множественного наследования нет! Не выйдет передавать базовый трасировщик как папу-класс. Как папу-интерфейс – можно, но что тогда делать со спрайтом? В интерфейс-то переменные совать нельзя!.. Тащить его по всей структуре, совать в наследников? Засорять private-секцию всех объектов системы?

Ладно, свойство одно, а если их пять? Если десять? Тоже везде заново писать в код наследников?

Ладно, такой класс один!.. А если много?

Например, у нас, в нагрузку ко всему прочему, есть класс, описывающий стандартный объект иерархии. Какой-нибудь CHierarchical? У него есть поле parent. Можно тоже обойтись без класса, но при этом поле снова-таки попадает в наследников… Дурная, надо сказать, наследственность.

Короче, я красивого выхода из подобной ситуации не вижу. Может кто-то подскажет?

Добавлено через 23 минуты
Так. Попробовал реализовать.

Не учёл, что описать вынесенные в наследника свойства надо будет только один раз, потом они будут переходить к наследникам, если описать его как protected. Будет легче, чем думал, но тоже не мёд, если честно.

Но я уже не уверен, что был сто процентов прав...

Добавлено через 1 час 4 минуты
Всё. Переделал... Однако, код мне начинает нравиться, он стал более управляемым!

Но тут как в игре в пинг-понг - повышаешь управляемость, но теряешь в скорости игры. Код стал более громоздким и в нём стали весомее комментарии.

В общем, так как-то:

public class Child implements Interface_1, … , Interface_N
	{
		// БЛОК ОПИСАНИЯ НАСЛЕДУЕМЫХ СВОЙСТВ
 
		// эмуляция блока свойств Interface_1
		…
		// эмуляция блока свойств Interface_N
 
		// БЛОК ОПИСАНИЯ СВОЙСТВ И МЕТОДОВ Child
 
		// свойства Child
 
		public function Child(/*ПАРАМЕТРЫ КОНСТРУКТОРА Child */ …)
		{
			// ЭМУЛЯЦИЯ КОСТРУКТОРОВ СВОЙСТВ
 
			// эмуляция конструктора Interface_1
			…
			// эмуляция конструктора Interface_N
 
			// КОНСТРУКТОР Child
 
			// здесь творятся свойства Child
		}
 
 
		// РЕАЛИЗАЦИЯ МЕТОДОВ Child
		. . .
 
 
		// РЕАЛИЗАЦИЯ МЕТОДОВ Interface_1
		. . .
		// РЕАЛИЗАЦИЯ МЕТОДОВ Interface_N
	}

[dimarik]

Это вы сейчас кому разговариваете слова? Вы поняли зачем нужны интерфейсы?

[Psycho Tiger]

Вот в Вашем примере это решается одним интерфейсом, ITraceable.

[semenyakinVS]

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

Это вы сейчас кому разговариваете слова? Вы поняли зачем нужны интерфейсы?

Нет. Я понял как очень извращённо можно с помощью них эмулировать множественное наследование.

Те комментарии, которые описаны у меня ДОЛЖНЫ БЫТЬ в коде, они должны предварять код, который описывают. Иначе код станет нечитабельным и вообще ужасным. Использование такого подхода - акт отчаяния.

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


Да и, кстати, описанный подход к формату будет действенным только для первого уровня иерархи. В более сложной ситуации - когда необходимы наследники от не корневых классов - он не поможет. Останется только композиция. (Могу показать картинку, не не понял как её вставлять сюда).

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

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

Вот в Вашем примере это решается одним интерфейсом, ITraceable.

Верно. Но вы бы видели код в ситуации, когда надо много наследников. Могу показать, если интересно.

[Psycho Tiger]

Верно. Но вы бы видели код в ситуации, когда надо много наследников. Могу показать, если интересно.

Это проблема не платформы и не языка, а Вашей архитектуры.

[dimarik]

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

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

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