SOLID Principles Explained (with Simple Examples)

🟠 Low-Level Design · Senior · the clean-code rules

SOLID is five principles that turn "code that works" into "code that stays maintainable." They're the vocabulary of a good LLD interview — when the interviewer asks "how would you make this extensible?", the answer is almost always one of these five. Better still, every design pattern is really SOLID applied. Let's make each one click with a plain example.

The five, at a glance

S — Single Responsibility Principle

🟠 A class should have one reason to change — one job. A User class that also formats reports and saves to the database has three reasons to change; split those out. Small, focused classes are easier to understand, test, and reuse. In an interview, if a class is doing too much, cite SRP and split it.

O — Open/Closed Principle

🟠 Software should be open for extension, closed for modification. Adding a new feature shouldn't mean editing existing, working code. The classic smell is a growing if/else or switch on a type: if shape is circle … else if square …. Every new shape edits that method. The fix: define a Shape interface with area(), and each shape implements it — adding a triangle means adding a class, not changing old ones. This is the principle most patterns exist to serve.

L — Liskov Substitution Principle

🔴 A subclass should be usable anywhere its parent is expected, without breaking things. If Square extends Rectangle but overrides setWidth to also change height, code that trusts a Rectangle's behaviour breaks when handed a Square — that violates LSP. The lesson: inheritance must model a true "is-a" where the child honours the parent's contract. When it doesn't, prefer composition. LSP is why "favour composition over inheritance" exists.

I — Interface Segregation Principle

🟠 Don't force a class to implement methods it doesn't need. A fat Machine interface with print(), scan(), fax() forces a simple printer to implement fax() it can't do. Split it into small, focused interfaces (Printer, Scanner, Fax) and let classes implement only what applies. Many small interfaces beat one bloated one.

D — Dependency Inversion Principle

🔴 Depend on abstractions, not concrete classes. A high-level OrderService shouldn't new MySQLDatabase() directly — it should depend on a Database interface, and the concrete one is injected. Now you can swap MySQL for Postgres, or a mock for testing, without touching OrderService. This "program to an interface, and inject dependencies" idea is the backbone of testable, flexible systems (and the whole reason frameworks like Spring do dependency injection).

Why SOLID matters in the interview

🟠 In an LLD round, you're graded on whether your design is extensible and clean, not just correct. SOLID gives you the language to justify choices: "I'll put the pricing logic behind a PricingStrategy interface (Open/Closed + Dependency Inversion) so new pricing rules are new classes, not edits." Naming the principle behind each decision is exactly what makes an answer sound senior. And when the interviewer says "now add feature X," a SOLID design lets you add a class instead of rewriting — visibly proving the point.

The interview-ready summary

"SOLID keeps designs maintainable. Single Responsibility — one job per class. Open/Closed — extend by adding classes, not editing old ones (I replace type switches with polymorphism). Liskov — subtypes must honour their parent's contract, or use composition. Interface Segregation — many small interfaces over one fat one. Dependency Inversion — depend on abstractions and inject them, so parts are swappable and testable. I use these to justify each design decision and to make 'add a feature' mean 'add a class.'" That's a senior-grade command of clean design."

What to read next

• Design Patterns in Java — SOLID applied, pattern by pattern
• Object-Oriented Design Basics — the pillars underneath SOLID
• Design a Parking Lot — SOLID in a real machine-coding problem
• ← The complete System Design guide (hub)

← OOD basics · UML class diagrams →