The Five SOLID Principles at a Glance

Five rules collected by Robert C. Martin and named SOLID by Michael Feathers, all aimed at change.

SOLID is an acronym for five design principles that keep object-oriented code easy to change. Each letter stands for one principle, and each principle answers one or more symptoms of design rot. This card gives every principle in one plain sentence, so that the names mean something before each one gets a topic of its own.

The principles were not invented together. Bertrand Meyer described the open/closed principle in 1988. Barbara Liskov gave the substitution idea in a keynote in 1987. Robert C. Martin gathered these with three principles of his own in articles and in his 2000 paper, and around 2004 Michael Feathers noticed that the first letters spelled SOLID. The acronym stuck because it is easy to remember, not because the five belong in that order.

Each SOLID principle in one sentence, with the symptom it answers
Letter	Principle	In one sentence	Symptom it answers
S	Single responsibility	A class should have one reason to change, which means it serves one group of people.	Rigidity, fragility
O	Open/closed	You should be able to add new behaviour by adding code, without editing code that already works.	Rigidity, fragility
L	Liskov substitution	A subclass must work anywhere its parent class is expected.	Fragility
I	Interface segregation	A class should not be forced to depend on methods it does not use.	Rigidity, immobility
D	Dependency inversion	High-level policy should depend on abstractions, not on concrete details such as a particular database.	Immobility, rigidity

An abstraction, in that last row, is a type that names what something does without saying how: an interface or an abstract class. A Sender with a send method is an abstraction; an SmtpMailer is a concrete detail.

Read the table as five different questions to ask of a class. Does it have more than one reason to change? Will the next variation mean editing it? Can a subclass be swapped in safely? Does it make its users depend on methods they never call? Does it reach for concrete details instead of being handed what it needs?

Two things the table does not say. The principles are guidelines, not laws: each one costs some indirection, and that cost is only worth paying where change is expected. And they overlap. Splitting a class for single responsibility often makes dependency inversion easier, and a good interface split helps substitution. You will rarely apply exactly one of them alone.

← → move through sections and cards