- Control abstractions primarily
affect the flow of control.
Control abstractions were introduced
to support a structured approach
to algorithm design.
A structured approach avoids the use
of goto's, and instead employs
if-statements and explicit while-statements.
In contrast, data abstraction pertains
to data structures and information hiding.
Abstract data types may be realized
as a collection of functions.
Object-oriented languages, however, provide
far better support for data abstraction.
See slide
[8-abstraction].
- Types contribute primarily to the reliability
of systems.
See slide
[8-objectives].
- The most obvious interpretation of
objects (as algebras) is to
regard each object state as an algebra.
A state change for the object, then,
results in a different algebra.
Mathematically, the object may then
be considered to live in a different
world.
See slide
[8-objects].
- A data abstraction matrix, as shown in
slide
[8-decomposition],
provides a powerful way to specify the
properties of an abstract data type.
Its realization by modules or objects
reflects a choice for a particular
decomposition, sacrificing
the generality of the original matrix.
- The realization of an abstract data type
as a module results in organizing
the functionality of the type around
the observers.
For each observer, the result for the
various generators is specified as
a separate case.
In contracts, objects may be regarded
as specifying for each generator
the value for the observer operation.
As trade-offs we have that objects
behave comparatively better when
extending the abstract data type with
new generators,
whereas the reverse seems to hold
for extending an abstract data type
with new observers.
- Types have a formal interpretation as
the specification of constraints,
whereas classes may be taken as templates
for object creation, which is a far more
pragmatic interpretation.
- Types may be specified in a syntactic
way, semantically or purely pragmatically.
In the latter case, the notion of types
coincides with the notion of classes.
Classes, clearly,
may be regarded as an over-specification
of the properties of a type.
When regarded from a syntactic point of view,
types specify too little.
However, a purely syntactic specification
allows for rigid type checking.
The behavioral specification of types
must be regarded as an ideal.
Contracts as supported by Eiffel
are one possible approximation
of this ideal.
See slides
[sli-8-classes] and [sli-8-refinement].
- Behaviorally compatible modifications
are refinements that fully
meet the substitutability requirement.
Alternatives are signature compatible modifications,
that are constrained only by syntactic requirements,
and name compatible modifications
that rely only on the method search
algorithm employed, imposing
even weaker constraints.