SOLID, from the top

SOLID. The acronym (of acronyms) coined by Robert "Uncle Bob" Martin. Yeah, I know, just what we needed... acronyms made up of more acronyms. So is there actually a method to this madness? Well, lets see.

The first glimmer of the SOLID principles can be found when, in 1995, Uncle Bob laid out his ten commandments of Object Oriented Programming. That list was eventually streamlined and broken out into 5 distinct Principles. He and others have written and spoken about them many times since.

First things first.  Here you will find no listing of the 5 principles that make up SOLID. By jumping straight to the principles, I feel that its easy to miss out on the full benefit of learning about SOLID.  Besides, if you don't buy into the principles as a whole, it's likely not worth your time to learn the individual principles.

Therefore, when starting with SOLID, I think it's best to first step back and take a look at the big picture.

Okay, so what are these SOLID principles all about? The best high level description I've seen comes from the man himself, in a blog post titled "Getting a SOLID Start."

The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.

That's a good start, but I think the missing piece here is... what is the source of these principles? Did Uncle Bob drink too much whiskey and just make them up to sound smart?

Actually, in his PPP book, Uncle Bob explains that the idea behind the principles is to share the wisdom he has gained in his twenty plus years of software development.  I have to think that he, along with others in the fifty plus years of OO programming, probably learned a lot of lessons the hard way.  Hopefully, by keeping SOLID in mind when developing, we can benefit from some of the pain our predecessors when through.  Uncle Bob continues with...

The principles are mental cubby-holes. They give a name to a concept so that you can talk and reason about that concept. They provide a place to hang the feelings we have about good and bad code. They attempt to categorize those feelings into concrete advice. In that sense, the principles are a kind of anodyne [-capable of soothing or eliminating pain]. Given some code or design that you feel bad about, you may be able to find a principle that explains that bad feeling and advises you about how to feel better.

The paragraph above hits on one of the major benefits of SOLID. It gives us some common names, and acronynms, to make it easier to discuss OO design.

The paragraph also ties SOLID to code smells. The PPP book repeatedly points out that often the best way to use SOLID is to wait until there is a code smell, and then apply one or more of the principles to reduce or eliminate the smell.

Uncle Bob wraps up the description of the principles with...

These principles are heuristics. They are common-sense solutions to common problems. They are common-sense disciplines that can help you stay out of trouble. But like any heuristic, they are empirical in nature. They have been observed to work in many cases; but there is no proof that they always work, nor any proof that they should always be followed.

In PPP, he points out that trying to apply the principles before they are needed actually creates the code smell of needless complexity. He states that the incorrect usage of the principles can be worse than not applying them at all.  He takes this a step further when relating SOLID to learning how to paint.

This is an important point. Principles will not turn a bad programmer into a good programmer. Principles have to be applied with judgement. If they are applied by rote it is just as bad as if they are not applied at all.

Having said that, if you want to paint well, I suggest you learn the rules on the paint can. You may not agree with them all. You may not always apply the ones you do agree with. But you’d better know them. Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.

So, in the end, looks the the SOLID principles won't replace good judgement or experience. Damn, guess there really is no silver bullet. However, I think the SOLID principles are good tools for improving the quality of Object Oriented code.

Here are a few of the better sources on SOLID:

• Uncle Bob's page on SOLID
• Pablos topic of the month: solid principles (lost techies)
• Pablos ebook (combines all solid posts)