The SOLID Principles, Explained with Motivational Posters

by Joey deVilla on July 15, 2009

This article also appears in Canadian Developer Connection.

SOLID Seems to be Everywhere These Days

solid

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?

Mmmmmmmaybe…

And Now, The Principles and Posters

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!

Single Responsibility Principle

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

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

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

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.

dependency_inversion_principle

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 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!

Previous post:

Next post: