Path: utzoo!attcan!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: <707@tetrauk.UUCP>
Date: 3 Aug 90 09:44:10 GMT
References: <27705@athertn.Atherton.COM> <71800004@m.cs.uiuc.edu> <620@.tetrauk.UUCP> <7057.26b57e9c@swift.cs.tcd.ie>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 64

In article <7057.26b57e9c@swift.cs.tcd.ie> omahony@swift.cs.tcd.ie writes:
> [I wrote]:
>> There will be a recipe in the library for a plain cake.  If you want to write a
>> recipe for a fruit cake, you just write "Proceed as for a plain cake, but add a
>> handful of fruit in the final mixing" (this is not a recommendation for my
>> cakes!).  You "inherit" the plain cake recipe from the library, and produce a
>> descendant recipe.  This will create a different object, and it is the
>> _objects_ which are the "components";  they are created at run-time and behave
>> according to their class descriptions (i.e. the programs).  You don't make a
>> good fruit cake by buying a plain cake from the shop and then trying to stuff
>> fruit into it when you get home.
>
>I like this analagy - now suppose you want to make a loaf of bread, or an
>omlette.  Even though both of these involve gathering materials together
>in a bowl, agitating them and then applying heat (am I making you hungry!)
> - they are not instances of the class 'cake'.
>
>My basic point is that the use of classes/objects as reusable components
>suffers from similar (though not as severe) problems to procedure libraries.
>The author of the component divides the functionality into a fixed part
>(the class decription/ procedure body) and a variable part (the
>parameter list/ the inheritance mechanism).  The problem occurs when a
>potential (re-) user of the component has an application for about 90%
>of the fixed part.

There are two problems here.  The last paragraph suggests that the author of a
component decides what may inherit from it, and how.  In other words 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.

The second problem gets back to an issue I mentioned earlier in my previous
article, i.e.  what is inheritance?  The nice theoretical, text-book concept
says that the sub-class has all its parent's properties, plus some more.  Thus
an object of the sub-class must be prepared to do everything its parent can do
- it can't refuse to inherit some of its parent's behaviour.  This means the
object exhibits total conformance to its parent, and allows a compiler to treat
classes and types as synonymous making type conformance checking nice and easy.

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.  An example I was quoted
recently was the case of a square inheriting from a rectangle;  not many people
would argue with that concept.  But suppose the rectangle supports an
"elongate" operation which changes its aspect ratio - you can't do that to a
square without changing it back into a rectangle.  The implication is partial
inheritance.  The result is that the class inheritance tree and the type
conformance tree are not the same, and static type checking in a compiler
becomes a whole new ball game.

The only convincing statement I've seen which seriously addresses this issue is
a recent re-posting by Bertrand Meyer in comp.lang.eiffel of a paper originally
written about a year ago.  The article was posted in two parts because of size,
and the references are <385@eiffel.uucp> & <386@eiffel.uucp>.  There is also an
article which covers the Eiffel type system in general, ref. <387@eiffel.uucp>.

I won't waste time & bandwidth quoting from these articles here, If you're
interested in this problem, I seriously suggest you read them.

-- 
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