Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!omahony
From: omahony@swift.cs.tcd.ie
Newsgroups: comp.sw.components
Subject: Re: OOP as a mechanism for software reuse
Message-ID: <7060.26c022e6@swift.cs.tcd.ie>
Date: 8 Aug 90 14:34:13 GMT
References: <27705@athertn.Atherton.COM> <71800004@m.cs.uiuc.edu> <620@.tetrauk.UUCP> <7057.26b57e9c@swift.cs.tcd.ie> <707@tetrauk.UUCP>
Organization: Computer Science Department, Trinity College Dublin
Lines: 43

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

My point was that even though the component author would like to produce a
highly reusable  software component - the design/coding of this component as
a class is implicitly fixing the scope of reuse. Just like libraries of
procedures, there is a fixed part and a variable part.  One could summarize
recent progress as follows:

Component Representation		Change mechanism

Procedure				Parameter list

ADA ADTs				parameter list + generics

Classes					parameter list [+ generics]
					+ inheritance

> 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.
> 
> inheritance which says "A is like B except ...", meaning the sub-class is NOT
> going to conform to some aspects of its parent. 

Even in cases where you can specify "A is like B except..", you have 
advanced to:  parameter list [+ generics] + more flexible inheritance

and you have deprived yourself of some of the encapsulation advantages
i.e. you would usually have to know quite a bit about the innards of a class
before "removing" some of it's behaviour 


In conclusion I suggest that as a representation of reusable components,
Classes are *probably* better than procedures, but they will not
provide quantum leaps in reuse rates for the same reasons that procedures
didn't (outside of confined domains e.g. IMSL).

This is difficult to *prove*, as studies have not yet been published of
experiences with some of the better OOP class libraries (e.g. EIFFEL).
Anybody got any *hard* info on this?