On 7/27/07, Barry Kelly <[EMAIL PROTECTED]> wrote: > > In the case where the relationships are stored centrally, the nodes are much > > more lightweight in term of code as most operations gets delegated to the > > tree and there is no need to have internal methods. > > If the relationships are stored centrally, it seems to me that there's > no need for your nodes to implement any interface at all - they can > simply be System.Object. That would appear to me to be a better > approach; you could then use a proxy class (I'd choose a concrete sealed > one rather than an interface) to work with the nodes.
This is interesting ... I will see if that is possible. One more advantage of storing relationships centrally :) > The nodes store the relationships; typically as either a (possibly > sparse, i.e. created on demand) List<> of children, or as a FirstChild > and NextSibling tuple just like a Lisp cons cell. While this approach is simpler, it has the disavantage of wasting a bit of space for every node. If you use an array based structure, you lose memory for empty cells or time resizing the arrays. A way to reduce that effect is to create arrays lazily, which is why the ITreeNode is directly enumerable instead of having a ChildNodes property. I can simply return EmptyEnumerator.Instance for leaf nodes. Likewise, the Count property can check if the array is null and return 0. If you use a linked list, you lose locality of reference, which is the weak point of pure tree structures. Again, a central store can eliminate both the wasted space and the non-locality problems. -- Sébastien www.sebastienlorion.com
