I'm developing a class that will be used to generate a tree structure. Each Node of the tree needs to know both who it's parent is and who it's children are. The fields used to track each Nodes parent and children are not accessible outside the base Node class.
Right now I have methods for AddChild, and Remove child. Which consequently also set the parent fields of the instances being related.
So what I'm wondering now is if it would be any better or worse to switch this and setup methods where the user of the class has to call Node.SetParent(Node parentNode) and Node.ClearParent(Node oldParentNode) methods instead.
If you are tracking both parent and child relationships, why would you choose to set the child relationships over the parents or vise versa, or does it even matter?
In either case, when you are attaching a node to the tree you will need a reference to both the parent and the child node in question, so I don't see how it would make a difference, as either way will be equally possible in all situations.
I'd suggest figuring out which direction your logic will make the most sense (i.e. is it easier to think about building the tree from the leaves up or the root down) and go with that.
Decisions like these typically depend on how the class will be used. If a typical scenerio is for a tree to be build from the parent node down, then using an AddChild method is often best, if your users build them from the other way around, give the a SetParent method. If there is a need for both, implement both, so long as the appropriate book keeping is done internal to the class.
(side note: I usually build trees from the parent down)
I think you need all three methods. When building a tree, the AddChild method would seem more natural. There are two reasons to remove a node. One is to get rid of it, and the other is to reorganise the tree (move a subtree to another branch). When deleting, RemoveChild works well. But reorganisation could use the SetParent method to avoid making two calls. SetParent could also become a transaction of sorts.
Related
I am trying to create a recursive Tuple in C#. One side is a reference a class, and the other side goes into recursion to a likewise datastructure. The right side can be null, and this is when the recursion ends.
At the moment I am using an alias, but this does not seem to work.
using Relation = System.Tuple<Node, Relation>;
Directly typing this is not possible, as this goes infinite.
System.Tuple<Node, System.Tuple<Node, System.Tuple<Node, ...>>>
1.
Is this possible in C#?
2.
Can I do this with aliases?
Extra info
I am doing this because I need to keep track the parent of each node. A node can have multiple children. I cannot edit the node class.
I only need to go up the hierarchy. i.e. I don't need to know a nodes children. I use this for an algorithm where I calculate alot of nodes, and when I find one, I want to find the path to it from bottom to root.
You can create a Class for this.
class Relation
{
Node Node; // Node is another class
Tuple<Node, Relation> Relation;
}
I want to display a tree structure. Do i really need to give the user/tree a predefined hardcoded root node like "RootUnit" where he can add his children or descendants?
Does this make sense or cause only trouble when adding nodes?
If you have two roots then you have two trees.
A tree should have only one root. But you need not hardcode a root. Just treat the first created tree node as root.
A tree by definition has only one root and every child node has exactly one parent (except the root which has no parent). If these restrictions are not met then your tree is no longer a tree but a graph (oriented or not)
It depends on the context. From a strict mathematical definition, you cannot have multiple root nodes to a tree. However, there some implementations of trees that ignore that and have multiple top level nodes anyway (Such as the TreeView control you tagged this question with). You simply need to ask yourself if your particular program would be better or worse with multiple top level nodes. Given that we know nothing else about your program it's not a decision we can really make for you.
Rather than using the same constructor for every node, supply a default constructor used for the root node and one for everything else. It isn't ugly, and it works.
public Node()
{
// Set properties if you'd like.
// such as having no children yet or whatnot.
}
public Node(Node parent)
{
// Similar to Node()
}
See! Nice and clean.
In the app I am writing, I am trying to find a way to store hierarchies effectively. Here is an example.
At the bottom, you can see the nodes to be stored. Should I use multi dimensional lists? That doesn't seem very optimal, right? I was thinking holding references like so:
node.Parent
node.Children { collection }
Anyone has experience with this kind of stuff?
This is a fairly basic implementation of a tree, yes. If choose to make your collection for the children an IList or IEnumable or ArrayList, etc is up to you.
I would strongly suggest you build a generic implementation instead of one typed to your domain model, however that is up to you.
Yeah. You have the right idea. If you need a two-directional hierarchy, I wouldn't use a multi-dimensional list... I would add a node to the tree and each node contains a parent and a collection of children.
You are on the right track.
If not all items are of the same type, I may use an abstract base class for a linked list and children collections in such a situation.
Basically in my app I want to store all the nodes created by the user in a global list, say like:
GlobalComposition = { collection }
which will store nodes like:
ImageInput01, ImageInput02, Blur01, Sharpen01, Contrast01, Contrast02
What I can't decide is whether I should store them in a linear "1 dimensional" collection, or only store the base node that contains other nodes? So for something like:
ImageInput01 -> Blur01 -> Sharpen01 -> Contrast01
storing only ImageInput01.
This gives me the ability to use the same names for the action nodes that comes after the base node.
Which one would be better for unique naming system for nodes, performance, easily traversing the nodes in the composition, etc?
To me keeping the hierarchy seems more sensible but want to know people's thoughts.
Certainly a hierarchy will give you more power from a taxonomy point of view. Also, searching a tree is more efficient than searching a 1-dimensional collection in most cases.
You'd also be able to use .ToList() for a 1-dimensional collection as long as you're using .NET generic collections, as well.
Unfortunately, a hierarchy is a bit harder to implement, but generally if there is an indication of a need for it, you'll be able to take good advantage of the features it'll provide you way down the line.
I know i can use LogicalTreeHelper class to find children node for every element searching it by name. But is there a possibility to find a child node by Type? For example, what if i would like to find a ListBox element in my Window without knowing its Name property??
I don't think that there is a built in way of doing this. Probably the best approach would be to recursively call LogicalTreeHelper.GetChildren() until a child control of the specified type is found.
Note that descending the Logical tree cleanly is actually a little tricky, here's a nice article on the intricacies of both the visual and logical trees.
I don't think any helper code exists to do this for you so implementing a recursive walk over the tree is required.