tags:

views:

70

answers:

3

If I say a car has a certain number of tires, a tire size, a tire brand, then I am guessing I could make a class like this:

public class Car
{
    public int TireCount {get;set;}
    public float TireSize {get;set;}
    public string TireBrand {get;set;}
}

On the other hand, I could make Tire a class and then make that a property of the class Car like so:

public class Tire
{
   public int Count {get;set;}
   public float Size {get;set;}
   public string Brand {get;set;}
}

public class Car
{
    public Tire tire {get;set;}
}

What is the better way? How deep do I take the relationship? Is it possible to over Object if that there is such as saying?

+2  A: 

Personally, I would have "Size" and "Brand" be members of Tire, since they're specific to a specific type of Tire.

Car, on the other hand, should probably have a collection of Tires, since you could (theoretically) have multiple tires, of differing types.

I would do it more like:

public class Tire
{
    public float Size {get;set;}
    public string Brand {get;set;}
}

public class Car
{
    public IList<Tire> Tires {get; private set;}
}
Reed Copsey
Agree on the collection. Just made a quick sample.
Xaisoft
@Xaisoft: I just edited and put in code for you...
Reed Copsey
Thanks. This all stems from me looking at some DICOM API's written in c# and they seem like they take every aspect of the DICOM file and make it an object.
Xaisoft
@Xiasoft: That's typically good - it makes the API flexible.
Reed Copsey
@Reed Copsey - Didn't think about that. Thanks for the tip again.
Xaisoft
Man...I'm getting pounded by the big boys today. First Jon Skeet, then Joel Coehoorn, and now Reed Copsey. :-P
Justin Niessner
@Justin: Hehehe, no pounding from me! You basically wrote the same thing I did ;)
Reed Copsey
+3  A: 

As deep as it makes sense to go for your application.

In your example, your Car class would have multiple properties related to tires...so a Tire class (or collection of Tires) makes sense. Probably something like:

public class Tire
{
    public float Size {get; set;}
    public string Brand {get; set;}
}

public class Car
{
    public List<Tire> Tires {get; private set;}
}

Then you could do:

Car myCar = new Car();

// Some initialization here

int tireCount = myCar.Tires.Count();

To get the count of tires.

Justin Niessner
Any particular reason why you used List<Tire> and Reed used IList<Tire>?
Xaisoft
Because he made his code more Generic (and arguably higher quality). With his, you can implement any type of Collection that implements the IList interface without breaking binary compatibility. Mine was merely a fast example.
Justin Niessner
@Xaisoft: Typically, you want to use the interface or class in your public API that puts the least restrictions upon you. If you are going to want "list-like" semantics, that'd be IList<T>. If you only need to iterate through a collection (ie: use foreach), then use IEnumerable<T>. This lets you use any form of collection internally, and change it any time you want.
Reed Copsey
+1  A: 

I would go until I'm sure I wont have to duplicate the information

in that case I might need an instance of the tire only

Fredou