Ah yes, you see how new to this I am! I read it as a cWheel is-part-of a cCar.

In my world:
I never want to create a wheel in isolation.
A wheel is holding more specialised information about the car.
A wheel intrinsically knows which car it is connected to, by inheritance.
There are multiple wheels!

A collection of wheels would still need to know which car they are individually connected to.

Now I just sound like a raving lunatic... Great.

Quote:
I never want to create a wheel in isolation.

This is a textbook example of objection composition. The car is entirely responsible for its wheels - the latter cannot exist without the former. In the real world, of course, a wheel could be independent of a car, but it's a question of what you are modelling.

Quote:
A wheel is holding more specialised information about the car.

Such as friction, for example? Friction of a wheel could be a function of its wear and tear and other real-world properties. The overall friction force acting on the car is then a function of all of its wheels friction, and likely other properties.

Quote:
A wheel intrinsically knows which car it is connected to, by inheritance.

It would be better to avoid inheritance and to pass the car in to the wheel's constructor so that the wheel knows about its parent.

Quote:
There are multiple wheels!

Absolutely, do you restrict yourself to four at all times, or do you use a List<Wheel> (or similar container) to keep track of them? That way, you could actually lose a wheel or model a big 6-wheel artic' truck.

Example:

class Car{   public decimal Friction   {      get { return Wheels.Average(w => w.Friction); }   }   private List<Wheel> Wheels   {      get;      set;   }   public void AddWheel()   {      Wheels.Add(new Wheel(this));   }}private class Wheel{   public Wheel(Car parent)   {      Parent = parent;   }   public decimal Friction   {      get { return 1.0f - Wear; }   }   public decimal Wear   {      get;      set;   }   public Car Parent   {      get;      private set;   }}

It's beginning to look like these OOP techniques aren't quite as useful as I had imagined... which is a pity really.

An awful lot of my code depends on strict heirarchical structures, making inheritance seem like it truely is a panacea!

Using DI to short-cut pathways from the top to the bottom of my code tree seems messy, but I'll bow to your collective experience and follow the pattern...

Thanks for the help guys. [smile]