SOLID Principles
SOLID is a set of five object-oriented design guidelines that help you build code that's easier to change, test, and reason about. They reduce coupling and clarify dependencies — but they're heuristics, not strict rules. Applied mechanically they produce needless abstraction; applied thoughtfully they make change safer.
The thread running through all five: manage change. Most "SOLID wins" come not from memorizing the acronym but from drawing good boundaries and pointing dependencies in the right direction. If you can't name the change a given abstraction protects against, you probably don't need it yet.
TL;DR
- SOLID reduces coupling and increases clarity.
- Don't apply it mechanically — solve the problem you actually have.
- Most wins come from good boundaries and clear dependencies.
- It's most valuable when it helps you manage change.
Quick Example
Dependency Inversion at a boundary — domain defines the interface, infrastructure implements it:
S — Single Responsibility Principle
"A module should have one reason to change."
Separate concerns — validation vs persistence vs formatting — and keep classes/functions focused. Signals you're violating it: unrelated edits keep touching the same file, or you can't test a unit without elaborate setup.
O — Open/Closed Principle
"Software entities should be open for extension, closed for modification."
Add new behavior by adding new code, not rewriting old code — via composition and polymorphism. In practice: a strategy for pluggable behavior, or a handler/registry instead of a sprawling switch statement.
L — Liskov Substitution Principle
"Subtypes must be substitutable for their base types."
If you accept an interface or base type, any implementation should work without surprises. Red flags: subclasses that throw "not supported," or implementations that quietly break the base type's invariants.
I — Interface Segregation Principle
"Clients should not be forced to depend on interfaces they do not use."
Prefer small, focused, role-based interfaces over one "god" interface. This pays off especially at module boundaries and in dependency injection, where a fat interface forces consumers to know about methods they never call.
D — Dependency Inversion Principle
"High-level modules should not depend on low-level modules. Both should depend on abstractions."
Business logic shouldn't import database clients or HTTP frameworks. Define ports/interfaces in the high-level layer and implement them in infrastructure (see the Quick Example). This is the backbone of Clean Architecture:
Best Practices
- Reach for SOLID to manage real change, not preemptively.
- Define interfaces where they're used (the high-level layer), implement them at the edges.
- Keep interfaces small and role-based.
- Favor composition over deep inheritance for variability.
- Let testability guide you — code that's hard to test usually has a SOLID smell.
Common Mistakes
Abstraction without a reason
Confusing "more classes" with "better design"
FAQ
Are the SOLID principles still relevant outside classic OOP?
Yes — the underlying ideas (one responsibility, depend on abstractions, small focused interfaces) apply to functions, modules, and services too, not just classes. Functional and modular codebases express them differently (higher-order functions instead of strategy classes, module boundaries instead of interfaces), but the goals — low coupling, easy change — are universal.
Which SOLID principle matters most?
Dependency Inversion tends to have the highest leverage: pointing your business logic at abstractions rather than concrete infrastructure is what makes code testable and lets you swap databases, frameworks, or external services without rewriting core logic. It also underpins Clean Architecture. Single Responsibility is a close second for everyday maintainability.
Can following SOLID make code worse?
Yes, when applied dogmatically. Wrapping everything in interfaces, splitting cohesive classes for the sake of SRP, or adding strategy patterns with a single implementation all add indirection without benefit. SOLID is a means to manage change; if an abstraction doesn't protect against a change you can actually name, it's likely over-engineering.
How does SOLID relate to design patterns?
Design patterns are concrete recipes that often implement SOLID ideas — Strategy enables Open/Closed, the Adapter and dependency injection support Dependency Inversion. SOLID gives you the why (goals for managing change and coupling); patterns give you proven how. Learn the principles first so you apply patterns purposefully rather than decoratively. See Design Patterns.
Related Topics
- Clean Architecture — DIP applied at scale
- Design Patterns — Concrete implementations
- Domain-Driven Design — Modeling the domain
- Unit Testing — Where testability pays off
- System Design — Boundaries at the system level