An introduction to SOLID principles in OO design

Single Responsibility Principle

"There should never be more than one reason for a class to change." — Robert Martin, SRP paper linked fromThe Principles of OOD

My translation: A class should concentrate on doing one thing

The SRP says a class should focus on doing one thing, or have one responsibility. This doesn't mean it should only have one method, but instead all the methods should relate to a single purpose (i.e. should be cohesive).

Open Closed Principle

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." — Robert Martin paraphrasing Bertrand Meyer, OCP paper linked from The Principles of OOD

My translation: Change a class' behaviour using inheritance and composition

The idea is that we can use OO techniques like inheritance and composition to change (or extend) the behaviour of a class, without modifying the class itself.

Liskov Substitution Principle

"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it." — Robert Martin, LSP paper linked from The Principles of OOD

My translation: Subclasses should behave nicely when used in place of their base class

Interface Segregation Principle

"Clients should not be forced to depend upon interfaces that they do not use." — Robert Martin, ISP paper linked from The Principles of OOD

My translation: Keep interfaces small and cohesive

The ISP is about keeping interfaces (both interface, and abstract class types of interfaces*) small and limited only to a very specific need (a single responsibility even :)). If you have a fat interface then you are imposing a huge implementation burden on anyone that wants to adhere to that contract. Worse still is that there is a tendency for class to only provide valid implementations for a small portion of a fat interface, which greatly diminishes the advantages of having an interface at all (note that these partial implementations violate the LSP, as we can no longer treat all subclasses of the interface equally)

Dependency Inversion Principle

"A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions." — Robert Martin, DIP paper linked from The Principles of OOD

My translation: Use lots of interfaces and abstractions

The DIP says that if a class has dependencies on other classes, it should rely on the dependencies' interfaces rather than their concrete types. The idea is that we isolate our class behind a boundary formed by the abstractions it depends upon. If all the details behind those abstractions change then our class is still safe. This helps keep coupling low and makes our design easier to change.