🚀 go-pugleaf

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