SOLID Principles
The problem
Object-oriented code can still end up brittle and hard to change — a class doing too much, subclasses that break their parent's contract, code forced to depend on methods it never uses — SOLID names five specific, checkable failure modes and the design move that avoids each one.
Why now
Coupling and cohesion already gave the general vocabulary for judging structure; SOLID is that vocabulary made concrete and checkable at the class level, giving five specific, nameable questions to ask about any class design instead of a vague sense that something 'feels off.'
Mental model
Each SOLID letter is coupling-and-cohesion's judgment turned into a specific test: Single Responsibility asks 'does this class do only one thing' (cohesion), Open/Closed asks 'can I extend behavior without editing existing code,' Liskov Substitution asks 'can a subclass truly stand in for its parent without breaking callers,' Interface Segregation asks 'am I forcing a class to depend on methods it doesn't use' (coupling), and Dependency Inversion asks 'am I depending on a concrete detail instead of an abstraction.'
Requires
- Object-Oriented Programming BasicsLow-Level Design
SOLID's five principles are all stated in terms of classes, interfaces, and inheritance; you need those building blocks already in place before SOLID's guidance about how to structure them applies.
- Coupling & CohesionSoftware Architecture
SOLID is coupling and cohesion's general vocabulary made specific and checkable at the class level — Single Responsibility is cohesion by another name, Dependency Inversion and Interface Segregation are both direct forms of reducing coupling.
Unlocks
Used in
- Code review checklists at nearly every professional engineering organization
- Dependency injection frameworks, which exist specifically to make Dependency Inversion practical
- Refactoring decisions — splitting a class that violates Single Responsibility
- System design and LLD interviews, where SOLID violations are a common thing interviewers probe for
Projects
- Take a class that violates Single Responsibility (e.g. a class that both calculates and prints an invoice) and split it into two classes, each with one reason to change
- Refactor a class that depends directly on a concrete database class into one that depends on an abstract interface instead, demonstrating Dependency Inversion
Examples
- A UserManager class that both validates user data and sends welcome emails violates Single Responsibility — two unrelated reasons for the class to change
- A PaymentProcessor depending on a concrete StripeClient class instead of an abstract PaymentGateway interface violates Dependency Inversion, making it hard to swap providers or write tests
Resources
Mastery checklist
- I can name and explain all five SOLID principles with a concrete example each
- I can identify a SOLID violation in a real or sample class design
- I can refactor a class to fix a Single Responsibility or Dependency Inversion violation
- I can explain why Liskov Substitution matters even when code compiles and runs without error