[Паттерны] Деревья в программировании

[Wolsh]

Вы понимаете, что не можете унаследовать тот же Sprite от своего AbstractClass?
Вся загвоздка то в этом. Вы ставили задачу — чтобы любой класс мог стать нодой. Как сделать специальный класс-ноду — итак очевидно. Но унаследовать от него DisplayObject не получится.

Но вот если бы сам объект был и законченным объектом и нодой одновременно и это бы не противоречило ООП, то это было тем, о чем я и спрашиваю.

[OlmerDale]

Значит я опять не смог донести мысль...
Класс, который должен быть унаследован или реализовывать поведение ноды,
он не из нативных. Этот класс собираю я и к DO он вообще никакого отношения не имеет
и к нативным "абстрактным классам" тоже ( и я знаю что в as3 нет абстрактных классов, а
от якобы существующих наследоваться нельзя ). Со Sprite я его сравнил только по тому,
что спрайт является и контейнером и так же может быть чилдом самого себя. А ещё
спрайт является "законченным классом", имеется ввиду, что мне достаточно создать его
инстенс, а второй уже добавлять в него. Не придется использовать что-то ещё, типа -

var sp1:Sprite = new Sprite();
var sp2:Sprite = new Sprite();
StaticClassIsertSprite.insert(sp1, sp2);

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

[Wolsh]

Нет. Мне не понятно.
Ну создали Вы класс со свойствами next, prev, up и down. И наследуете его как хотите. В чем проблема? Как он "нарушает ООП"?

Люди, которые делали поле data:*, подразумевали отдельную структуру классов, обеспечивающих дерево — отдельно от всех остальных классов. Это структура "контейнеров", или "представителей". Они играют в свое дерево, и каждый "представляет" какой-то объект. Преимущество здесь в том, что объектом может быть действительно любой объект, никогда в жизни не слышавший ни о каких деревьях и нодах. Это, скажем так, соответствует композиции а не наследованию.
То, что делаете Вы — через наследование. Нодой может быть любой класс, если он наследует класс Node. Преимущество — отсутствие отдельно организованного Дерева как набора экземпляров нод, которое нужно обслуживать. Ну, вобщем-то, это ваше инвазивное дерево тоже надо обслуживать. Но не создается лишних объектов, согласен.
А, вот еще нюанс: в первом способе один и тот же объект может иметь несколько разных представителей.

[AlexCooper]

не уверен что правильно понял что вы хотите

package
{
	public class Node
	{	
		public var data:*;
 
		public function Node()
		{
		}
 
		public function get prev():Node {
			return _prev;
		}
 
		public function set prev(node:Node):void {
			if (!_prev) _prev = node;
		}
 
		public function add( node:Node ):void {
			next = node;
			node.prev = this;
		}
 
		public function set next(node:Node):void {
			_next = node;
		}
 
		public function get next():Node {
			return _next;
		}
 
		private var _prev:Node;
		private var _next:Node;
	}
}

package
{
	public class CustomClass extends Node
	{
		public function CustomClass()
		{
 
		}
	}
}

package
{
	import flash.display.Sprite;
 
	public class TestNode extends Sprite
	{
		public function TestNode()
		{
			var custom:CustomClass = new CustomClass();
			custom.data = 'parent';
 
			var node:Node = new Node();
			node.data = 'child';
 
			var childnode:Node = new Node();
			childnode.data = 'childnode';
 
			node.add( childnode);
			custom.add( node );
 
			trace(">>> Who is the youngest ? \n");
			elevator(custom,false);
 
			trace(">>> Who is the senior ? \n");
			elevator(childnode,true);
 
		}
 
		private function elevator(node:Node, goUp:Boolean):void {
 
			var level:uint = 0;
 
			while( node ) {
 
				trace('Level '+level++);
 
				xray( node );
 
				node = goUp ? node.prev : node.next;
			}
		}
 
		private function xray(node:Node):void {
 
			if (node.prev) trace(' Prev node: '+ node.prev.data );
 
			trace(' This node: ' + node.data );
 
			if (node.next) trace(' Next node: '+ node.next.data );
 
			trace("\n");
		}
	}
}

>>> Who is the youngest ?

Level 0
This node: parent
Next node: child


Level 1
Prev node: parent
This node: child
Next node: childnode


Level 2
Prev node: child
This node: childnode


>>> Who is the senior ?

Level 0
Prev node: child
This node: childnode


Level 1
Prev node: parent
This node: child
Next node: childnode


Level 2
This node: parent
Next node: child

[OlmerDale]

package
	// если объяснять на Вашем примере,
	// то CustomClass становится CustomContainerClass
	public class CustomContainerClass extends Node
	{
		// а так как он контейнер он содержит лист объектов
		// унаследованных от Node. Но это не привычный и 
		// лист, который содержит ноды, в которые добавляется
		// все что туда положат, а это лист принимающий и манипулирующий
		// самими нодами.
		private var _nodeQueueList:NodeQueueList;
 
		public function CustomContainerClass()
		{
 
		}
 
		// и так как это контайнер, то CustomContainerClass
		// имеет метод insert
		public function inser(node:Node):void
		{
			// и тут уже добавляем в _nodeQueueList
		}
 
	}
}

Но меня напугало слово "инвазивно" и я отказался от первоначальной идеи
и заменил

private var _nodeQueueList:NodeQueueList;

private var _nodeQueueList:Vector.<Node>;

Спасибо всем.

[Wolsh]

Ну и зачем Вы упорно используете Очередь (Queue)?
Для дерева любая нода должна иметь ссылку на parent:Node и список children:Vector<Node>. То есть как в уже цитировавшемся Вами Sprite. И даже возможно те же методы придется подшить, типа getChildByName() и getChildAt(). Это нарушает ООП? Пожалуйтесь в ООН.

[OlmerDale]

Я опять ошибся в объяснениях, сорри. Я вообще отказался от идеи с нодами и перешел на идею где
контайнер и его чилды унаследованы от общего абстрактного класса ( в последнем ошибочном примере
я его Node назвал ). да и очередь у меня приоритетная которую класс-контайнер запускает при добавлении в него объекта унаследованного от абстрактного типа, от которого унаследован и он.

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

А Вы случаем не знаете для чего дисплей обжектам нужна ссылка на парент?

[Wolsh]

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

[dimarik]

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

Могут ли деревья состоять из узлов-листьев не класса контейнера с полем data:*, а из самих-поведенчески законченных классов-объектов?

Если "поведенчески законченные" объекты будут выглядеть как узлы, то чем их структура будет отличаться от древовидной? Если же нет, то как они смогут образовать древовидную структуру?
Тут простой философский вопрос: перед нами дерево или не дерево?

То есть я объект CustomInstance и у меня есть ссылку на next, prew, up, down.

У дерева примерно такие ссылки и есть.