Robert Martin’s Principles of OOD

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

 

SRP
The Single Responsibility Principle
A class should have one, and only one, reason to change.

OCP
The Open Closed Principle
You should be able to extend a classes behavior, without modifying it.

LSP
The Liskov Substitution Principle
Derived classes must be substitutable for their base classes.

DIP
The Dependency Inversion Principle
Depend on abstractions, not on concretions.

ISP
The Interface Segregation Principle
Make fine grained interfaces that are client specific.

Also, Robert Martin’s ’10 Commandments’

"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
      the depender.

   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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s