Path: utzoo!attcan!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@.tetrauk.UUCP (Rick Jones)
Newsgroups: comp.sw.components
Subject: Re: What is a reusable software compone
Message-ID: <620@.tetrauk.UUCP>
Date: 30 Jul 90 09:33:10 GMT
References: <27705@athertn.Atherton.COM> <71800004@m.cs.uiuc.edu>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 76

In article <71800004@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson)
writes:
>
>I think that Paul Sander's B-tree abstraction is a pretty good
>reusable component.  However, I think that Bill Ogden has a
>good point.  Bill's basic point is that it is really more
>important to reuse specifications than it is to reuse
>implementations.  Of course, we need to provide implementations
>for our specifications, but the user should think mostly of the
>specification and not the implementation.  B-trees are an
>implementation, while almost-constant functions are specification.
>
>Further, I take the point of view held by the object-oriented
>community that it is not particular kinds of components that are
>important, but rather sets of components and their relationships.
>The advantage of concentrating on specification is that you end
>up with lots of components that share the same specification.
>When you learn one, you have learned something about all of them.
>Also, it becomes easier to replace one component with another
>because they will share specification.  Thus, it becomes easier
>to write utilities that work with any of the related components.

I see this as the key difference between the OO concept of re-use, and the
procedural library approach.  In both cases, software is certainly re-used, but
the whole OO thing is really about specification and design.

OO languages provide a way of moving from the design stage to the coding stage
without the sort of traumatic paradigm shift which results in design
information getting lost.  Further, OO encourages _design_ re-use as much as
code re-use.  Abstract classes provide one means to do this, so that you can
have an abstract structure (B-tree or whatever else you want), and different
implementations inheriting from it.  The program components which use the
structure can use the abstract type, except where the structure is actually
created, which is where the decision has to be made;  this should only be at
one place.  If you decide to use a different implementation of the structure,
you should only need to change about one line of code.

The other important re-use issue is partial re-use.  You have a component which
is nearly what you want, but you need a few variations for your application.
This is what inheritance can give you.  This leads into a problem which I don't
think is resolved, or even fully understood, regarding what you actually
inherit.  Is it an abstraction (i.e. a consistent interface) or an
implementation (i.e. some useful chunks of code)?  A statically type-checked
language assumes and/or requires descendant classes to conform to their
parents;  but do you always want that?  It sounds like a good case for dynamic
type checking (Smalltalk and Objective-C users can afford to smirk here :-).
	[ Extended discussion of inheritance aborted - please pick it up if
	  you're interested. ]

Although you can take a very object-oriented approach to software with a
standard procedural language, careful design, and good coding discipline, the
concepts of abstract types and re-use by inheritance really require a true
object-oriented language to make them work for you.

I find it helps to think of programs as recipes rather than actual components.
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.

In summary, I believe it's better to treat software as detailed component
designs, rather than actual components, and thus software re-use _is_ design
and specification re-use.  The major benefit of object-oriented languages, and
the way of thinking which they (should) promote, is to bring the ideas of
"design" and "code" closer together so that they can be treated as different
levels of the same thing.

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