The SOLID Principles, Explained with Motivational Posters

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…

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”.

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

• ATL ALT.NET group (Atlanta)
• Austin .NET User Group
• North Dalls .NET User Group
• Pivotal Labs (San Francisco)
• Regina .NET User Group
• Space Coast .NET User Group
• Wisconsin .NET Users Group
• and there’ll be a talk on SOLID at the Isle of Man Dev Group tomorrow (the 17th)

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

• In Stack Overflow podcast 38, Joel “Joel on Software / Stack Overflow” Spolsky expressed his doubts about the real-world usefulness of SOLID (among other things he also considers to be stuff that “Architecture Astronauts” like)…
• So naturally “Uncle Bob” responded…
• and then Joel and Jeff had him as a guest of Stack Overflow podcast 41
• the SOLID scuffle was covered at InfoQ,
• and after that, he was a guest on Hanselminutes podcast 150.

SOLID has also been spotted in a number of blogs:

• Dave Tchepak blogged about SOLID in January
• “Uncle Bob” himself posted an article on getting started with SOLID in February
• LosTechies.com made SOLID their Topic of the Month in March
• Sandi Metz blogged about SOLID in March as well
• Steve Bohlen seems to have sworn off Stack Overflow’s podcast as a result of the SOLID scuffle

Mmmmmmmaybe…

The folks at LosTechies.com 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!

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.

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.

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.

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.

In addition to the LosTechies.com 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!