https://www.youtube.com/watch?v=K7iVBAQHN8I
The God Class Problem
You open a codebase and find one class doing everything. Authentication, emails, logging, database queries, input validation. Two thousand lines. You change how emails are sent and tests break in authentication. Everything is wired to everything.
This is the most common disaster in object-oriented code. And five principles — proposed by Robert Martin over forty years ago — exist to prevent it.
S — Single Responsibility
SRP doesn't mean "one class, one method." It means one reason to change.
If your marketing team, security team, and ops team all need changes to the same file, that file has too many responsibilities. Split it so each module answers to one stakeholder. When marketing changes the email format, authentication doesn't break.
The trap: taking SRP too far and creating twelve files to send an email. The principle is about reasons to change, not counting methods.
O — Open/Closed
Software should be open for extension, closed for modification.
A payment processor with a switch statement works until you add a new method and accidentally break an existing one. The fix: replace the switch with a PaymentMethod interface. Adding crypto means adding a new class — existing code never changes.
The trap: abstracting code that hasn't changed in two years. Open/Closed is for hot paths that change frequently, not stable code.
L — Liskov Substitution
Square extends Rectangle compiles. Types check. But set width to 5 and height to 10 on a Square, and the area is 100 — not 50. The subclass broke the parent's contract.
Liskov Substitution means any code expecting a parent type must work correctly with any subclass. If a subclass surprises the caller, you have the wrong hierarchy. The fix isn't better Square code — it's not extending Rectangle at all.
I — Interface Segregation
A Worker interface with work() and eat() forces a Robot to implement eat(). An empty method is a lie in your code.
Split the interface. Workable and Feedable. Humans implement both. Robots implement only Workable. Clients depend on what they actually use — nothing more.
D — Dependency Inversion
OrderService that creates MySQLRepository directly is coupled to a specific database. Switch to Postgres? Rewrite everything.
DIP flips the arrows. Both high-level policy and low-level detail depend on a shared abstraction — a Repository interface. MySQL implements it. Postgres implements it. OrderService doesn't know which one it gets.
DIP ≠ dependency injection. Injection is a technique (passing dependencies from outside). Inversion is the principle (both layers point toward the abstraction). Different ideas.
The Honest Truth
SOLID principles are heuristics, not laws. They connect to deeper concepts: SRP drives cohesion, OCP reduces coupling, LSP ensures correct abstractions, ISP supports testability, and DIP enables flexibility.
Apply them when the cost of change is high. Relax them when simplicity matters more. The worst code isn't code that violates SOLID — it's code that follows SOLID dogmatically without judgment.
Top comments (0)