Best way to implement parent child relationship

Question

I am working on a CAD application, where I have block entity. Each block entity have a list of child entities. When these entities are rendered, every block entity knows about its child entity (as it can figure out the child entity in the list), and hence when block entity is selected, the whole block entity along with its child entities gets selected. However, child entity does not know the parent block and other child entities of that block, and due to this when child entity is selected, I cannot get the whole block entity along with all its child entities selected.

As a fix to this problem I created a property in child entities to hold the reference of parent block entity. But, then there might be some issues with cross-referencing and making my data structures error prone.

For Ex: Having a Copy command, somebody working on these data structures few days from now, might just copy the same parent while creating a copy of child entity. However, new copy should belong to some other parent block.

Please suggest the better way to implement this relationship, so that when a child entity is selected I can select whole block entity along with all its child entities.

public class BlockEntity
{
    public List<ChildEntity> Children = new List<ChildEntity>();
}

public class ChildEntity
{
    public readonly BlockEntity Parent;
}

look for disjoined set structure and union-find algorithms – ne2dmar Nov 05 '13 at 14:48 — ne2dmar, Nov 05 '13 at 14:48

Mike Webb · Accepted Answer · 2014-02-05T14:31:39.703

I have recently come across this issue. I, and others I talked with, came up with two choices:

Do what you are doing with the Parent<-->Child relationship, both knowing about each other.
Have a Parent-->Child relationship and make everything be handled at the parent.

Both are viable solutions, but both have their issues. The first case, what you are doing, seems better and Microsoft seems to use this with their TreeView/TreeNode and DataTable/DataRow/etc. objects for example, because they can each reference back to their respective parents.

Maybe add constraints to the parent, such as not allowing access to the parent's child-collection directly, but only allowing an AddChild function in which you can do the necessary linking. Or do what @Irfan suggests and have the child require you pass the parent to its constructor. Constrain your copy method as well, but always document everything to remove as much confusion as possible.

The later of the above examples is a little easier as everything is always accessed from the parent. This was our solution. We have many functions in the parent to check for and manage the children within. So in this case you would select the child in the CAD app then go to the parents and check in their collection to see if the child exists there. If it does you select the parent and the rest of the children.

It's up to you, but in each case you need to add constraints and error checking to make sure things happen as close to your desired way as possible. Hope this helps.

score 1 · Answer 2 · answered Nov 05 '13 at 15:01

what reference problems will you get by creating a reference to parent? With this readonly reference which can only be set during construction of the object I see no problem at all.

The Contructor (I am sure you know) looks like:

public ChildEntity(BlockEntity p)
{
  Parent = p;
}
//Test just to show Parent can not be assigned elsewhere
public void test()
{
//this line below will show compile error
  Parent = new BlockEntity();
}

Do you think there would be some problem with this. The list is a loose reference so there is no stack overflow exception.

Best way to implement parent child relationship

2 Answers2