![]() |
Examples 6.2:
|
The simplest of abstract class definitions is found in the pervasive abstract class $OB which, without proper commenting for the purposes of illustration could be written simply as
This has no arguments, no sub or super types and no features.
One of the simplest abstract classes including a feature in the Required Library is
Inheritors from this abstraction are required, whatever other features may be defined, to implement this hash function returning a cardinal number. Note that no implementation detail is specified here - the implementation class is perfectly free to implement any hash function. Well!! not quite!!!
One of the cardinal properties of a hash function is that it will ideally not produce the same result for different values of the class, nor will it produce different values for successive invocations of the function on the same object!
One of the great benefits of formal definition is that this can be expressed algebraically so that an implementer has to 'obey the rules'. Although Sather itself does include pre and post condition features it does not allow them to be used in an abstract class signature. This is one disadvantage of the language. Using non-Sather notation (eg Raise, vdm-sl or Z) such a specification can be formally produced.
Simple abstract class sub-typing is seen in the pervasive class $ATTACH which is in essence specified as
Classes which model general concepts in relation to various kinds of possible object are usually parameterised. The most obvious example is almost any form of container (see the Container section of the Required Library for many examples). A possibly less obvious example is that of a colour palette. It could have various densities of grey, it could be a palette of RGB colour values for screen display - or a palette of CMYK colour values for printing on paper. The concept of a palette as an indexed colour description is common to all of these so the following abstraction could be defined.
which would define various look-up operations, perhaps conversion to other forms of palette, etc - all in relation to an unknown instantiation class which is given the parameter name COL for use in defining the appropriate signatures.
The palette example could be extended to use any variety of a particular colour format. If this were the case then it would be relatively easy to define another abstraction -
and from that a few child classes
end
so that at the end of all this the palette abstraction could be defined in terms of $COL as
which requires that any of the 'real' colour classes which may be used in instantiating a class inheriting from $PALETTE must themselves conform to $COL - whether they be RGB or CMYK or ... colour models!!
![]() |
Specification Index | ![]() |
Language Index | ![]() |
Abstract Classes | ![]() |
Section 6 Index |
Comments
or enquiries should be made to Keith Hopper. Page last modified: Monday, 22 May 2000. |
![]() |