SOLID – Getting Started and Source Material

This next series will follow the principles of SOLID, “five basic principles of object-oriented programming and design.”

The concepts as collated into SOLID was organized by a gentleman named Robert C. Martin who has what may be one of my favorite quotes in software engineering:

Following the rules on the paint can won’t teach you 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.

Getting a SOLID start, Robert C. Martin

Why is this one of my favorites? I’ll get to that in the future (when I get to patterns).

I will be referring to Robert C. Martin through out these posts as Uncle Bob. This isn’t intended to imply any familiarization between myself and Uncle Bob, nor any familial relationship. In fact, quite the opposite, I’ve never met Uncle Bob. But Uncle Bob self identifies as “Uncle Bob” using it for his old blog, as a twitter handle (@UncleBobMartin), and for his email. I figure he wants us to call him Uncle Bob, so why not?

Here are the references I’ll be utilizing on the posts covering each of the SOLID principles (ripped almost literally from Uncle Bob’s own post on object oriented design):

Design Principles and Design Patterns Uncle Bob’s initial paper discussing SOLID without naming it as such. Covers all the SOLID principles except “The Single Responsibility” principle.
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.
ISP The Interface Segregation Principle Make fine grained interfaces that are client specific.
DIP The Dependency Inversion Principle Depend on abstractions, not on concretions.

Needless to say, the vast majority of the content for this series will be based on Uncle Bob’s writings. I will try to make it clear the content that belongs to Uncle Bob and content that belongs to me and cite appropriately as I’ve done for posts in the past when I reference someone else’s work. This series is a case of “dwarfs standing on the shoulders of giants” taking Uncle Bob’s work and extending it to encapsulate my own experience with each of these topics.

So coming next week will be the first SOLID principle, “The Single Responsibility Principle”.


Leave a Reply