SOLID principles

SOLID is an acronym for five design principles of object-oriented programming, popularized by Robert C. Martin. The five principles are the single responsibility principle, the open-closed principle, the Liskov substitution principle, the interface segregation principle, and dependency inversion.

Martin introduced the acronym in his 2000 essay Design Principles and Design Patterns, gathering principles he had been writing about through the 1990s into a single mnemonic. Two of the five predate him: the Liskov substitution principle was stated by Barbara Liskov in 1987, and the open-closed principle by Bertrand Meyer in 1988. The other three emerged from Martin’s own series of C++ Report columns in 1996. The acronym itself is a teaching device, a way to make the five memorable and to present them as a coherent set rather than as isolated heuristics.

What the principles address

Martin framed the principles as remedies for the symptoms of poor design he called software rot: rigidity, where every change forces many others; fragility, where a change breaks unrelated parts; immobility, where a module cannot be reused because it drags in too many dependencies; and viscosity, where it is easier to hack around the design than to follow it. The five principles are not a checklist of features to add but a set of preferences – for high cohesion, low coupling, and dependence on abstractions rather than concretes – that, taken together, push a codebase away from those symptoms.

The principles operate at the scale of a single class or module and its immediate collaborators. They are not architectural rules. Styles such as hexagonal architecture and clean architecture apply dependency inversion across a whole system, but that is a larger use of one SOLID letter, not a consequence of SOLID as a whole.

How the letters relate

The five principles are interdependent, and Martin described them as building toward one another. The single responsibility principle is the foundation: a module with one reason to change is easier to extend without modifying, which is the goal of the open-closed principle. The open-closed principle is in turn easiest to satisfy when subtypes are genuine behavioral substitutes (the Liskov substitution principle), when interfaces are narrow enough that every implementer can honor the full contract (the interface segregation principle), and when callers depend on abstractions owned by the caller rather than on concrete implementations (dependency inversion). Each letter makes the next more achievable.

Dependency injection is the technique most commonly used to put dependency inversion into practice, and so it is the mechanism by which much of SOLID becomes operational in real codebases.

Relation to other heuristics

SOLID overlaps with GRASP, Craig Larman’s set of responsibility-assignment patterns, which express similar preferences for low coupling and high cohesion but frame them as questions about which class should own a responsibility. SOLID is also a specific application of separation of concerns to the class and module level. The Law of Demeter is a complementary heuristic: it constrains how an object talks to its collaborators, where the SOLID letters constrain the shape of the modules that collaborate.

Criticism

The principles are heuristics, not laws, and they are easy to over-apply. Introducing an abstraction for every collaboration, ahead of any second implementation, produces empty interfaces and speculative hierarchies that multiply without earning their keep. The result is complexity in the name of avoiding it. YAGNI is the usual counterweight: an abstraction that never sees a second implementation is generality bought on credit. The principles are most useful when applied where a dependency is genuinely volatile or where unit testing needs a seam, not as a blanket rule over every class.

See also

References

  • Martin, Robert C. (2000). Design Principles and Design Patterns. objectmentor.com.
  • Martin, Robert C. (2002). Agile Software Development, Principles, Patterns, and Practices. Pearson.
  • Liskov, Barbara (1987). Data Abstraction and Hierarchy in Object-Oriented Programming. OOPSLA.
  • Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall.