[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
	}