SOLID Principles Summary

The five SOLID principles in one place: what each one asks for, how they depend on each other, and one small example that shows all five.

Overview

SOLID is a set of five rules for arranging classes so that a program stays easy to change. Robert C. Martin collected them in the late 1990s; his 2000 paper 'Design Principles and Design Patterns' explains four of them (OCP, LSP, DIP, ISP) and the problem they solve, which he calls software rot. The acronym came later, around 2004, and is credited to Michael Feathers.

Every principle is about change. Martin's paper names four signs of a design that has started to rot, and each principle removes one or more of them.

Rigidity — one small change forces changes in many modules — classes depend directly on each other
Fragility — a change breaks code that seems unrelated — one class does several jobs, so its parts share state
Immobility — a useful class cannot be reused because it drags its dependencies along — it depends on concrete details
Viscosity — the hack is easier than the clean change — the design gives no clean place to add behavior

The five principles

S — Single Responsibility (SRP) — gather what changes for the same reason; separate what changes for different reasons — who asks for changes to this class, and is it more than one group?
O — Open-Closed (OCP) — open for extension, closed for modification — can I add a new case without editing existing classes?
L — Liskov Substitution (LSP) — code that uses an interface must not be confused by an implementation of it — can any subtype stand in for the base type without surprises?
I — Interface Segregation (ISP) — keep interfaces small so users do not depend on what they do not need — does every implementer use every method?
D — Dependency Inversion (DIP) — depend in the direction of abstraction, not on low-level details — does business logic import the database, or an interface?

The 'L' is named for Barbara Liskov. In a 1987 talk she described the idea as a substitution property: if a program written against type T behaves the same when objects of type S replace objects of type T, then S is a subtype of T. Liskov and Jeannette Wing made the rule precise in 1994.

How the five fit together

The principles are not five separate checks. Applying one tends to lead to the next, and breaking one tends to break the others.

A chain reaction in the other direction is common. A fat interface (ISP broken) forces implementers to stub out methods they cannot support (LSP broken), so callers add type checks to avoid the stubs (OCP broken), and now business logic knows about concrete classes (DIP broken).

One example that shows all five

Take pricing an order in a shop. The strong design puts each job in its own class and lets the pricer depend only on a small interface.

SRP — pricing, saving and notifying are three classes with three different reasons to change
OCP — a buy-one-get-one offer is a new DiscountRule class; OrderPricer is not edited
LSP — every rule returns a discount that is never larger than the order, so the pricer never sees a negative total
ISP — DiscountRule has one method; a rule does not have to know about saving or email
DIP — OrderPricer holds a list of DiscountRule, the interface, and the concrete rules are passed in

What interviewers listen for

Naming the principle — points at the line of code that breaks it — recites the definition only
The fix — shows the refactored shape and what stays untouched — says 'use an interface' with no shape
Judgment — says when a principle is not worth its cost — applies every principle to a 50-line script
Connection — explains how one fix helps or hurts another principle — treats the five as unrelated

What you will be able to do

State each principle in one sentence and name the smell it removes.
Spot which principle a piece of code breaks and refactor it in a few minutes.
Walk through one example that shows all five working together.
Say when a principle is not worth applying, and why.

Interview questions

This class computes a report, formats it and saves it. Which principle does it break, and how would you fix it?
How do the Open-Closed and Dependency Inversion principles work together?
Show a Liskov Substitution violation that runs without errors but is still wrong.
When should you not apply a SOLID principle?
Do SOLID principles apply outside a single class, for example to services?