Instructors' Guide

1. 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.
2. 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.
3. Types contribute primarily to the reliability of systems. See slide 8-objectives.
4. 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.
5. 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.
6. Types have a formal interpretation as the specification of constraints. 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 slide 8-classes and slide 8-refinement.

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