Should i have Parent or ListOfChild property in Hierarcical object

Question

i have a doubt on how to model a hierarchical object for storing a Tag tree:

thinking to db table i can use

public class Tag
{
    public int Id { get; set; }
    public int Description { get; set; }
    private readonly Tag parentTag;
    public Tag ParentTag
    {
        get
        {
            return parentTag;
        }
    }
}

the code from parent property come from Hierarchical object and AutoFixture to avoid circular reference

but as suggested there, and thinking to object maybe is better having child collection instead of parent: naturally speaking a tag can have a collection of child tags make more sense So my class become:

public class Tag
{
    public int Id { get; set; }
    public int Description { get; set; }
    private IList<Tag> childTag;
    public IEnumerable<Tag> ChildTag
    {
        get
        {
            return childTag.remove(0);
        }
    }
}

but in this way how can i move a tag in the tree: that is change Parent property on my tag?

EDIT

thinking about what my object will have to do I would say:

• create new root
• create new child
• move a node
• say if a node is a child
• say if a node is a root
• get all child of a node (recursivly)
• delete child (recursivly and not)

I have to allow the user to create trees of Tags for tagging documents that are stored would like to achieve something similar to the tag collection used by lightroom for pictures

Answer 1

Whether you have a Parent property on the child, or a Children property on the parents, should depend on what your code needs to do.

Try this: remove both properties and see if anyone cares.

---

Responding to your update. I use test-driven development whenever possible. The tests become an executable definition of "what does the program need to do" (A: it needs to pass all the tests). The process of making the tests pass then forces you to implement your code in the simplest way possible that still passes all the tests.

You can do the same thing without TDD by first writing a set of client code that calls your class, then only implementing what's required in order for the client code to work. I recommend that you remove both properties in question, then start writing your code. You will quickly determine whether or not you need one, or both, properties.