tags:

views:

84

answers:

5

Given the code:

class Car{
   Engine engine;
}

class SportCar extends Car{
   SportChair chair;
}

Is it valid to say that 'SportCar "has-a" Engine and a SportChair'?
Or the only valid affirmations are: 'SportCar "has-a" SportChair' and 'Car "has-a" Engine' ?

+1  A: 

If a SportCar is-a Car and a Car has-a engine, seems to me that SportCar has-a engine. Perfectly valid.

Gann Bierner
A: 

Depends -- I wouldn't replicate the relationship in a UML diagram, but conceptually SportsCar has a(n) engine because it derives from Car.

tvanfosson
+3  A: 

I don't have any definite sources for this, but my gut feeling is that the relationship DOES apply to inherited members.

In your example, SportCar "is-a" car, therefor it "has-a" engine.

This could be related to the Liskov Substitution Principle, where a super-type should be replaceable by any of its subtypes. In this case the super-type "has-a" engine, in order for sub-types to follow the LSP they must recognise that they also have an engine.

This should not only follow for members of the class, but for the behavior and state in general - a class should not inherit from another unless it makes sense for every aspect to be inherited. I.e. in your example, if Car had a method "attachBabySeat()", it would not really make sense for SportsCar to inherit from it. Likewise a member protected BabySeat[] babySeats does not make sense for SportsCar.

The exception to this, in Java, is private or "package-private" (aka default) member variables. These are generally implementation details that are not part of the abstraction. Subclasses can not access these fields and so I wouldn't consider a private member to be part of the subclass' "has-a" relationship.

In terms of the Java language, when a subclass is created, the superclass is also constructed (either implicitly or explicitly). So when a superclass has a private member, this is still part of the subclass object in terms of memory, JVM etc. For instance, a method on the superclass which uses a private member, can be called from the subclass without problem. So at some level, you could argue that subclasses do "have-a" private field of the superclass, but I'd argue this is at a physical level, not a conceptual one, and can be disregarded.

Grundlefleck
There is trouble in the code in that it exposes fields. If `Car` was an interface with a `getEngine` method, the relationships would still hold.
Tom Hawtin - tackline
My point is not about encapsulation, and it seems logical that the SportCar has an engine but I wanted to know if it is valid to say that from the language point of view.
Robert
Is the question specifically about package-private access, as in the example? If that or private I'd say no - subclass relationship is not a "has-a". For public/protected I'd say yes. Like I said though, this is my gut feeling, nothing I can attribute to any source, unfortunately.
Grundlefleck
A: 

Yes, a SportsCar is a Car and therefore has an engine. This is an example of the composite design pattern.

mR_fr0g
A: 

No. It is not valid to say that SportsCar has-a Engine. Especially in the example where Engine has default access. I guess the best way of looking at this would be the following.

I am going to use a real world example and I think that generally helps.

A Moose is a type of Deer.

Deer have 2 eyes therefore Moose have 2 eyes.

An injured Moose has 1 eye.

An injured Moose is a type of Moose.

Woot4Moo