Oo Design Principles

This is a page dedicated to capture OO design principles and to give credit to its original authors. Feel free to add more references to this page.

See also PrinciplesOfObjectOrientedDesign for a different presentation of these principles. -- RobertCecilMartin - 9/7/99

Are they different enough to warrant two separate pages? Some pages contain reference to both, which I personally find confusing. Would anyone object to merging the two?

If they are merged, please keep the references, they are useful to find source materials -- JosephThompson

The current page is a succinct summary with bibliography. The PrinciplesOfObjectOrientedDesign page veers into some interesting discussions.

The LiskovSubstitutionPrinciple (LSP): "An instance of a derived should be able to replace any instance of its superclass"

[Liskov74] Barbara H. Liskov and Stephen N. Zilles, Programming with Abstract Data Types, Computation Structures Group, Memo No 99, MIT, Project MAC, Cambridge Mass, 1974. (See also SIGPLAN notices, 9, 4, pp. 50-59, Apr 1974.) [Martin96] Robert C. Martin, Engineering Notebook, C++ Report, March, 1996. [Martin96] Robert C. Martin, Engineering Notebook, C++ Report, Nov-Dec, 1996.

The OpenClosedPrinciple (OCP): "A reusable class should be open for extension, but closed for modification."

[Meyer88] Bertrand Meyer, Object Oriented Software Construction, Prentice Hall, 1988. pg. 23 [Martin96] Robert C. Martin, Engineering Notebook, C++ Report, Jan, 1996. [Martin96] Robert C. Martin, Engineering Notebook, C++ Report, Nov-Dec, 1996.

The DependencyInversionPrinciple (DIP): "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."

[Martin95] Robert C. Martin, Object Oriented Design Quality Metrics: An Analysis of dependencies, ROAD, Vol. 2, No. 3, Sep-Oct, 1995.

The InterfaceSegregationPrinciple (ISP): "The dependency of one class to another one should depend on the smallest possible interface."

[Meyer88] Bertrand Meyer, Object Oriented Software Construction, Prentice Hall, 1988. [Martin96] Robert C. Martin, Engineering Notebook, C++ Report, Nov-Dec, 1996.

The ReuseReleaseEquivalencePrinciple (REP): "The granule of reuse is the granule of release." module == type, the fusion of distinct notions is what gives OO its distinctive flavor.

[Meyer88] Bertrand Meyer, Object Oriented Software Construction, Prentice Hall, 1988. [Martin96] Robert C. Martin, Engineering Notebook, C++ Report, Nov-Dec, 1996.

The CommonClosurePrinciple (CCP): "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."

[Martin96] Robert C. Martin, Engineering Notebook,
C++ Report, Aug, 1996.
[Martin96] Robert C. Martin, Engineering Notebook,
C++ Report, Nov-Dec, 1996.

The CommonReusePrinciple (CRP): "The classes in a package are reused together."

[Martin95] Robert C. Martin, Engineering Notebook,
C++ Report, Nov-Dec, 1996.

The AcyclicDependenciesPrinciple (ADP): "The dependency structure between packages must not contain cyclic dependencies."

[Lakos96] John Lakos, Large Scale C++ Software Design, Addison and Wesley, 1996. [Martin96] Robert C. Martin, Engineering Notebook, C++ Report, Nov-Dec, 1996.

The StableDependenciesPrinciple (SDP): "Architectures must be crafted using a set of stable dependencies". This is also related to the DIP principle.

Richard Riehle, ROAD, ???, (I can't remember the issue at this moment) [Meyer88] Bertrand Meyer, Object Oriented Software Construction, Prentice Hall, 1988. [Martin95] Robert C. Martin, Object Oriented Design Quality Metrics: An Analysis of dependencies, ROAD, Vol. 2, No. 3, Sep-Oct, 1995. [Martin97] Robert C. Martin, Engineering Notebook, C++ Report, Feb 1997.

The StableAbstractionsPrinciple (SAP): "An architecture should contain as many stable abstractions as possible, and these abstractions should be isolated from the ones that are more likely to change."

Richard Riehle, ROAD, ???, (I can't remember the
issue at this moment) 
[Martin97] Robert C. Martin, Engineering Notebook,
C++ Report, Feb 1997.

The LawOfDemeter (LoD): "The law of demeter (class form) says that inside an operation O of class C we should call only operations of the following classes, called preferred supplier classes: the classes of the immediate subparts (computed or stored) of the current object, the classes of the argument object of O (including the class C itself) and the classes of object created by O."

[Lieberherr89] Lieberherr, Karl. J. and Holland, I. Assuring good style for object-oriented programs IEEE Software, September 1989, pp 38-48 [Lieberherr96] Karl Lieberherr, Adaptive Object Oriented Software - The Demeter Method, PWS Publishing Co., Boston, 1996.