> > Thus my TreeNode class
> > corresponds most closely
> > to the TreeEntry class of yours, not Tree.
>
> Which suggests the right approach to take is to leave TreeNode as it is,
and consider whether to make an implementation of Tree that uses TreeNode
for its guts.
This was kind of where I was heading. What if the keys in your
implementation became TreeNodes?
public interface Tree extends Map {
// Map methods are used to set/get the values
/** Set value on a node */
put(node, value)
/** Get value from node */
get(node)
/** remove from parent */
remove(node)
/** Get all the tree nodes */
keySet()
/** Get all the values */
values()
// additional Tree methods amend the tree structure
/** Get the root node */
getRootNode()
/** add child */
add(parentNode, childNode, value)
...
}
Internally, Tree would hold TreeEntry objects. Each TreeEntry would have the
node as the key and the value as the value. Would this style of interface
work for you? (It involves no change to TreeNode)
Stephen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
