The Single Responsibility Principle
A class should have one, and only one, reason to change.
The Open Closed Principle
You should be able to extend a classes behavior, without modifying it.
The Liskov Substitution Principle
Derived classes must be substitutable for their base classes.
The Dependency Inversion Principle
Depend on abstractions, not on concretions.
The Interface Segregation Principle
Make fine grained interfaces that are client specific.
"If I had to write commandments, these would be candidates.
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 componen 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
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. "
March 16, 1995
I’ve been reading the C# 3.0 Design Patterns book and it’s always good to see the principle’s being used to express the patterns. No matter how long I program I like to come back to the basics.