From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_40,MSGID_SHORT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 4 Dec 92 08:54:53 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.amer ican.edu!news.univie.ac.at!hp4at!mcsun!uknet!root44!hrc63!mrcu!paj@ucbvax.Berke ley.EDU (Paul Johnson) Subject: Re: OOD, Ada, and Inheritance Message-ID: <2284@snap> List-Id: >>>>: Can someone give me a good >>>>: example of a case where one wants to have multiple implementations for >>>>: SIMILAR but NOT IDENTICAL abstract behaviors, AND for which this >>>>: abstract behavior is specified formally and in implementation-neutral >>>>: terms (or at least could be in principle)? ... >>>>: As part of the example I would, of >>>>: course, expect to see the abstract specification of that part of their >>>>: behavior that these different implementations would all have in >>>>: common. I'm not sure what is meant by `similar but not identical' in this context, so I'll talk a little more generally. The classic example is of course the graphic drawing library, where all the drawable classes must have common behaviour such as being drawable, rotatable, expandable, stretchable etc, but some classes have additional behaviour, such as a drawable text class which also has features that allow the text to be altered. In this case the drawable features for the various classes are similar (they draw the shapes) but not identical (each shape is different). Or if you want the same logical behaviour with different implementations, consider the single and double linked list. A developer may not know when coding starts which implementation to choose. If both single and double linked lists share a common interface then the developer can pick one safe in the knowledge that switching to the other is a trivial change. If your data structure library has tables of objects and lists of objects then you could also have a class which inherits from both table and list. This allows you to pass this to a routine that expects a list and to one that expects a table. It is important to remember that inheritance is not about reusing the implementation of your class (you can do that by delegation). It is about reusing the *interface*, because that way you get to reuse all the other code out there that uses the interface. Paul. -- Paul Johnson (paj@gec-mrc.co.uk). | Tel: +44 245 73331 ext 3245 --------------------------------------------+---------------------------------- These ideas and others like them can be had | GEC-Marconi Research is not for $0.02 each from any reputable idealist. | responsible for my opinions