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.

See also... BertrandMeyer discusses five other principles: LinguisticModularUnits?, FewInterfaces, SmallInterfaces?, ExplicitInterfaces?, InformationHiding

	[Meyer88] Bertrand Meyer, Object Oriented 
	Software Construction, pg 18, Prentice Hall, 1988.

Information Hiding was first proposed by Parnas on it's seminal paper "On the criteria to be used in decomposing systems into modules". http://portal.acm.org/citation.cfm?doid=361598.361623

--MarcosEliziarioSantos

JohnLakos discuses similar architectural principles
	[Lakos96]  John Lakos, Large Scale C++ 
	Software Design, Addison and Wesley, 1996.

See also RobertMartin's original articles http://www.objectmentor.com/.

I gathered most of them from books, journal articles, trade magazines, web pages and other papers on the net over the years. Some of them often appear in early OO books and papers, but have they also have been documented many times by different authors over time.

-- MikeBeedle


CategoryModellingLawsAndPrinciples, CategoryObjectOrientation

EditText of this page (last edited July 14, 2009) or FindPage with title or text search