SOLID Principles in Java — The Five Rules of Maintainable OOP
Fast recall
Quick revision
Core answer
Whether you can explain each principle, connect it to the code smell it prevents, and show a concrete Java refactor. This is a near-universal mid-level interview question — the module is literally named 'Java OOP & SOLID'. Interviewers want to see that you can apply SOLID, not just recite the acronym.
Reciting the acronym expansion ('Single Responsibility means a class should have one reason to change') without a real example, or without explaining what goes wrong if you violate it. A second mistake: treating SOLID as absolute rules rather than tradeoffs — applying ISP to split a 3-method interface into three 1-method interfaces is over-engineering.
For each principle, give the rot smell it prevents AND a before/after Java snippet. Acknowledge the pragmatic ceiling: SOLID is a guide, not dogma. Mention that Robert Martin (Uncle Bob) defined them and that they're most valuable in large, long-lived codebases — not in a script or a prototype.
Interview-ready guide
Interview answer
SOLID is five design principles from Robert C. Martin, each targeting a specific way object-oriented code rots. S is Single Responsibility — a class should have one reason to change. The smell it prevents is the god class that does everything; a Report class that loads, formats, and emails changes for three different teams. The fix is to split by actor: a repository, a formatter, a mailer.
O is Open-Closed — open for extension, closed for modification. The smell is the forever-growing switch statement, like a shipping calculator that you edit every time you add a carrier. The fix is polymorphism: a ShippingCarrier interface where each carrier is a class, and adding DHL means writing a new class without touching the calculator.
L is Liskov Substitution — subtypes must be substitutable for their base types. The classic violation is Square extends Rectangle, where setting width also sets height and breaks code that assumed they were independent. If the subtype can't honor the supertype's contract, the inheritance is wrong — redesign the hierarchy.
I is Interface Segregation — clients shouldn't depend on methods they don't use. A fat Machine interface with print, scan, and fax forces a simple printer to throw UnsupportedOperationException for scan and fax, which is a runtime bomb. Split into focused interfaces so a caller can't even call scan on something that doesn't support it.
D is Dependency Inversion — depend on abstractions, not concretions. The smell is a service that news up its own database, making it untestable and welded to one implementation. The fix is constructor injection of an interface — which is exactly what Spring's @Autowired does.
The nuance interviewers want to hear: SOLID is a guide, not dogma. Each principle adds indirection, so applying all five to a 20-line class is over-engineering. Apply them at the seams — the boundaries that change — and keep the interior simple.
SOLID Principles in Java — The Five Rules of Maintainable OOP
Direct Answer
SOLID is an acronym for five design principles (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) that make object-oriented code maintainable, testable, and resilient to change. Each principle targets a specific rot pattern: SRP targets god classes, OCP targets change-fragile code, LSP targets broken inheritance hierarchies, ISP targets fat interfaces, DIP targets hardcoded dependencies. They are guidelines, not laws — applying all five to a 20-line class is over-engineering; ignoring all five in a 50,000-line system is how you get an unmaintainable monolith.
Common Mistakes & Pitfalls
Reciting the acronym expansion ('Single Responsibility means a class should have one reason to change') without a real example, or without explaining what goes wrong if you violate it. A second mistake: treating SOLID as absolute rules rather than tradeoffs — applying ISP to split a 3-method interface into three 1-method interfaces is over-engineering.
Check your understanding
Answer these without looking back at the article.
- What is the difference between the Open-Closed Principle and polymorphism? Aren't they the same thing?
- How does Spring's dependency injection implement the Dependency Inversion Principle?
- Give an example where applying SOLID would be over-engineering.
- How does the Liskov Substitution Principle relate to the contract of equals() and hashCode()?
- What is the relationship between SOLID and design patterns — do patterns like Strategy and Factory exist to enforce SOLID?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.