From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9eccdbc9cfa1c9b9 X-Google-Attributes: gid103376,public From: mmann@ibm.net (Gerd Moellmann) Subject: Re: OO Idiom: Interfaces for derived classes Date: 1996/03/22 Message-ID: #1/1 X-Deja-AN: 143714007 distribution: world sender: mmann@ibm.net references: <199603220939.KAA00777@email.enst.fr> organization: None x-nntpdaemon: changi 0.9 for OS/2 newsgroups: comp.lang.ada Date: 1996-03-22T00:00:00+00:00 List-Id: Jean-Pierre Rosen 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