S.O.L.I.D Principle

kick it on DotNetKicks.com
Save to delicious Saved by 0 users

Just to share a few links to video that demonstrate the S.O.L.I.D Object-Oriented Principles in an easy to understand and intuitive way.

Hi guys, in this post I am not going to write anything my own but to share with you the object-oriented principles, namely S.O.L.I.D by Robert Martin who has been a software professional since 1970.  Generally, S.O.L.I.D is a set of object-oriented design principle that guide us to write application that can sustain changes. As we all know, in the IT industries, the changes are constant. For e.g. business requirements changes, technology changes,  policy changes and etc. All these changes will affect the way the application operates. If the application design and codes can't sustain these changes, then it will be a very big problem because any change in any part of the application will have a ripple effect throughout the rest of the application. At the end, a whole application rewrite is the only solution.

I have come across a series of short 10 - 20 minutes video posts on dimecasts that demonstrates the S.O.L.I.D principle in a very easy to understand and intuitive way. So, I would like to share with you. I would encourage  those fresh developers who do the object-oriented programming to go through the video. Even if you are a very experienced developer and you never heard of these principles, it is no harm to have a look.
Here the links for the video that tell all;

S  -  Single Responsibility Principle

O - Open/Closed Principle

L - Liskov Substitution Principle

I - Interface Segregation Principle

D - Dependency Inversion Principle

This will end my post.  I am in the midst of preparing my next post on Dependency Injection with Unity and Common Service Locator Library.

See you in my next post.
Stay tune and bye...



February 23, 2010 at 6:00 PM

Unfortunately the videos or not that good. The injections take place at the wrong place and the methods are not that well chosen.

f.e. A report has a Print method. Unfortunately a report can not print. It should implement something like IPrintable. And than the Print method of the MatrixPrinter should have a variable of type IPrintable to print the document. Unfortunately the author of this screencast chose to inject an IReport to the constructor of the printer, so now I have to create a NEW printer for each report I create and want to print? That's not that smart. We only need ONE printer to which we can pass our IPrintables... and the same goes for the implementation of the Formatters.


Post a Comment