Re: OOD, Ada, and Inheritance

[pipex!bnr.co.uk!bnrgate!nott!cunews!cunews!knight@uunet.uu.net (Alan Kni]

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