# Section 6.2.1:
Abstract Class Definitions

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 observable behaviour of visible features. 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.

TODO | Consider the potential benefits of including pre and post-conditions and exception identity in an abstract class signature - to ensure self-consistency of the specification.

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.

#### Concrete Syntax

abstract class definition = | Abstract_SY, Class_SY, abstract type name,
| [generic arguments],
| [subtyping clause],
| [supertyping clause], Is_SY,
| [abstract signature list],
| End_SY ;

abstract signature list = | abstract signature, {Semicolon_SY, [abstract signature]},

#### Abstract Syntax

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.

Class_Def ::
kind : Class_Kind
features : set of Feature
typenode : [ Type_Graph ]
inv mk_Class_Def(kind,ftrs,_) ==
(kind = Abstract)
and (forall feat in ftrs &
(feat.impl = nil)
and (feat.ext_vis = {Use})
and (feat.value = nil)

#### Static Semantics

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 -

wf_abstract_class : Class_Def -> bool
wf_abstract_class(mk_Class_Def(_,comps,graph)) ==
forall feat in set comps &
wf_abstract_signature(feat)
and forall feat1, feat2 in set comps &
feat1 <> feat2 => is_disjoint_sig(feat1,feat2)
and wf_type_graph(graph) ;

in which the auxiliary vdm function is_disjoint_sig is used (see section 6.9).

#### Dynamic Semantics

An abstract class has no dynamic semantics associated with it, since its use is in specifying ADTs for use 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: Wednesday, 25 October 2000. |