Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.sw.components
Subject: Re: OOP and re-usable cakes
Message-ID: <714@tetrauk.UUCP>
Date: 6 Aug 90 14:40:38 GMT
References: <27705@athertn.Atherton.COM> <71800004@m.cs.uiuc.edu> <620@.tetrauk.UUCP> <7057.26b57e9c@swift.cs.tcd.ie> <707@tetrauk.UUCP> <382@taumet.com>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 69

In article <382@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>rick@tetrauk.UUCP (Rick Jones) writes:
>
>>The scope of re-use is being fixed in the design of the component.  Although some
>>object-oriented languages encourage this viewpoint (C++ being one of the worst
>>offenders, IMHO), for re-use to be valuable in the long-term classes need to be
>>re-usable in ways which the original author never envisaged.
>
>I'm not sure of what you are accusing C++ here.

Sorry! I'm not trying to start an object (class?) war.  Ultimately, anything is
possible in any language, but I do believe that the characteristics of a
language influence the design of the software;  in fact, I take the view that
coding is just the final step in the design process.  Yes, you _can_ make
everything virtual, but how many C++ programmers actually _do_, in anticipation
of something they haven't yet thought of?  This isn't to say I'm accusing C++
programmers of being wrong, per se, either.  Perhaps it's just human nature to
use a tool in the most obvious way which the tool itself suggests;  if you make
a corkscrew in the shape of a hammer, someone is bound to open a bottle by
smashing the top off!  (this isn't a good analogy, but it was off the top of my
head).

>>This approach doesn't always reflect reality, though.  You often do want an
>>inheritance which says "A is like B except ...", meaning the sub-class is NOT
>>going to conform to some aspects of its parent....
>
>Again, you can do this in C++.  It is possible to eliminate some of a
>base (parent) class's functionality within a derived (sub) class.  You
>simply override the base class function in the derived class with an
>empty function which is private.

But it's not that simple if you are going to use polymorphic references, which
for me is what an effective class-based design is all about.  If you assign an
object of the sub-type to a pointer variable of the parent type, the compiler
will assume that all the parent's functionality is available on all objects
which may be attached to it.

>While I understand your example, I don't agree it is good design.  You
>have an "extend" operation for a rectangle which changes its aspect
>ratio, something not possible for a square.  I suggest instead something
>like this inheritance graph:
>
>			quadrilateral
>			______|______
>			|           |
>		rectangle	trapezoid
>		____|____
>		|       |
>extensible_rectangle	square

The example is certainly contrived, but your solution illustrates my point.
Suppose the inheritance tree was already in place, without square and with a
single (extensible) rectangle, and your task was to implement square.  Your
solution requires a re-arrangement of the existing hierarchy.  Although
ultimately desirable, it is not helpful if it has to be done in order to solve
the immediate problem - it's making re-use more difficult.  Good re-use is
achieved by finding and implementing the "nearest fit" to what is already
there, even if not perfect.  The ability subsequently to re-arrange parts of
the hierarchy without having to change things which derive from them is equally
important.

There will be many real problems of this type which are far less trivial.

(Ducking flames: holiday period 3 weeks, expiry period 2 weeks :-)

-- 
Rick Jones					You gotta stand for something
Tetra Ltd.  Maidenhead, Berks			Or you'll fall for anything
rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick)	     - John Cougar Mellencamp