Design Heuristics (p. 135)

Design heuristics are general guidelines, not recipes! They only help look for good characteristics or bad signs of a class design.

Cohesive Abstraction

A class should be a cohesive module to which the methods belong together.

  • Generally associated with a single abstraction (like an ADT).
    • should be capturable by a noun or adjective
      • Stack or Comparable
      • verbs like print or send should raise a red flag
  • Should also think if any items are missing
  • High cohesion is associated with loose coupling.

Encapsulation and Information Hiding

A cohesive interface doesn't guarantee a good design.

Data structure should be bundled with associated operations

  • TicTacToe might contain many appropriate methods, but what if the board is defined in another class?

Accessors and Mutators

Accessor

A query method that finds out the runtime state of an object of the class.

Mutator

A function that changes the state of an object.

Command-Query Separation Principle

When a class has both accessors and mutators, a clear separation is desirable.

  • accessors should not change object states
  • mutators should make a certain change

Classes as Data Types

In a typed object-oriented language, a class is a data type.

When a class only has static variables/methods, it deserves a closer look.

  • this is acceptable if a class is meant to only have one instance (Singleton)

Inheritance

  • in a good inheritance relationship, the superclass's methods should be cohesive with those in the subclass.
    • Stack<E> and Vector<E> do not have cohesive methods.
  • will a future change of the superclass affect a subclass?
    • avoid introducing new assumptions that could be broken by a potential superclass change
  • overriding may modify the precondition and postcondition of an overridden method and affect current/future clients of the class

Abstract Properties

Can often be stated in terms of:

  • preconditions
  • postconditions
  • class invariants

If not, the class's intent may be unclear.

Class invariants capture how the constructors and methods (especially mutators and accessors) are related.

  • An accessor's postcondition should reflect no object state change
  • A mutator's postcondition should specify a specific object state change