Skip to main content

Object-Oriented Design Principles

Printer-friendly version
Generalization or Inheritance is sometimes spoken of as a White Box relationship since the implementation of the superclass is available to the subclass. This awareness of implementation contrasts with Composition or Delegation as Black Box relationships since those two objects interact solely according to their externally visible contracts. Thus, Composition is favored over Inheritance because there is a better separation of responsibility. Note that a Generalization Hierarchy as a whole is still a Black Box to an external client, although the designer of the client must be aware of the responsibilities exposed at each level of the hierarchy.

Inherent to these themes is the principle that any one attribute or behavior should only be in one place. Otherwise we would not have correctly subdivided the universe of data and behavior to create cohesive, unified units. Students of relational database systems will recognize this as the principle of Normalization.

In a number of these principles, the statement is about a principle in terms of properties of the design, but one should remember that every design is intended to be a model of a problem space. Thus, if one has analyzed the problem space correctly, the design principle follows naturally. For example, in Interface Segregation Principle, if one has defined interfaces in terms of cohesive, irreducible concerns in the problem space, by definition one has also created the minimal appropriate interface. In Stable Dependencies Principle, one could re-interpret the requirement as defining the interface capturing the invariants of the problem space at the client’s level of abstraction. In Stable Abstractions Principle, if one defines interfaces in terms of invariants of the problem space, the more stable will be the definition.

Conclusion
While there is some difference of opinion about some details of some of the principles documented here, there is broad consensus in the OO world about the underlying principles on which they are based. Adhere to these principles and one can expect to more readily enjoy the benefits of object-orientation; violate the principles without good reason and those benefits may be denied.

There are reasons why one may not wish to adhere strictly to every principle in every circumstance. In particular, one might decide that there are characteristics of OOABL which indicate a pattern which seems to violate one of these principles and yet is a good manifestation of the underlying principles, but the choice should be made knowingly and carefully. There are often many ways to solve a given problem and it may be that more than one of these ways would seem to be an expression of one or the other of the principles reviewed here. Arriving at the best solution requires balance, judgment, and consideration of how the whole will function together, not just verification that each element can be defended according to some principle.

  • 1. See Mercer-Hursh, Thomas - Object-Oriented Vocabulary: An Introduction, for definitions of the words used in this document. See Mercer-Hursh, Thomas - Object-Oriented Design Patterns: An Introduction, for some common design patterns used in OO development which reinforce and support the design principles discussed here.
  • 2. While the context of this document is intended for use in relation to Object-Oriented ABL, the principles involved should apply to any OO language.
  • 3. This group and the two groups following on package cohesion and package coupling are derived from Robert Cecil Martin’s compilation at http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign .
  • 4. Bertrand Meyer, Object Oriented Software Construction.
  • 5. Defined by Barbara Liskov in 1988.
  • 6. Mercer-Hursh, Thomas. Object-Oriented Design Patterns: An Introduction.
AttachmentSize
OODesignPrinciples_20100123.pdf78.65 KB