When a class "has a" relationship with other class objects

Question

Let's say we have a Car, Wheel, and Brakes classes. A Car "has" four wheels so when an instance of Car is created, I want 4 instances of Wheels created at the same time. Likewise if I were creating a Motorcycle, I would want two instances of Wheels created. My question is how do I best create the Wheel instances and name them when creating a Car class?

Now suppose you want to assign the brakes to specific wheels- i.e.: FrontBrakes are attached to frontLeft, frontRight Wheels. Should I try to make a property in the Wheel class called AttachedTo? How do I assign ownership so to speak of the brakes to specific wheels?

public class Car
{
    public Car()
    {
        Wheel frontLeft = new Wheel();
        Wheel frontRight = new Wheel();
        Wheel backLeft = new Wheel();
        Wheel backRight = new Wheel();
        Brake frontBrakes = new Brake();
        Brake backBrakes = new Brake();
    }
}

public class Wheel
{
    public int Size;
    public string Brand;
    public Brake AttachedTo { get; set; }
}

public class Brake
{
    public string Type;
}

I have edited your title. Please see, "[Should questions include “tags” in their titles?](http://meta.stackexchange.com/questions/19190/)", where the consensus is "no, they should not". — John Saunders, Jul 09 '13 at 17:10
If you really wanted to do it right, you'd construct it exactly how it is in real life. A "wheel" consists of many different components made of many different materials, all of which do not assemble themselves but are put together by an outside actor. — , Jul 09 '13 at 17:11
The question you should be asking yourself is "how is the user of this set of types going to interact with it?" If someone is going to have a reference to `Wheel` in hand and they need to know what `Brake` is attached to it then there had better be a property called `Brake` on the `Wheel` class. And similarly for `Brake` -- if the user of `Brake` is going to need to know what `Wheel` it is attached to then there had better be such a property. If you don't have a real user-based scenario, don't add the feature. — Eric Lippert, Jul 09 '13 at 17:28
As a general rule, car analogies always suck when applied to software. — 500 - Internal Server Error, Jul 09 '13 at 17:49

score 3 · Answer 1 · answered Jul 09 '13 at 17:13

Definitely do not make an attached to property. I would just make the wheels a property on the appropriate class, but a property called attached is an awkward approach.

This looks like a good use of the Builder pattern.
http://www.dofactory.com/Patterns/PatternBuilder.aspx

In general use SOLID and prefer composition over inheritance. http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

score 0 · Answer 2 · answered Jul 09 '13 at 17:47

I would suggest that the car does not have brakes directly, the car has wheels and the wheels have brakes.

I would also suggest that you subclass Wheel with FrontWheel and BackWheel. If you dont, then at the very least, wheel should have a FrontOrBack property, and this needs to be specified in the constructor.

score 0 · Answer 3 · answered Jul 09 '13 at 17:56

Since the wheel positions and the brake types are constants, enums would probably be appropriate. Then wheel position and brake type would be properties in the wheel class. Make the braketype read only and set it in the constructor according to the wheel position.

When a class "has a" relationship with other class objects

3 Answers3