Is-a Versus Has-a

[uddipan@xxxxxxxxxxxxxxxx (Uddipan Bagchi)]

Hi,

See inlined comments.

friedman_hill ernest j wrote:

> There is a very important distinction here. The exception does NOT
> tell PJ he made a mistake. It tells (depending on circumstances) the
> Test team or the Customer that PJ made a mistake.

It is going to be caught at Testing, unless the Test specs have been
written by PJ or his close friends. After it is fixed, as David pointed
out, the only remaining overhead would be of the runtime type checking.

> The Smalltalk-flavored folks, together with people
> used to programming in largely untyped languages like Perl and BASIC,
> will often think along the same lines as David here: catching problems
> at runtime is Good (something that cannot be argued with.)

Amen :-)

> These people know that although catching errors at runtime
> is good, *catching them at compile-time is infinitely better.* The
> reason is that runtime errors happen on user's desktops, while
> compile-time errors happen on programmer's desktops.

No arguments on the superiority of compile-time checking. But, isn't it
true that gunning for compile-time checking derails polymorphic calls ? I
would imagine that compile-time checking and dynamic binding are at
logger-heads with each other with regard to flexibility. (I do hope that
my morning coffee has not worn off ;-)). Please do not rush, and see below
for an explanation.

> Strong typing is the alternative. A constructor should never accept an
> Engine as an argument, then throw an exception unless it gets a
> TruckEngine. It should instead simply accept a TruckEngine.

Perfect, as far as the constructor goes. Imagine now that you have created
a Truck with a TruckEngine, and while driving you make a stopover, and
want to change the engine. Also, assume that Truck extends from a
GenericFourWheeler which has a setEngine(Engine) method. (At the time of
making the GenericFourWheeler we may not have known that it would be
extended to a Truck. Same for the Engine interface and the TruckEngine
interface.) The Truck class would override the setEngine(Engine) method
and MUST do a runtime type check to see that a TruckEngine is being fitted
to it. Can we avoid it ?

> The resulting application will contain less code, run faster, and be
> more
> reliable, all because the runtime checks have been replaced by
> compile-time checks.

Agreed. But, I guess, at the cost of flexibility. Needless to say, the
amount of required flexibility would depend on the design. If our design
DOES NOT call for the following, then it is fine to only go in for
compile-time checks:
GenericFourWheeler gfw = new Truck(...,...,...,...);
Performance performance = gfw.runOnRaceTrack();
if (performance.notUptoMark()){
    // replace engine
    Engine newEngine = EngineFactory.makeEngine("Truck","400HP",...);
    gfw.setEngine(newEngine);
}

> Buy and read "Writing Solid Code" by Steve
> Maguire. This is the best Java progamming book I've ever read, for a
> book that doesn't mention Java, anyway (it predates Java by a few
> years.) The basic thesis of the book is that if you design your code
> right, you can reduce the number of bugs left for testers (and users)
> to find to near zero.

May I suggest that a few hundred copies of this book be donated to
Micro$oft. However, if I am allowed, I may question the "basic thesis of
the book" - there may be a few corporations and individuals whose daily
bread seems to be in jeopardy :-).

- Uddipan.


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