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.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 2 Dec 92 14:58:34 GMT From: pipex!bnr.co.uk!bnrgate!nott!cunews!cunews!knight@uunet.uu.net (Alan Kni ght) Subject: Re: OOD, Ada, and Inheritance Message-ID: List-Id: In <1992Nov30.230312.8279@cis.ohio-state.edu> weide@elephant.cis.ohio-state.edu (Bruce Weide) writes: >In article <1992Nov26.012530.7587@fcom.cc.utah.edu> >val@news.ccutah.edu (Val Kartchner) writes of an example where >polymorphism is useful. But unfortunately this example does not >address the question I was asking, especially the part underlined >below. At great risk I therefore repeat the challenge, which was >prompted originally by some complaints about the quality of the >examples in J. Rosen's paper that recently appeared in CACM: >>: 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. > ------- OK, here are 3, and although I do not provide the abstract specification I think it is clear for all of them that such a specification could exist. Two of them are quite general, while the third is domain-specific. 1) I/O The ability to write to files, pipes, the screen, etc. interchangeably at run-time is extremely useful, and practically everybody does it this way. 2) Matrix libraries There are a number of different representations of matrices (sparse,dense,symmetric,asymmetric,definite,upper triangular, real, double, complex). These differ very significantly in representation and in the implementation of operations on them, but they all follow the same abstract behaviour of a matrix. It is clearly nice to be able to write code that operates on any matrix, and which will use the appropriate algorithm. In fact, now that I think about it, numbers themselves are another example. Reals and doubles have identical abstract behaviour, and complex numbers add only a few additional functions while leaving the others unchanged. They clearly have different representations and operations must take this into account. 3) Finite element types I work in finite element analysis, in which we have a number of different "element types", which can vary with the geometry of the element or with its properties. Examples would be the 8-node brick, 4-node tetrahedron, 27-node brick, etc. Without going into too much detail, the routines for solving finite element problems expect the same abstract behaviour from these elements (that they give the right answer) without regard to the internal structure of the elements. I can elaborate on this if anybody is interested. I hope these are the sort of examples you are looking for. -- Alan Knight knight@mrco.carleton.ca +1 613 788 2600x5783 Dept. of Mechanical and Aerospace Engineering Carleton University, Ottawa, Ontario, Canada, K1S 5B6