This page is a work in progress… a compilation of information about object-oriented design principles and values.

S.O.L.I.D. Class Design Principles

Collected by Robert C. Martin for his book “Applying Principles and Patterns”

Single Responsibility Principle (SRP)

A class should have only one reason to change. For example, if a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.

http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx

http://c2.com/cgi/wiki?SingleResponsibilityPrinciple

Head First Design patterns page 185, 336, 339, 367

http://msdn.microsoft.com/en-us/magazine/cc546578.aspx

http://codebetter.com/blogs/david_laribee/archive/2008/09/09/why-solid-gimme-an-s.aspx

Open/Closed Principle (OCP)

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

http://davidhayden.com/blog/dave/archive/2005/06/04/1096.aspx

http://en.wikipedia.org/wiki/Open/closed_principle

Head First Design patterns page 86-87, 407

http://c2.com/cgi/wiki?OpenClosedPrinciple

http://codebetter.com/blogs/david_laribee/archive/2008/09/11/why-solid-gimme-an-quot-o-quot.aspx

Liskov substitution principle (LSP)

Subtypes must be substitutable for their base types. If class A inherits from class B, then wherever you can use A you should be able to use B. E.g. remember that square is not necessarily a rectangle! When extending: Preconditions cannot be straightened, Postconditions cannot be loosened, visible Invariants cannot be changed (?). Invariants: users depend on this both before and after sending a message. Use a proper set-based inheritance relationship. Not following set semantics is very risky. Subsumption Rule: A reference to a subtype can be used in any context where a reference to a super type is expected. This principle extremely limits what SHOULD be done with the pure extension (inheritance) mechanism. Do not follow at your own risk.

Interface Segregation Principle (ISP)

The dependency of one class to another one should depend on the smallest possible interface.

Dependency Inversion Principle (DIP)

Depend upon abstractions (interfaces), not upon concrete classes.

http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx

http://en.wikipedia.org/wiki/Dependency_inversion_principle

Head First Design patterns page 139-143

http://c2.com/cgi/wiki?DependencyInversionPrinciple

Other Important Ones

Law of Demeter

aka Principle of Least Knowledge: Only talk to your friends

Any method M of an object O may only invoke the methods of the following kinds of objects:

itself

its arguments/parameters

any objects it creates/instantiates

its direct component objects

See

http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge

http://ctrl-shift-b.blogspot.com/2008/06/distilling-law-of-demeter.html

Head First Design patterns page 265

Hollywood Principle

Don’t call us, we’ll call you.

http://en.wikipedia.org/wiki/Hollywood_Principle

Head First Design patterns page 296

Don’t Repeat Yourself (DRY)

Remove duplication.

Pragmatic Programmer page 27

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

http://c2.com/cgi/wiki?DontRepeatYourself

Program to an interface, not an implementation

Maybe just another way to say dependency inversion.

Head First Design patterns page 11, 110-111, 243, 335

http://www.artima.com/lejava/articles/designprinciples.html

You Ain’t Gonna Need It (YAGNI)

Do not add code that you “think will be used later”. Add code only at “Last Responsible Moment”

Keep It Simple, Stupid (KISS)

What is the simplest thing that could possibly work?

And More

Encapsulation and Information Hiding

http://en.wikipedia.org/wiki/Encapsulation_(computer_science) http://en.wikipedia.org/wiki/Information_hiding

Separation of Concerns (SoC)

http://ctrl-shift-b.blogspot.com/2008/01/art-of-separation-of-concerns.html

High Cohesion

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Low/Loose coupling

Head First Design patterns page 53

http://en.wikipedia.org/wiki/Coupling_(computer_science)

Convention over Configuration (CoC)

http://en.wikipedia.org/wiki/Convention_over_Configuration

Command-query separation (CQS)

edit ] Design by Contract (DbC)

Dependency Injection (DI)

Inversion of Control (IoC)

Avoid Fragile Baseclass

http://en.wikipedia.org/wiki/Fragile_base_class

Has-a Is-a

http://en.wikipedia.org/wiki/Has-a http://en.wikipedia.org/wiki/Is-a http://en.wikipedia.org/wiki/Object_composition

What is Identity

http://en.wikipedia.org/wiki/Identity_(object-oriented_programming)

Interchangeability

http://en.wikipedia.org/wiki/Interchangeability_(computer_science)

Option-operand separation

http://en.wikipedia.org/wiki/Option-operand_separation

Intention Revealing Names

Zero Friction Development

http://www.google.com/search?q=Zero+Friction+development

Encapsulate Variation

Separate what varies from what stays the same. Also known as Serenity Principle.

http://blogs.msdn.com/steverowe/archive/2007/12/26/encapsulate-what-varies.aspx

Head First Design patterns page 9, 111

Composition over inheritance

Head First Design patterns page 23, 243, 397

Common Closure Principle

Classes that change together must be placed in the same package.