TITLE: Principles and Patterns of OOD


RESPONSE: rmartin@rcmcon.com (Robert Martin), 6 Jun 95

I am in the midst of working on my next book: "The Principles and Patterns
of Object Oriented Design".  As part of that exercise, I have been compiling
a set of principles, some of which I posted to comp.object several months
back.  They are included at the end of this posting.

Over the next few weeks I will be posting articles that expound upon
each of the principles in turn.  My object, of course, is to present these
principles to the OO community and get some early feedback and reviews for
my book.

I'll post an article about the first principle in a subsequent posting.


   1. Software entities (classes, modules, etc) should be open for
      extension, but closed for modification.  (The open/closed
      principle -- Bertrand Meyer)

   2. Derived classes must usable through the base class interface
      without the need for the user to know the difference.  (The
      Liskov Substitution Principle)

   3. Details should depend upon abstractions.  Abstractions should
      not depend upon details.  (Principle of Dependency Inversion)

   4. The granule of reuse is the same as the granule of release.
      Only components that are released through a tracking system can
      be effectively reused.

   5. Classes within a released component should share common closure.
      That is, if one needs to be changed, they all are likely to need
      to be changed.  What affects one, affects all.

   6. Classes within a released component should be reused together.
      That is, it is impossible to separate the components from each
      other in order to reuse less than the total.

   7. The dependency structure for released components must be a DAG.
      There can be no cycles.  

   8. Dependencies between released components must run in the
      direction of stability.  The dependee must be more stable than
      the depender.

   9. The more stable a released component is, the more it must
      consist of abstract classes.  A completely stable component
      should consist of nothing but abstract classes.

  10. Where possible, use proven patterns to solve design problems.

  11. When crossing between two different paradigms, build an
      interface layer that separates the two.  Don't pollute one side
      with the paradigm of the other.