Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!omahony
From: omahony@swift.cs.tcd.ie
Newsgroups: comp.sw.components
Subject: Re: OOP and re-usable cakes
Message-ID: <7057.26b57e9c@swift.cs.tcd.ie>
Date: 31 Jul 90 12:50:36 GMT
References: <27705@athertn.Atherton.COM> <71800004@m.cs.uiuc.edu> <620@.tetrauk.UUCP>
Organization: Computer Science Department, Trinity College Dublin
Lines: 24

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

Comments?