The SOLID Principles, Explained with Motivational Posters

This article also appears in Canadian Developer Connection.

SOLID Seems to be Everywhere These Days


Robert C. “Uncle Bob” Martin first gathered the object-oriented design principles that would eventually go under the acronym SOLID almost fifteen years ago, but the SOLID principles have been making the rounds lately.

Before I talk about the SOLID principles, let me show you where the concept has been popping up in the past few months…

SOLID at Conferences

At the Microsoft TechEd conference in May, Steve Smith gave a presentation on applying the SOLID principles to developing applications with the ASP.NET MVC framework. At around the same time, the GeeCon conference in Krakow, Poland had a couple of presentations on SOLID: Bruno Bossola gave a talk on the SOLID principles and  Lee Brandt gave a talk on spotting SOLID code “in the wild”.

SOLID at User Groups

A number of user groups have had recently presentations on SOLID, such as:

Stack Overflow on SOLID

SOLID was the topic of a recent argument that took place over a series of podcasts earlier this year:

SOLID in Blogs

SOLID has also been spotted in a number of blogs:

Will There be a Presentation on SOLID at TechDays Canada 2009?


And Now, The Principles and Posters

The folks at have created a series of Creative Commons-licenced posters that illustrate the SOLID principles. I took the posters, cleaned up the typography a little and posted them below under the same Creative Commons licence. Below each poster is an explanation of the corresponding SOLID principle. Enjoy!

Single Responsibility Principle


The “S” in SOLID is for Single Responsibility Principle, which states that every object should have a single responsibility and that all of its services should be aligned with that responsibility. “Responsibility” is defined as “a reason to change”, and Wikipedia does a pretty good job of explaining it:

As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

Open-Closed Principle


The “O” in SOLID is for Open-Closed Principle, which states that software entities – such as classes, modules, functions and so on – should be open for extension but closed for modification. The idea is that it’s often better to make changes to things like classes by adding to or building on top of them (using mechanisms like subclassing or polymorphism) rather than modifying their code.

Liskov Substitution Principle


The “L” in SOLID is for Liskov Substitution Principle, which states that subclases should be substitutable for the classes from which they were derived. For example, if MySubclass is a subclass of MyClass, you should be able to replace MyClass with MySubclass without bunging up the program.

Interface Segregation Principle


The “I” in SOLID is for Interface Segregation Principle, which states that clients should not be forced to depend on methods they don’t use. If a class exposes so many members that those members can be broken down into groups that serve different clients that don’t use members from the other groups, you should think about exposing those member groups as separate interfaces.


The “D” in SOLID is for Dependency Inversion Principle, which states that high-level modules shouldn’t depend on low-level modules, but both should depend on shared abstractions. In addition, abstractions should not depend on details – instead, details should depend on abstractions.

Bonus Reading Material on SOLID

In addition to the posters, they’ve also produced a book covering the SOLID principles in detail. Go and download Pablo’’s Solid Software Development [1.4 MB PDF] now!

18 replies on “The SOLID Principles, Explained with Motivational Posters”

This is a great compendium of all-things-SOLID, but by way of a slight correction, if you read closely my blog post where I swear off the StackOverflow podcast, you will actually see that *despite* their position on SOLID I actually continued to listen to SO; I think the discussions that Rob Martin had with them were quite illuminating (hopefully) for most listeners. I still think Jeff and Joel are completely wrong, but at least now they are a better-informed WRONG rather than wrong b/c of their ignorance.

I’d also like to mention that there is a whole 5-part series of 10-minute screencasts on each of the SOLID principles on the DimeCasts.NET site that you might want to point out to your readers as well at

Steve Bohlen: Hey, Steve!

That’s why I went with the mitigated “seems to have sworn off Stack Overflow’s podcast” rather than “stopped listening”. I like your idea of “a better-informed WRONG” — my question is: “Is a better-informed WRONG worse for the audience?”

Thanks for the heads-up about the screencasts — I’ll blog about them here in Global Nerdy as well as in Canadian Developer Connection.

Not that your list needs to be comprehensive, but we did a workshop on SOLID and another on Clean Code in the Philly ALT.NET group as part of our Foundation Series of workshops. Obviously, we leaned heavily on Uncle Bob’s writings on both topics (and made sure we gave credit – and links – where they were due). We also got ideas from Steve Bohlen above, and the recordings he mentions. We hope to repeat the content later this year.

I liked the SOLID motivational pictures and some time ago I used them to make the the full page posters (picture + text) to hang it on a pinboard in a kitchen when people always look at waiting for water to boil or coffee to brew. People in the company had liked it and recently I remastered them and made publicly available in PDF version ready to print. They can be downloaded from my blog:
Solid Soft – Working code is not enough:

Thanks Joey!

[…] A great example illustrating LSP (given by Uncle Bob in a podcast I heard recently) was how sometimes something that sounds right in natural language doesn’t quite work in code. In mathematics, a Square is a Rectangle. Indeed it is a specialization of a rectangle. The “is a” makes you want to model this with inheritance. However if in code you made Square derive from Rectangle, then a Square should be usable anywhere you expect a Rectangle. This makes for some strange behavior. Imagine you had SetWidth and SetHeight methods on your Rectangle base class; this seems perfectly logical. However if your Rectangle reference pointed to a Square, then SetWidth and SetHeight doesn’t make sense because setting one would change the other to match it. In this case Square fails the Liskov Substitution Test with Rectangle and the abstraction of having Square inherit from Rectangle is a bad one. Y’all should check out the other priceless SOLID Principles Explained With Motivational Posters. […]

Comments are closed.