Also known as: SOLID
SOLID is a set of five object-oriented design principles, popularized by Robert C. Martin, that all aim at one outcome: code that is easy to change without breaking.1
The five principles
- S — Single Responsibility Principle. A unit of code should have one reason to change — it answers to a single concern. Mixing parsing, business rules, and storage in one class means a change to one risks breaking the others.
- O — Open/Closed Principle. Software should be open for extension but closed for modification: add new behavior by writing a new implementation, not by editing existing, tested code. An abstraction with multiple implementations is the usual mechanism.
- L — Liskov Substitution Principle. A subtype must be usable anywhere its base type is expected, honoring the parent’s contract — its expectations, guarantees, and invariants — not just its method signatures.
- I — Interface Segregation Principle. Clients shouldn’t be forced to depend on methods they don’t use. Many small, role-focused interfaces beat one fat one.
- D — Dependency Inversion Principle. High-level logic should depend on abstractions, not concrete details, with implementations supplied from outside (dependency injection).1
Why it matters
Together the principles reduce coupling and make code flexible and testable: when logic depends on an interface rather than a concrete class, a test can pass in a fake. SOLID overlaps heavily with DRY, KISS and YAGNI and underpins many design patterns — but it is a toolbox of heuristics, not a law. Applied dogmatically it causes as much over-engineering as it prevents; reach for these principles to diagnose code that resists change or testing, not to satisfy a checklist. They are a frequent target of refactoring.