| # Examples 6.2: Abstract classes |

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

abstract class $OB is
end

This has no arguments, no sub or super types and no features.

### Simple features

One of the simplest abstract classes including a feature in the Required Library is

abstract class $HASH is
hash : CARD
end

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.

### Sub-Typing

Simple abstract class sub-typing is seen in the pervasive class $ATTACH which is in essence specified as

abstract class $ATTACH < $LOCK is
...
end

### Generic arguments

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.

abstract class $PALETTE{COL} is
...
end

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.

#### $COL

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 -

abstract class $COL is
...
end

and from that a few child classes

abstract class $RGB_COL < $COL is
...
end
abstract class $CMYK_COL < $COL is
...
end
abstract class $GREY_COL < $COL is
...

end

so that at the end of all this the palette abstraction could be defined in terms of $COL as

abstract class $PALETTE{COL < $COL} is
...
end

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. |