Is-a Versus Has-a

[uddipan@xxxxxxxxxxxxxxxx (Uddipan Bagchi)]

Hi,

Some heavyweights on this list like Randy and David have responded to this
poster. Now that the discussion has into some details, I have something to add
to my previous posting.

See inlined comments.

> > Aggregation
> > will allow you to selectively export those Engine methods that make sense
> for
> > a car.
>
> But aggregation means you now have that other class to create.  You know,
> the one that takes processor time?
>
> Why do this?  Because the car and the engine may be dependant on each other
> beyond what a deep inheritance architecture can solve.  There are situations
> were polymorphism can actually put your design in jeopardy.

Agreed. I wonder if one should put the words "wrongly done" somewhere in the
middle of that last sentence.

> How do you
> specify what engines can go in a truck?  Based on horsepower?  Torque?
> Displacement?  Physical Dimensions?  Compression?  How about a
> bigger/smaller truck?

The Constructor's contract should be able to decide clearly what types of
engines get fitted in a truck. I haven't understood your deviation into a
"Truck" example, but I definitely believe that we both are in sync that the
"Truck" class is not going to extend "Car". The truck class' setter methods with
respect to engine could query the engine on its type, horsepower, torque, etc.
and "reject" it if any incompatibility is found. IMHO, I would extend the Engine
interface to some sub-interfaces like SmallTruckEngine, LargeTruckEngine,
CarEngine etc. Accordingly, in the setEngine(Engine engine) method of class
SmallTruck, I would do a check for "if (!(engine instanceof SmallTruckEngine))
throw new IncompatibleEngineException("......");". Any comments.

> You can't, unless you design the Truck with some
> scope-breaking knowledge about engines.  As I said, you wouldn't want
> Programmer, Jr. coming along and dropping a top-fuel engine in VW with the
> logic, "if big is good, bigger is better".

Well, on the assembly line the guy who does the final fitment (the equivalent of
programmer, jr.) never gets to fit the wrong engine, because he is never given
any choice of selecting any engine of his choice. However, even if he were given
the choice (the real-life equivalent of programmer, jr. :-)), he will not be
able to make a "major mistake" as outlined in the one above, because the bolt
positions on the engine would not match the positions on the chassis. Hence, he
is forced to "reject" it - the equivalent of a RuntimeException. (A fertile mind
would be thinking of various "what-if" situations to dig holes into this
argument - like "what-if" somebody could couch an aero engine in the casing of a
VW engine, etc. ;-).  I have no ready answer for such situations. The software
equivalent would be of implementing SmallTruckEngine where one wanted to
implement LargeTruckEngine - probably, one should pack one's bags and head for
the nearest mountains).

> Again, there is a reason the auto manufacturers build cars without the
> ability to plug in different engines.  It is less flexible, but more
> efficient (for the car and the manufacturer).  Granted, we build software,
> and they build cars.  And we model systems other cars in our software,
> therefore, you cannot impose any single rule of "is-a", "has-a" or
> aggregation within all domains.

Well put. A little addition to the above may be in order - manufacturer's DO
make a single chassis on which they can plug in more than one engine - they DO
provide more than one type of hole combinations on the chassis so that more than
one type of engine can be fitted. The above seems perfect if one were to replace
"different" with "more than a few types of" :-).

> It's a myth-conception that your design isn't complete unless you have taken
> it to its most atomic level where you have fully aggregated it.  Do you know
> what happens if you break a design down to and beyond its most atomic level?
> It becomes very unstable.  Einstein proved that.
>

Pardon me. Could you explain that ?

>
> -T

- Uddipan.


---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx