SOLID: LSP, ISP, and DIP

The remaining three SOLID principles - LSP, ISP, and DIP - govern how classes and interfaces relate to each other. These principles prevent the subtle bugs and architectural decay that emerge when inheritance and dependencies are misused. Master these, and you'll design systems that remain flexible for years.

📋 At a Glance

Aspect	Details
Principles Covered	LSP, ISP, DIP
Key Concept	Contracts and abstractions
Detection	UnsupportedOperationException, fat interfaces
Primary Pattern	Interface extraction, dependency injection
Business Impact	70% reduction in integration bugs

🎯 What You'll Learn

After reading this article, you will be able to:

Explain LSP with the Rectangle/Square example and real-world cases
Identify LSP violations through behavioral contract analysis
Detect fat interfaces and apply Interface Segregation
Distinguish DIP from DI (they're not the same!)
Design abstractions that don't leak implementation details
Apply these principles in Spring Boot applications

🔥 Production Story: The Substitution That Broke Production

An e-commerce platform had a class hierarchy for product inventory:

JAVA(31 lines)
Code
Loading syntax highlighter...

The disaster: Order processing code treated all products uniformly:

JAVA(7 lines)
Code
Loading syntax highlighter...

The fallout:

2,340 orders failed during Black Friday
$180,000 in lost sales
Customer trust damaged
3-day emergency fix

The root cause: LSP violation. BundleProduct was not a valid substitute for Product because it couldn't honor the setQuantity() contract.

The fix:

JAVA(24 lines)
Code
Loading syntax highlighter...

🧠 Mental Model: Contracts and Substitutability

TEXT(26 lines)
Code
Loading syntax highlighter...

The Rectangle/Square problem visualized:

TEXT(11 lines)
Code
Loading syntax highlighter...

🔬 Deep Dive

Part 1: Liskov Substitution Principle (LSP)

Definition: Objects of a superclass should be replaceable with objects of a subclass without breaking the program.

Formal rules:

Preconditions cannot be strengthened - Subtype must accept everything the parent accepts
Postconditions cannot be weakened - Subtype must guarantee at least what parent guarantees
Invariants must be preserved - If parent says "X is always true", subtype must maintain X
History constraint - Subtype cannot allow state changes parent would prohibit

Detecting LSP Violations

Red flags in code:

JAVA(32 lines)
Code
Loading syntax highlighter...

Fixing LSP Violations

Strategy 1: Extract common interface

JAVA(33 lines)
Code
Loading syntax highlighter...

Strategy 2: Composition over inheritance

JAVA(42 lines)
Code
Loading syntax highlighter...

Strategy 3: Design by Contract (DbC)

JAVA(24 lines)
Code
Loading syntax highlighter...

Part 2: Interface Segregation Principle (ISP)

Definition: Clients should not be forced to depend on interfaces they don't use.

Translation: Many specific interfaces are better than one general-purpose interface.

Detecting ISP Violations

The "Fat Interface" smell:

JAVA(19 lines)
Code
Loading syntax highlighter...

Refactoring to ISP

Step 1: Identify client needs

TEXT(4 lines)
Code
Loading syntax highlighter...

Step 2: Create role interfaces

JAVA(35 lines)
Code
Loading syntax highlighter...

ISP in Real-World Java

JDK Example - Collections:

JAVA(23 lines)
Code
Loading syntax highlighter...

Spring Example - Repository interfaces:

JAVA(26 lines)
Code
Loading syntax highlighter...

Part 3: Dependency Inversion Principle (DIP)

Definition:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Common confusion: DIP ≠ Dependency Injection

TEXT(8 lines)
Code
Loading syntax highlighter...

The Abstraction Ownership Problem

Wrong approach: Low-level module owns the interface

TEXT(11 lines)
Code
Loading syntax highlighter...

Correct approach: High-level module owns the interface

TEXT(17 lines)
Code
Loading syntax highlighter...

Implementing DIP in Spring

JAVA(43 lines)
Code
Loading syntax highlighter...

Abstractions That Don't Leak

Leaky abstraction: Exposes implementation details

JAVA(10 lines)
Code
Loading syntax highlighter...

Clean abstraction: Hides implementation details

JAVA(12 lines)
Code
Loading syntax highlighter...

⚠️ Common Mistakes

Mistake 1: Marker Interfaces That Lie

JAVA(7 lines)
Code
Loading syntax highlighter...

Mistake 2: Interface for Everything

JAVA(16 lines)
Code
Loading syntax highlighter...

Mistake 3: Wrong Abstraction Level

JAVA(13 lines)
Code
Loading syntax highlighter...

Mistake 4: Circular Dependencies via Abstraction

JAVA(23 lines)
Code
Loading syntax highlighter...

🐛 Debug This: The Square-Rectangle Paradox

A developer reports: "I have a failing test but the code looks perfectly correct. My Square extends Rectangle and my test says area should be 20, but I'm getting 25!"

JAVA(39 lines)
Code
Loading syntax highlighter...

Why does this "perfectly logical" code fail? Find the LSP violation!

✅ Solution:

This is the classic Square-Rectangle Problem - the most famous LSP violation.

The issue: Square violates LSP because it doesn't behave like a Rectangle should. A client using Rectangle expects:

setWidth(4) followed by setHeight(5) → area = 20
Width and height are independent

But Square couples them, breaking this expectation.

Why it fails:

rect.setWidth(4) sets both width AND height to 4
rect.setHeight(5) sets both width AND height to 5
Result: 5 × 5 = 25, not 4 × 5 = 20

The lesson: Mathematical "IS-A" relationships (a square IS a rectangle) don't always translate to behavioral substitutability. LSP is about behavior, not taxonomy. The fix: don't use inheritance here; use composition or separate interfaces.

💻 Exercises

Exercise 1: Fix the LSP Violation

⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes

Task: Refactor this code to fix the LSP violation.

JAVA(21 lines)
Code
Loading syntax highlighter...

✅ Solution:

JAVA(24 lines)
Code
Loading syntax highlighter...

Exercise 2: Apply ISP

⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes

Task: Split this fat interface into role-based interfaces.

JAVA(16 lines)
Code
Loading syntax highlighter...

✅ Solution:

JAVA(24 lines)
Code
Loading syntax highlighter...

Exercise 3: Apply DIP

⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 20 minutes

Task: Refactor to follow DIP - make high-level module own the abstraction.

JAVA(20 lines)
Code
Loading syntax highlighter...

✅ Solution:

JAVA(27 lines)
Code
Loading syntax highlighter...

Exercise 4: Design Service Layer with DIP

⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 25 minutes

Task: Design a payment service following DIP where the domain owns all abstractions.

JAVA(10 lines)
Code
Loading syntax highlighter...

✅ Solution:

JAVA(34 lines)
Code
Loading syntax highlighter...

Exercise 5: Complete SOLID Audit

⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 30 minutes

Task: Audit this class for ALL SOLID violations and refactor.

JAVA(24 lines)
Code
Loading syntax highlighter...

✅ Solution:

JAVA(54 lines)
Code
Loading syntax highlighter...

🎤 Senior-Level Interview Questions

Question #1: Explain LSP with a real example from your experience.

Strong answer:

In a previous project, we had a Cache interface with get() and put() methods. We created a ReadOnlyCache that threw exceptions on put().

The problem: Code like this broke:

JAVA(3 lines)
Code
Loading syntax highlighter...

The fix: We split into ReadableCache and WritableCache:

JAVA(7 lines)
Code
Loading syntax highlighter...

Now methods declare exactly what they need, and ReadOnlyCache implements only ReadableCache.

Question #2: How does ISP relate to microservices API design?

Strong answer:

ISP applies to APIs just like interfaces:

Fat API problem:

/api/orders - GET, POST, PUT, DELETE, GET analytics,
              GET reports, POST bulk, etc.

Mobile client only needs GET and POST but must handle entire contract.

ISP-inspired design:

/api/orders - Core CRUD (mobile client uses this)
/api/orders/analytics - Separate endpoint (dashboard uses this)
/api/orders/bulk - Separate endpoint (admin uses this)

Even better: GraphQL lets clients request exactly what they need.

Key insight: ISP is about not forcing clients to depend on things they don't use - applies to REST APIs, GraphQL schemas, SDK methods, everything.

Question #3: What's the difference between DIP and DI frameworks?

Strong answer:

DIP (principle): High-level modules should depend on abstractions, not concretions. Abstractions owned by high-level module.

DI framework (tool): Resolves and injects dependencies at runtime.

You can have DI without DIP:

JAVA(6 lines)
Code
Loading syntax highlighter...

You can have DIP without DI:

JAVA(7 lines)
Code
Loading syntax highlighter...

Best practice: Use both - DIP for design, DI framework for wiring.

Question #4: How do you test code that follows DIP?

Strong answer:

DIP makes testing trivial because you depend on abstractions:

JAVA(25 lines)
Code
Loading syntax highlighter...

Without DIP: Would need to mock concrete Stripe SDK, set up test credentials, etc.

Question #5: When is it OK to violate these principles?

Strong answer:

LSP violation acceptable:

Null Object pattern (intentionally different behavior)
Decorator that adds preconditions (with documentation)
Legacy wrapper gradually migrating behavior

ISP violation acceptable:

Small internal interfaces where splitting adds complexity
Performance-critical code where virtual dispatch matters
Marker interfaces (empty by design)

DIP violation acceptable:

Simple applications without swappable implementations
Performance-critical hot paths
Frameworks/libraries (they ARE the low-level module)

Key: Understand the principle, then make informed trade-offs.

Question #6: How do these principles interact with each other?

Strong answer:

They reinforce each other:

ISP enables LSP:

Small, focused interfaces have clearer contracts
Easier to implement fully (no UnsupportedOperationException)

DIP requires ISP:

High-level module defines focused interface it needs
Low-level implements only what's required

LSP enables DIP:

Substitutable implementations make abstraction meaningful
Can swap implementations confidently

Together they create:

Testable code (mock small interfaces)
Flexible architecture (swap implementations)
Stable high-level modules (insulated from changes)

📝 Summary & Key Takeaways

Liskov Substitution Principle

Aspect	Key Point
Definition	Subtypes must be substitutable for base types
Rules	Preconditions, postconditions, invariants
Detection	UnsupportedOperationException, instanceof checks
Fix	Extract interface, composition, DbC

Interface Segregation Principle

Aspect	Key Point
Definition	Clients shouldn't depend on unused methods
Detection	Empty implementations, UnsupportedOperationException
Fix	Split into role-based interfaces
Benefit	Smaller contracts, easier implementation

Dependency Inversion Principle

Aspect	Key Point
Definition	Depend on abstractions, not concretions
Key insight	High-level owns the abstraction
Not the same as	Dependency Injection (DI is technique, DIP is principle)
Benefit	Swappable implementations, testability

SOLID Summary Table

Principle	One-liner
SRP	One reason to change
OCP	Extend without modifying
LSP	Subtypes honor contracts
ISP	Small, focused interfaces
DIP	Depend on abstractions

🏁 Conclusion

LSP, ISP, and DIP complete the SOLID foundation. Together with SRP and OCP, they provide a framework for designing maintainable object-oriented systems.

Key insights:

LSP is about contracts, not just inheritance
ISP is about client needs, not interface size
DIP is about ownership, not just abstraction

Your next step: Continue to Part 4 (Code Smells - Complete Catalog) to learn how to detect problems that SOLID principles prevent.

📅 Review Schedule for This Article

Day	Task	Time
Day 1	Review LSP behavioral substitutability concept	5 min
Day 3	Redo Exercise 1 (Fix LSP Violation - Bird/Ostrich)	15 min
Day 7	Answer interview questions without looking	10 min
Day 14	Redo Debug This (Square-Rectangle Paradox)	10 min
Day 30	Review ISP in your current project - are there fat interfaces?	10 min

Next in series: [Part 4: Code Smells - Complete Catalog]

📋 At a Glance

🎯 What You'll Learn

🔥 Production Story: The Substitution That Broke Production

🧠 Mental Model: Contracts and Substitutability

🔬 Deep Dive

Part 1: Liskov Substitution Principle (LSP)

Detecting LSP Violations

Fixing LSP Violations

Part 2: Interface Segregation Principle (ISP)

Detecting ISP Violations

Refactoring to ISP

ISP in Real-World Java

Part 3: Dependency Inversion Principle (DIP)

The Abstraction Ownership Problem

Implementing DIP in Spring

Abstractions That Don't Leak

⚠️ Common Mistakes

Mistake 1: Marker Interfaces That Lie

Mistake 2: Interface for Everything

Mistake 3: Wrong Abstraction Level

Mistake 4: Circular Dependencies via Abstraction

🐛 Debug This: The Square-Rectangle Paradox

💻 Exercises

Exercise 1: Fix the LSP Violation

Exercise 2: Apply ISP

Exercise 3: Apply DIP

Exercise 4: Design Service Layer with DIP

Exercise 5: Complete SOLID Audit

🎤 Senior-Level Interview Questions

Question #1: Explain LSP with a real example from your experience.

Question #2: How does ISP relate to microservices API design?

Question #3: What's the difference between DIP and DI frameworks?

Question #4: How do you test code that follows DIP?

Question #5: When is it OK to violate these principles?

Question #6: How do these principles interact with each other?

📝 Summary & Key Takeaways

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

SOLID Summary Table

🏁 Conclusion

📅 Review Schedule for This Article

Tags: