ADTs as the Class Foundation (p. 117)

The notion of a class supports the basic design principles:

  • Modularity
  • Cohesion
  • Encapsulation
  • Information Hiding

Abstract Data Types (ADTs) help us:

  • capture the essential meaning of a class
  • develop a deep understanding of acceptable class abstractions
  • why it is desirable to document a public interface in terms of:
    • preconditions
    • postconditions
    • invariants.

Abstract Data Type

A data type for which only the properties of the data and the operations to be performed on the data are specified, without concern for how the data will be represented or how the operations will be implemented.

Usually, an object's prodperties can be captured by its behaviors (operations) rather than its data.

Example: Stack (p. 119)

  • ADT in code
    • why it's inadequate - what's the essential property?
    • Formal ADT specification solves inadequacy
      • Type name and parameters
      • Function signatures
      • Preconditions
      • Axioms

Class Invariant

A condition that any object of the class must satisfy at certain times.

Example: In the TicTacToe example, turn must be either X or O, though its data type is char.

Class invariants are usually established during construction and constantly maintained between calls to public methods. The code within the body of a method may break an invariant as long as it is restored before the method returns.

A class invariant may capture relationships between the methods of the class. For example, peek(push(s, x)) = x and pop(push(x, s)) = s describe the functional relationships between push, pop, and peek.

Summary

  • A non-abstract class is an ADT equipped with implementation details
    • the class's public interface corresponds to the ADT specification
    • instance variables are the data representation of the ADT
    • the methods:
      • implement the ADT's functions
      • satisfy the preconditions and axioms
  • Object-oriented software construction
    • Build a collection of interacting real-world entities (ADTs)
    • Create classes that are easier to implement initially and modify over time
    • At the level of analysis, design, or implementation
  • The choice of data representation may introduce additional constraints
    • if an array is used to represent a stack, whether the stack is full becomes an issue
  • An abstract class is an ADT with partial or no implementation details
  • An interface is an ADT without any implementation
  • An object-oriented design consists of a set of interacting ADTs, partially or fully implemented
  • Without ADTs, classes are like convenient carrying cases for loosely-related collections of data and operations