![]() |
Examples 6.2:
|
![]() |
The simplest of abstract class definitions is found in the pervasive abstract class $OB which, without comment solely for the purposes of this 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 deterministic hash function.
A deterministic hash function 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'. Sather itself does not include pre and post condition features in an abstract class signature (see the TODO in the specification for more on this point). 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
which requires that any implementation class inheriting from $ATTACH shall implement the features defined in the $ATTACH class plus those specified in the inherited abstract class $LOCK.
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!!
Note the method of specifying properties that an implementation must be able to expect to be implemented for the generic argument COL - exactly those which are specified in the abstraction $COL. This facility enables a palette class implementation to use such features in implementing the particular palette.
Restricting the kind of type argument to a class does not have to be restricted to a single abstraction. It may be desired, for example, to convert a palette into a text string description - which implies that the argument must have a text string representation too - so the class header could be -
which looks as though it should work - but does it? How is this distinguishable from a palette with two arguments - one COL and the other $STR - such as-
for example?
The answer lies in the fact that a generic argument cannot have an abstract name - so the first of these two has COL inheriting from both $COL and $STR, whereas the second has two arguments - COL (inheriting from $COL) and STR. Even though STR is the name of a class in the Required Library, for the purposes of this abstract definition it is an argument name and not the class STR.
Finally, it must be pointed out that an abstract class may have any number of abstract classes from which it inherits (as dictatrd by the abstract model which the designer is describing). Each of these could have arguments inheriting from an arbitrary number of other abstractions - provided that the non-circular nature of the type graph is not violated!
![]() |
Specification Index | ![]() |
Language Index | ![]() |
Abstract Classes | ![]() |
Section 6 Index |
Comments
or enquiries should be made to Keith Hopper. Page last modified: Wednesday, 25 October 2000. |
![]() |