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):

Update 2024-02-18: This was originally hosted on the site objectmentor.com but that has now gone defunct. I’ve hosted it here for archival purposes but Uncle Bob is the original author and owns the copyright as indicated in the paper.	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”.

Thanks,
Brian