![]() |
Section 6.2.1:
|
An abstract class is a specification of a class interface - without implementation. It is an Abstract Data Type to use the name associated with the concept that an object type may be defined solely in terms of the externally visible features (which may or may not include direct access to any internal state). The features identified in the abstract specification do not indicate how an implementation class is to provide the feature - merely that it must be implemented.
An abstract class does not need to specify any features at all. In such a case it becomes more a 'category' of object than an ADT. However, in practice this may be useful as a 'parent' abstraction for a number of sub-type abstractions which do have similar (though not identical) features. If the features were identical then the parent should have contained them rather than the child sub-types.
The invariant on the Class_Def for abstract classes ensures that the specification is abstract and that the features have no implementation or value.
This is the first component in Section 6 of this document which introduces the new form of abstract syntax. The generic arguments, sub-typing and super-typing clause are all part of the type graph component of the class which will eventually be checked for well-formedness - which involves checking the entire graph for all classes referred to in a program.
Given the invariant above then well-formedness needs to ensure that both each individual feature is well-formed and that all are disjoint (there are no possible ambiguities!). Since all of the features are merely signatures it is only necessary to use that form of feature well-formedness testing, thus -
in which the auxiliary vdm function is_disjoint_sig is used (see section 6.9).
An abstract class has no dynamic semantics associated with it, since its use is in specifying ADTs for us in implementations - having no run-time existence.
![]() |
Specification Index | ![]() |
Language Index | ![]() |
Examples | ![]() |
Section 6 Index |
Comments
or enquiries should be made to Keith Hopper. Page last modified: Friday, 26 May 2000. |
![]() |