This is a general best practice question about creating parent / child relationships with objects. 

Let's say I have Wheel and Car objects and I want to Add a Wheel object to car object

```
public class Car{

    private List<Wheel> wheels = new List<Wheel>();

    void AddWheel ( Wheel WheelToAdd)
        {
            wheels.Add(WheelToAdd)
            //Some Other logic relating to adding wheels here
        }
    }
}

```

So far so good. But what if I want to have a Car property of my wheel to say which parent car it relates to. Something like this

```
 public class Wheel {

     private Car parentCar;
     public Car 
     {
        get
        {
         return parentCar
        }

  }

}

```

When adding the wheel to the car, at which point would you set the parent property of the Wheel? You could set it in the Car.AddWheel method, but then the Car Property of the Wheel object would have to be Read/Write and then you could set it outside of the AddWheel method, creating an inconsistency.

Any thoughts, many thanks in advance
['https://Stackoverflow.com/questions/3875021', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/425095/']
A better design methodology, (Domain Driven Design) specifies that you should first decide what the domain model requirements are for these entities... Not all entities need to be independantly accessible, and if `Wheel` falls into this category, every instance of it will always be a child member of a `Car` object and you don't need to put a Parent property on it... `Car` becomes what is referred to as a *root entity*, and the only way to access a `Wheel` is through a `Car` object.

Even when the `Wheel` object needs to be independantly accessible, the domain model requirements should tell you what the usage patterns require. Will any `Wheel` ever be passed around as a separate object, without it's parent ? In those cases is the `Car` parent relevant? If the identity of the parent `Car` *is* relevant to some piece of functionality, why aren't you simply passing the complete composite `Car` object to that method or module? Cases where a contained composite object (like a `Wheel`) must be passed on it's own, but the identity of the parent (the object it is part of) is needed and/or relevant, are in fact not a common scenario, and approaching your design using the above type of analysis can save you from adding unnessary code to you system.
Question: Can the Wheel instance be assigned to a different Car instance later in time? 

1) If yes, the expose a public method to set the parentCar. You *could* make it a fluent method, for ease of code:

```
public class Wheel 
{
    private Car parentCar;

    public ParentCar 
    {
        get
        {
            return parentCar;
        }
    }

    public void SetParentCar(Car _parentCar)
    {
        parentCar = _parentCar;
        return this;
    }
}

```

Where you assign add the wheel, make the assignment:

```
void AddWheel ( Wheel WheelToAdd)
{
    wheels.Add(WheelToAdd.SetParentCar(this));
    //Some Other logic relating to adding wheels here
}

```

2) If not, just set the parent in the constructor.

```
public class Wheel 
{
    private Car parentCar;

    public ParentCar 
    {
        get
        {
            return parentCar;
        }
    }

    public Wheel(Car _parentCar)
    {
        parentCar = _parentCar;
    }
}

```