SOLID by Uncle Bob

I've spend a couple of minutes today on listening to the Hanselminutes podcast about SOLID principles. The principles presented and explained by Uncle Bob himself is something you totally need to hear if you're any kind of software developer.

It's really good stuff so make sure to take a couple minutes to relax and listen the podcast. It's here: http://www.hanselminutes.com/default.aspx?showID=163

I also summarized them quickly for future reference (but you may like the Wikipedia version better):

• S (Single Responsibility) - Class and a method should have exactly one reason to change
  
• O – Open-Close Principle - Module open for extension, closed for modification. Polymorphism. We use interfaces, extend functionality by using different implementations of that interface. We can add new features by adding new code, not modifying core of the application. Principle of attitude ;-)
  
• L – Liskov substitution principle - The user of the interface should not be surprised by the implementation he's using. If you drive Chevrolet you should not be surprised by driving the VW. Square and Rectangle dilemma. No relationship between them. They are both a Shape, but in code, Square is not a Rectangle! (think about setHeight method.)
  
• I – Interface segregation principle - Applies to very fat classes, classes that have hundreds of methods and many many clients. Populations of clients that use subsets of the methods of this class. Some of the clients use couple of methods there, the other clients use couple of methods somewhere else. If a signature of one of that methods changes, then you need to recompile the class for all the clients, even that ones who are not affected by the change. You don’t want to depend on something you don’t use.
  
• D – Dependency Inversion Principle - Depend only at things that are abstract! Don’t depend at anything concrete, anything!!!! Never touch anything concrete! (In reality of course that never happens.. but there is a rule. The rule is that only those who are volatile can ignore the principle a bit. “The things that change frequently are volatile”, e.g. Main function. You need to instantiate come stuff there... but then depend only on abstractions!)