Re: OO Idiom: Interfaces for derived classes

[mmann@ibm.net (Gerd Moellmann)]

Jean-Pierre Rosen <rosen@EMAIL.ENST.FR> writes:

> At 15:34 21/03/1996 +0100, you wrote:
> >Dear Ada users,
> >
> >I am currently investigating Ada for OO programming, and I would like
> >to ask you for your comments wrt a question of programming style
> >
> >After studying the ARM and "Ada as a second language" (Normal
> >H. Cohen, 1996), I came to the conclusion that Ada as a language does
> >not directly address/ has no apparently obvious approach wrt
> >
> >   whether it is desirable to separate interfaces for clients of
> >   classes vs. derived classes, and if so, how to implement the
> >   separation.
> We discussed this issue at length during some Ada-France meeting. Here is a
> summary of our conclusions.
> 
> There are two views of derived classes. Suppose you are the provider of some
> reusable software components, and you want to provide guarantee on your product.
> 
> 1) The product as a whole is a hierarchy of classes (for example, a set of
> widgets).  For design as well as for efficiency reasons, it makes sense to
> have derived classes defined in child packages, and since it is YOUR
> product, you don't mind derived classes accessing the parent's private part.
> Actually, without hierarchical libraries, you would provide the  whole stuff
> as one package. Child packages make it just more convenient  for the user to
> "with" only the features that are needed.
> 
> 2) The product is a set of classes, that are INTENDED to be extended by the
> user. The user should not do this in child packages, because you cannot
> guarantee your product if the *user* accesses the private part of the
> parent. Actually, the  guarantee would have a clause "guarantee is void if
> classes are derived in child packages", similar to a TV set with a clause
> "guarantee is void if the user opens the back pannel".
> 
> So both views serve are useful, for different purposes.

I fully agree with the second paragraph, of course, but I think that
the first approach is really only useful under rare circumstances: The
reason is that I view the class hierarchy developers as just another
set of users of that hierarchy.  For a non-trivial, evolving class
hierarchy the second approach will bring the same benefits during
library development that it has when the library is shipped: we
avoid the void guarantee.






-- 
Gerd Moellmann, Altenbergstr. 6, D-40235 Duesseldorf, Germany
Software Development & Consulting
Internet: mmann@ibm.net / CIS: 100025,3303 / Phone: +49 211 666 881