[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":94,"_71":95,"_35":96},"articles",{"_11":12,"_13":14,"_15":16,"_17":16,"_18":19,"_20":21,"_22":23,"_24":23,"_25":16,"_26":27},"content",[30],"pageable",{"_28":21,"_29":19},"totalElements",1,"totalPages","size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_31":32,"_33":34,"_35":36,"_37":38,"_11":39,"_40":-5,"_41":23,"_42":27,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":52,"_54":55,"_56":57,"_58":59,"_60":52,"_61":16,"_62":55,"_63":64,"_65":66,"_67":68,"_69":70},"id",4,"title","SOLID: LSP, ISP, and DIP","slug","clean-code-part-3-solid-lsp-isp-dip","excerpt","Master Liskov Substitution, Interface Segregation, and Dependency Inversion principles. Learn patterns to prevent integration bugs and design flexible systems.","# Advanced Clean Code Patterns Part 3: SOLID - Liskov, Interface Segregation, Dependency Inversion\n\nThe 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.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Principles Covered | LSP, ISP, DIP |\n| Key Concept | Contracts and abstractions |\n| Detection | UnsupportedOperationException, fat interfaces |\n| Primary Pattern | Interface extraction, dependency injection |\n| Business Impact | 70% reduction in integration bugs |\n\n---\n\n## 🎯 What You'll Learn\n\nAfter reading this article, you will be able to:\n\n- **Explain LSP** with the Rectangle/Square example and real-world cases\n- **Identify LSP violations** through behavioral contract analysis\n- **Detect fat interfaces** and apply Interface Segregation\n- **Distinguish DIP from DI** (they're not the same!)\n- **Design abstractions** that don't leak implementation details\n- **Apply these principles** in Spring Boot applications\n\n---\n\n## 🔥 Production Story: The Substitution That Broke Production\n\nAn e-commerce platform had a class hierarchy for product inventory:\n\n```java\npublic class Product {\n protected int quantity;\n\n public void setQuantity(int quantity) {\n this.quantity = quantity;\n }\n\n public void decrementQuantity(int amount) {\n this.quantity -= amount;\n }\n}\n\npublic class BundleProduct extends Product {\n private List components;\n\n @Override\n public void setQuantity(int quantity) {\n // Bundles have calculated quantity - can't set directly!\n throw new UnsupportedOperationException(\n \"Bundle quantity is calculated from components\");\n }\n\n @Override\n public void decrementQuantity(int amount) {\n // Decrement each component proportionally\n for (Product component : components) {\n component.decrementQuantity(amount);\n }\n recalculateQuantity();\n }\n}\n```\n\n**The disaster:** Order processing code treated all products uniformly:\n\n```java\npublic void processOrder(Order order) {\n for (OrderItem item : order.getItems()) {\n Product product = item.getProduct();\n product.setQuantity(product.getQuantity() - item.getAmount());\n // BOOM! UnsupportedOperationException for bundles\n }\n}\n```\n\n**The fallout:**\n- 2,340 orders failed during Black Friday\n- $180,000 in lost sales\n- Customer trust damaged\n- 3-day emergency fix\n\n**The root cause:** LSP violation. BundleProduct was not a valid substitute for Product because it couldn't honor the `setQuantity()` contract.\n\n**The fix:**\n\n```java\n// ✅ After: Clear contract separation\npublic interface InventoryItem {\n int getAvailableQuantity();\n void reserve(int amount);\n void release(int amount);\n}\n\npublic class SimpleProduct implements InventoryItem {\n private int quantity;\n\n public void reserve(int amount) {\n if (amount > quantity) throw new InsufficientInventoryException();\n this.quantity -= amount;\n }\n}\n\npublic class BundleProduct implements InventoryItem {\n private List components;\n\n public void reserve(int amount) {\n // Reserve from all components\n components.forEach(c -> c.reserve(amount));\n }\n}\n```\n\n---\n\n## 🧠 Mental Model: Contracts and Substitutability\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ LSP: BEHAVIORAL CONTRACTS │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ A CONTRACT consists of: │\n│ │\n│ ┌─────────────────────────────────────────────────────────┐ │\n│ │ PRECONDITIONS (what caller must provide) │ │\n│ │ - Subtype can WEAKEN (accept more) │ │\n│ │ - Subtype cannot STRENGTHEN (demand more) │ │\n│ └─────────────────────────────────────────────────────────┘ │\n│ │\n│ ┌─────────────────────────────────────────────────────────┐ │\n│ │ POSTCONDITIONS (what method guarantees) │ │\n│ │ - Subtype can STRENGTHEN (guarantee more) │ │\n│ │ - Subtype cannot WEAKEN (guarantee less) │ │\n│ └─────────────────────────────────────────────────────────┘ │\n│ │\n│ ┌─────────────────────────────────────────────────────────┐ │\n│ │ INVARIANTS (what's always true) │ │\n│ │ - Subtype must PRESERVE all invariants │ │\n│ └─────────────────────────────────────────────────────────┘ │\n│ │\n│ VIOLATION = Subtype breaks any of these rules │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n**The Rectangle/Square problem visualized:**\n\n```text\nRectangle Contract:\n - setWidth(w): width becomes w, height unchanged\n - setHeight(h): height becomes h, width unchanged\n - Invariant: area = width × height\n\nSquare \"Subtype\":\n - setWidth(w): width becomes w, height becomes w (!)\n - setHeight(h): height becomes h, width becomes h (!)\n - Violates: \"height unchanged\" postcondition\n\nResult: Square is NOT a valid Rectangle subtype\n```\n\n---\n\n## 🔬 Deep Dive\n\n### Part 1: Liskov Substitution Principle (LSP)\n\n**Definition:** Objects of a superclass should be replaceable with objects of a subclass without breaking the program.\n\n**Formal rules:**\n\n1. **Preconditions cannot be strengthened** - Subtype must accept everything the parent accepts\n2. **Postconditions cannot be weakened** - Subtype must guarantee at least what parent guarantees\n3. **Invariants must be preserved** - If parent says \"X is always true\", subtype must maintain X\n4. **History constraint** - Subtype cannot allow state changes parent would prohibit\n\n---\n\n#### Detecting LSP Violations\n\n**Red flags in code:**\n\n```java\n// 🚩 Red Flag 1: instanceof checks\npublic void process(Animal animal) {\n if (animal instanceof Bird) {\n ((Bird) animal).fly();\n }\n // Why do we need to know the concrete type?\n}\n\n// 🚩 Red Flag 2: UnsupportedOperationException\npublic class ReadOnlyList extends ArrayList {\n @Override\n public boolean add(E e) {\n throw new UnsupportedOperationException();\n }\n}\n\n// 🚩 Red Flag 3: Empty overrides\npublic class NullLogger extends Logger {\n @Override\n public void log(String message) {\n // Do nothing - but callers expect logging!\n }\n}\n\n// 🚩 Red Flag 4: Different behavior for same input\npublic class Square extends Rectangle {\n @Override\n public void setWidth(int width) {\n super.setWidth(width);\n super.setHeight(width); // Unexpected side effect!\n }\n}\n```\n\n---\n\n#### Fixing LSP Violations\n\n**Strategy 1: Extract common interface**\n\n```java\n// ❌ Before: Flawed inheritance\npublic class Bird {\n public void fly() { ... }\n}\n\npublic class Penguin extends Bird {\n @Override\n public void fly() {\n throw new UnsupportedOperationException(\"Penguins can't fly!\");\n }\n}\n\n// ✅ After: Capability-based interfaces\npublic interface Bird {\n void eat();\n void sleep();\n}\n\npublic interface FlyingBird extends Bird {\n void fly();\n}\n\npublic class Sparrow implements FlyingBird {\n public void fly() { ... }\n public void eat() { ... }\n public void sleep() { ... }\n}\n\npublic class Penguin implements Bird {\n public void eat() { ... }\n public void sleep() { ... }\n // No fly() method - penguins are Birds, not FlyingBirds\n}\n```\n\n---\n\n**Strategy 2: Composition over inheritance**\n\n```java\n// ❌ Before: Inheritance-based reuse\npublic class Stack extends ArrayList {\n public E push(E item) {\n add(item);\n return item;\n }\n\n public E pop() {\n return remove(size() - 1);\n }\n // But Stack inherits get(index), add(index), etc. - broken abstraction!\n}\n\n// ✅ After: Composition\npublic class Stack {\n private final List elements = new ArrayList<>();\n\n public E push(E item) {\n elements.add(item);\n return item;\n }\n\n public E pop() {\n if (elements.isEmpty()) {\n throw new EmptyStackException();\n }\n return elements.remove(elements.size() - 1);\n }\n\n public E peek() {\n if (elements.isEmpty()) {\n throw new EmptyStackException();\n }\n return elements.get(elements.size() - 1);\n }\n\n public boolean isEmpty() {\n return elements.isEmpty();\n }\n\n // Only stack operations exposed!\n}\n```\n\n---\n\n**Strategy 3: Design by Contract (DbC)**\n\n```java\n// Explicit contract documentation\npublic interface Account {\n /**\n * Withdraws amount from account.\n *\n * @param amount must be positive\n * @throws IllegalArgumentException if amount <= 0\n * @throws InsufficientFundsException if amount > balance\n * @post balance = old balance - amount\n * @post balance >= 0\n */\n void withdraw(BigDecimal amount);\n}\n\n// All implementations must honor this contract\npublic class SavingsAccount implements Account {\n @Override\n public void withdraw(BigDecimal amount) {\n // Must throw IllegalArgumentException if amount <= 0\n // Must throw InsufficientFundsException if amount > balance\n // Must reduce balance by exactly amount\n // Must ensure balance >= 0 after\n }\n}\n```\n\n---\n\n### Part 2: Interface Segregation Principle (ISP)\n\n**Definition:** Clients should not be forced to depend on interfaces they don't use.\n\n**Translation:** Many specific interfaces are better than one general-purpose interface.\n\n---\n\n#### Detecting ISP Violations\n\n**The \"Fat Interface\" smell:**\n\n```java\n// ❌ Fat Interface - too many methods\npublic interface Worker {\n void work();\n void eat();\n void sleep();\n void attendMeeting();\n void writeReport();\n void managePeople();\n void writeCode();\n void designSystem();\n}\n\n// Robot workers can't eat or sleep\npublic class RobotWorker implements Worker {\n public void work() { /* OK */ }\n public void eat() { throw new UnsupportedOperationException(); }\n public void sleep() { throw new UnsupportedOperationException(); }\n // ...\n}\n```\n\n---\n\n#### Refactoring to ISP\n\n**Step 1: Identify client needs**\n\n```text\nHumanWorker needs: work, eat, sleep, attendMeeting\nRobotWorker needs: work\nManager needs: work, attendMeeting, managePeople\nDeveloper needs: work, writeCode, designSystem\n```\n\n**Step 2: Create role interfaces**\n\n```java\n// ✅ Segregated interfaces\npublic interface Workable {\n void work();\n}\n\npublic interface Feedable {\n void eat();\n void sleep();\n}\n\npublic interface Meetable {\n void attendMeeting();\n}\n\npublic interface Manageable {\n void managePeople();\n}\n\npublic interface Technical {\n void writeCode();\n void designSystem();\n}\n\n// Compose as needed\npublic class HumanWorker implements Workable, Feedable, Meetable {\n // Only implements what humans do\n}\n\npublic class RobotWorker implements Workable {\n // Only implements what robots do\n}\n\npublic class TechManager implements Workable, Meetable, Manageable, Technical {\n // Combines multiple roles\n}\n```\n\n---\n\n#### ISP in Real-World Java\n\n**JDK Example - Collections:**\n\n```java\n// JDK segregated interfaces well\npublic interface Iterable {\n Iterator iterator();\n}\n\npublic interface Collection extends Iterable {\n int size();\n boolean isEmpty();\n boolean contains(Object o);\n boolean add(E e);\n boolean remove(Object o);\n // ...\n}\n\npublic interface List extends Collection {\n E get(int index);\n E set(int index, E element);\n // Index-based operations\n}\n\npublic interface Set extends Collection {\n // No additional methods - just contract for uniqueness\n}\n```\n\n**Spring Example - Repository interfaces:**\n\n```java\n// ✅ Spring's segregated repository interfaces\npublic interface Repository { }\n\npublic interface CrudRepository extends Repository {\n S save(S entity);\n Optional findById(ID id);\n void deleteById(ID id);\n // Basic CRUD only\n}\n\npublic interface PagingAndSortingRepository\n extends CrudRepository {\n Page findAll(Pageable pageable);\n // Adds pagination\n}\n\npublic interface JpaRepository\n extends PagingAndSortingRepository {\n void flush();\n // Adds JPA-specific operations\n}\n\n// Use only what you need\npublic interface UserRepository extends CrudRepository {\n // Don't need pagination? Don't extend PagingAndSortingRepository\n}\n```\n\n---\n\n### Part 3: Dependency Inversion Principle (DIP)\n\n**Definition:**\n- High-level modules should not depend on low-level modules. Both should depend on abstractions.\n- Abstractions should not depend on details. Details should depend on abstractions.\n\n**Common confusion:** DIP ≠ Dependency Injection\n\n```text\nDIP = Design principle (WHAT to do)\n \"Depend on abstractions, not concretions\"\n\nDI = Implementation technique (HOW to do it)\n \"Have dependencies provided from outside\"\n\nYou can have DI without DIP: Injecting concrete classes\nYou can have DIP without DI: Factory patterns\n```\n\n---\n\n#### The Abstraction Ownership Problem\n\n**Wrong approach:** Low-level module owns the interface\n\n```text\n┌─────────────────┐ ┌─────────────────┐\n│ OrderService │───────→│ MySQLRepository│\n│ (high-level) │ │ (low-level) │\n└─────────────────┘ └────────┬────────┘\n │\n ┌────────┴────────┐\n │ Repository │\n │ (interface) │\n └─────────────────┘\n\nProblem: High-level depends on low-level package\n```\n\n**Correct approach:** High-level module owns the interface\n\n```text\n┌─────────────────────────────────────────────┐\n│ ORDER MODULE (high-level) │\n│ ┌─────────────────┐ ┌─────────────────┐ │\n│ │ OrderService │─→│ Repository │ │\n│ │ │ │ (interface) │ │\n│ └─────────────────┘ └────────▲────────┘ │\n└────────────────────────────────┼────────────┘\n │\n ┌────────────┴────────────┐\n │ PERSISTENCE MODULE │\n │ ┌──────────────────┐ │\n │ │ MySQLRepository │ │\n │ │ (implements) │ │\n │ └──────────────────┘ │\n └─────────────────────────┘\n\nCorrect: Low-level depends on high-level's abstraction\n```\n\n---\n\n#### Implementing DIP in Spring\n\n```java\n// ✅ Correct DIP implementation\n\n// 1. High-level module defines the abstraction it needs\n// Located in: com.example.order.domain\npublic interface PaymentGateway {\n PaymentResult charge(PaymentRequest request);\n}\n\n// 2. High-level module uses only the abstraction\n// Located in: com.example.order.service\n@Service\npublic class OrderService {\n private final PaymentGateway paymentGateway; // Depends on abstraction\n\n public OrderService(PaymentGateway paymentGateway) {\n this.paymentGateway = paymentGateway;\n }\n\n public Order placeOrder(OrderRequest request) {\n PaymentResult result = paymentGateway.charge(\n new PaymentRequest(request.getTotal())\n );\n // ...\n }\n}\n\n// 3. Low-level module implements the abstraction\n// Located in: com.example.payment.stripe\n@Component\npublic class StripePaymentGateway implements PaymentGateway {\n private final StripeClient stripeClient;\n\n @Override\n public PaymentResult charge(PaymentRequest request) {\n // Stripe-specific implementation\n }\n}\n\n// Dependency direction:\n// OrderService → PaymentGateway ← StripePaymentGateway\n//\n// Both high and low-level depend on the abstraction!\n// Low-level module depends on high-level's package (inverted)\n```\n\n---\n\n#### Abstractions That Don't Leak\n\n**Leaky abstraction:** Exposes implementation details\n\n```java\n// ❌ Leaky - exposes SQL concepts\npublic interface UserRepository {\n List findByNativeQuery(String sql); // Leaks SQL!\n void executeUpdate(String sql); // Leaks SQL!\n}\n\n// ❌ Leaky - exposes HTTP concepts\npublic interface PaymentGateway {\n Response postPayment(HttpRequest request); // Leaks HTTP!\n}\n```\n\n**Clean abstraction:** Hides implementation details\n\n```java\n// ✅ Clean - domain language only\npublic interface UserRepository {\n Optional findById(UserId id);\n List findByStatus(UserStatus status);\n void save(User user);\n}\n\n// ✅ Clean - domain language only\npublic interface PaymentGateway {\n PaymentResult charge(Money amount, PaymentMethod method);\n RefundResult refund(PaymentId paymentId, Money amount);\n}\n```\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: Marker Interfaces That Lie\n\n```java\n// ❌ Interface says \"Serializable\" but subtype can't serialize\npublic class TransientConnection implements Serializable {\n private Socket socket; // Socket is not serializable!\n\n // This class claims to be Serializable but will throw\n // NotSerializableException at runtime\n}\n```\n\n---\n\n### Mistake 2: Interface for Everything\n\n```java\n// ❌ Unnecessary abstraction\npublic interface UserMapper {\n UserDto toDto(User user);\n}\n\npublic class UserMapperImpl implements UserMapper {\n // Only one implementation, ever\n}\n\n// ✅ Just use the class\npublic class UserMapper {\n public UserDto toDto(User user) { ... }\n}\n\n// Create interface when you actually need multiple implementations\n// or for testing boundaries\n```\n\n---\n\n### Mistake 3: Wrong Abstraction Level\n\n```java\n// ❌ Abstraction too low-level\npublic interface DataStore {\n void connect();\n void disconnect();\n ResultSet executeQuery(String sql);\n}\n\n// ✅ Abstraction at domain level\npublic interface OrderRepository {\n Optional findById(OrderId id);\n List findByCustomer(CustomerId customerId);\n void save(Order order);\n}\n```\n\n---\n\n### Mistake 4: Circular Dependencies via Abstraction\n\n```java\n// ❌ Circular dependency\n// Module A\npublic interface ServiceA {\n void doA(ServiceB b); // Depends on B's interface\n}\n\n// Module B\npublic interface ServiceB {\n void doB(ServiceA a); // Depends on A's interface\n}\n\n// ✅ Break cycle with events or mediator\npublic interface EventPublisher {\n void publish(DomainEvent event);\n}\n\npublic class ServiceA {\n private final EventPublisher publisher;\n\n public void doA() {\n publisher.publish(new WorkCompleted());\n }\n}\n```\n\n---\n\n## 🐛 Debug This: The Square-Rectangle Paradox\n\nA 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!\"\n\n```java\npublic class Rectangle {\n protected int width;\n protected int height;\n\n public void setWidth(int width) {\n this.width = width;\n }\n\n public void setHeight(int height) {\n this.height = height;\n }\n\n public int getArea() {\n return width * height;\n }\n}\n\npublic class Square extends Rectangle {\n @Override\n public void setWidth(int width) {\n this.width = width;\n this.height = width; // Keep it square!\n }\n\n @Override\n public void setHeight(int height) {\n this.width = height;\n this.height = height; // Keep it square!\n }\n}\n\n// Test that's failing\n@Test\npublic void testRectangleArea() {\n Rectangle rect = new Square(); // Should work - Square IS-A Rectangle, right?\n rect.setWidth(4);\n rect.setHeight(5);\n assertEquals(20, rect.getArea()); // Expected: 20, Actual: 25!\n}\n```\n\n**Why does this \"perfectly logical\" code fail? Find the LSP violation!**\n\n---\n\n**✅ Solution:**\n\nThis is the classic **Square-Rectangle Problem** - the most famous LSP violation.\n\n**The issue:** `Square` violates LSP because it doesn't behave like a `Rectangle` should. A client using `Rectangle` expects:\n- `setWidth(4)` followed by `setHeight(5)` → area = 20\n- Width and height are independent\n\nBut `Square` couples them, breaking this expectation.\n\n**Why it fails:**\n1. `rect.setWidth(4)` sets both width AND height to 4\n2. `rect.setHeight(5)` sets both width AND height to 5\n3. Result: 5 × 5 = 25, not 4 × 5 = 20\n\n**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.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Fix the LSP Violation\n⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes\n\n**Task:** Refactor this code to fix the LSP violation.\n\n```java\npublic class Bird {\n public void fly() {\n System.out.println(\"Flying...\");\n }\n\n public void eat() {\n System.out.println(\"Eating...\");\n }\n}\n\npublic class Ostrich extends Bird {\n @Override\n public void fly() {\n throw new UnsupportedOperationException(\"Ostriches can't fly!\");\n }\n}\n\n// This code should work with any Bird\npublic void makeBirdFly(Bird bird) {\n bird.fly(); // Breaks for Ostrich!\n}\n```\n\n**✅ Solution:**\n\n```java\n// Separate behavior interfaces\npublic interface Flyable {\n void fly();\n}\n\npublic interface Eatable {\n void eat();\n}\n\n// Birds compose behaviors\npublic class Sparrow implements Flyable, Eatable {\n public void fly() { System.out.println(\"Flying...\"); }\n public void eat() { System.out.println(\"Eating...\"); }\n}\n\npublic class Ostrich implements Eatable {\n // No fly() - doesn't implement Flyable\n public void eat() { System.out.println(\"Eating...\"); }\n}\n\n// Safe method - only accepts Flyable birds\npublic void makeBirdFly(Flyable bird) {\n bird.fly(); // Type-safe - only flyable birds allowed\n}\n```\n\n---\n\n### Exercise 2: Apply ISP\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n**Task:** Split this fat interface into role-based interfaces.\n\n```java\npublic interface Machine {\n void print(Document doc);\n void scan(Document doc);\n void fax(Document doc);\n void copy(Document doc);\n void staple(Document doc);\n}\n\n// SimplePrinter only prints - forced to implement everything\npublic class SimplePrinter implements Machine {\n public void print(Document doc) { /* works */ }\n public void scan(Document doc) { throw new UnsupportedOperationException(); }\n public void fax(Document doc) { throw new UnsupportedOperationException(); }\n public void copy(Document doc) { throw new UnsupportedOperationException(); }\n public void staple(Document doc) { throw new UnsupportedOperationException(); }\n}\n```\n\n**✅ Solution:**\n\n```java\n// Role-based interfaces\npublic interface Printer {\n void print(Document doc);\n}\n\npublic interface Scanner {\n void scan(Document doc);\n}\n\npublic interface Fax {\n void fax(Document doc);\n}\n\n// SimplePrinter only implements what it needs\npublic class SimplePrinter implements Printer {\n public void print(Document doc) { /* works */ }\n}\n\n// MultiFunctionPrinter implements multiple interfaces\npublic class MultiFunctionPrinter implements Printer, Scanner, Fax {\n public void print(Document doc) { /* works */ }\n public void scan(Document doc) { /* works */ }\n public void fax(Document doc) { /* works */ }\n}\n```\n\n---\n\n### Exercise 3: Apply DIP\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 20 minutes\n\n**Task:** Refactor to follow DIP - make high-level module own the abstraction.\n\n```java\n// Low-level module\npackage com.example.infrastructure.email;\n\npublic interface EmailSender {\n void send(String to, String subject, String body);\n}\n\npublic class SmtpEmailSender implements EmailSender {\n // SMTP implementation\n}\n\n// High-level module - DEPENDS ON low-level package!\npackage com.example.domain.notification;\n\nimport com.example.infrastructure.email.EmailSender; // Wrong direction!\n\npublic class NotificationService {\n private final EmailSender emailSender;\n // ...\n}\n```\n\n**✅ Solution:**\n\n```java\n// Interface OWNED BY high-level module\npackage com.example.domain.notification;\n\npublic interface MessageSender { // Defined in domain, not infrastructure\n void send(String to, String subject, String body);\n}\n\n@Service\npublic class NotificationService {\n private final MessageSender messageSender; // Depends on abstraction it owns\n\n public NotificationService(MessageSender messageSender) {\n this.messageSender = messageSender;\n }\n}\n\n// Low-level module IMPLEMENTS the domain interface\npackage com.example.infrastructure.email;\n\nimport com.example.domain.notification.MessageSender; // Correct direction!\n\n@Component\npublic class SmtpMessageSender implements MessageSender {\n public void send(String to, String subject, String body) {\n // SMTP implementation\n }\n}\n```\n\n---\n\n### Exercise 4: Design Service Layer with DIP\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 25 minutes\n\n**Task:** Design a payment service following DIP where the domain owns all abstractions.\n\n```java\n// Current (violates DIP):\npackage com.example.payment;\n\nimport com.example.stripe.StripeClient; // Domain depends on infrastructure!\nimport com.example.database.PaymentDao; // Domain depends on database!\n\npublic class PaymentService {\n private final StripeClient stripe;\n private final PaymentDao dao;\n}\n```\n\n**✅ Solution:**\n\n```java\n// Domain owns the interfaces\npackage com.example.payment.domain;\n\npublic interface PaymentGateway {\n PaymentResult charge(PaymentRequest request);\n void refund(String transactionId);\n}\n\npublic interface PaymentRepository {\n void save(Payment payment);\n Optional findById(String id);\n}\n\n@Service\npublic class PaymentService {\n private final PaymentGateway gateway; // Domain-owned interface\n private final PaymentRepository repository; // Domain-owned interface\n}\n\n// Infrastructure implements domain interfaces\npackage com.example.payment.infrastructure;\n\nimport com.example.payment.domain.PaymentGateway;\n\n@Component\npublic class StripePaymentGateway implements PaymentGateway {\n private final StripeClient stripeClient;\n // ...\n}\n\n@Repository\npublic class JpaPaymentRepository implements PaymentRepository {\n // JPA implementation\n}\n```\n\n---\n\n### Exercise 5: Complete SOLID Audit\n⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 30 minutes\n\n**Task:** Audit this class for ALL SOLID violations and refactor.\n\n```java\npublic class ReportService {\n private JdbcTemplate jdbcTemplate;\n private SmtpMailSender mailSender;\n private S3Client s3Client;\n\n // SRP violation: multiple responsibilities\n public Report generateReport(Criteria criteria) {\n List data = jdbcTemplate.query(...); // Data fetching\n Report report = transformToReport(data); // Report generation\n byte[] pdf = renderPdf(report); // PDF rendering\n String url = s3Client.upload(pdf); // Storage\n mailSender.send(url); // Notification\n return report;\n }\n\n // OCP violation: switch statement\n public BigDecimal calculateBonus(Employee e) {\n switch (e.getType()) {\n case SALES: return e.getSales().multiply(new BigDecimal(\"0.1\"));\n case DEVELOPER: return new BigDecimal(\"1000\");\n default: return BigDecimal.ZERO;\n }\n }\n}\n```\n\n**✅ Solution:**\n\n```java\n// SRP: Split into focused services\n@Service\npublic class ReportDataService {\n private final ReportRepository repository; // DIP: depends on abstraction\n public List fetchData(Criteria criteria) { ... }\n}\n\n@Service\npublic class ReportGenerator {\n public Report generate(List data) { ... }\n}\n\n@Service\npublic class PdfRenderer {\n public byte[] render(Report report) { ... }\n}\n\n// DIP: Domain owns interface\npublic interface ReportStorage {\n String store(byte[] content);\n}\n\n// OCP: Strategy pattern for bonus calculation\npublic interface BonusCalculator {\n BigDecimal calculate(Employee employee);\n EmployeeType getType();\n}\n\n@Component\npublic class SalesBonusCalculator implements BonusCalculator {\n public EmployeeType getType() { return EmployeeType.SALES; }\n public BigDecimal calculate(Employee e) {\n return e.getSales().multiply(new BigDecimal(\"0.1\"));\n }\n}\n\n// Orchestration service\n@Service\npublic class ReportOrchestrator {\n private final ReportDataService dataService;\n private final ReportGenerator generator;\n private final PdfRenderer renderer;\n private final ReportStorage storage;\n private final NotificationSender notificationSender;\n\n public String createAndDistributeReport(Criteria criteria) {\n List data = dataService.fetchData(criteria);\n Report report = generator.generate(data);\n byte[] pdf = renderer.render(report);\n String url = storage.store(pdf);\n notificationSender.notify(url);\n return url;\n }\n}\n```\n\n---\n\n## 🎤 Senior-Level Interview Questions\n\n### Question #1: Explain LSP with a real example from your experience.\n\n**Strong answer:**\n\nIn a previous project, we had a `Cache` interface with `get()` and `put()` methods. We created a `ReadOnlyCache` that threw exceptions on `put()`.\n\n**The problem:** Code like this broke:\n```java\nvoid updateCache(Cache cache, String key, Object value) {\n cache.put(key, value); // Throws for ReadOnlyCache!\n}\n```\n\n**The fix:** We split into `ReadableCache` and `WritableCache`:\n```java\ninterface ReadableCache {\n Object get(String key);\n}\n\ninterface WritableCache extends ReadableCache {\n void put(String key, Object value);\n}\n```\n\nNow methods declare exactly what they need, and ReadOnlyCache implements only `ReadableCache`.\n\n---\n\n### Question #2: How does ISP relate to microservices API design?\n\n**Strong answer:**\n\nISP applies to APIs just like interfaces:\n\n**Fat API problem:**\n```\n/api/orders - GET, POST, PUT, DELETE, GET analytics,\n GET reports, POST bulk, etc.\n```\n\nMobile client only needs GET and POST but must handle entire contract.\n\n**ISP-inspired design:**\n```\n/api/orders - Core CRUD (mobile client uses this)\n/api/orders/analytics - Separate endpoint (dashboard uses this)\n/api/orders/bulk - Separate endpoint (admin uses this)\n```\n\nEven better: GraphQL lets clients request exactly what they need.\n\n**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.\n\n---\n\n### Question #3: What's the difference between DIP and DI frameworks?\n\n**Strong answer:**\n\n**DIP (principle):** High-level modules should depend on abstractions, not concretions. Abstractions owned by high-level module.\n\n**DI framework (tool):** Resolves and injects dependencies at runtime.\n\n**You can have DI without DIP:**\n```java\n@Service\npublic class OrderService {\n @Autowired\n private MySQLOrderRepository repository; // Concrete class!\n // DI is used, but DIP is violated\n}\n```\n\n**You can have DIP without DI:**\n```java\npublic class OrderService {\n private final OrderRepository repository;\n\n public OrderService() {\n this.repository = RepositoryFactory.create(); // Factory, no DI\n }\n}\n```\n\n**Best practice:** Use both - DIP for design, DI framework for wiring.\n\n---\n\n### Question #4: How do you test code that follows DIP?\n\n**Strong answer:**\n\nDIP makes testing trivial because you depend on abstractions:\n\n```java\n// Production code\n@Service\npublic class PaymentService {\n private final PaymentGateway gateway; // Abstraction\n\n public PaymentResult process(Payment payment) {\n return gateway.charge(payment.getAmount());\n }\n}\n\n// Test - inject fake\nclass PaymentServiceTest {\n @Test\n void successfulPayment() {\n // Create test double\n PaymentGateway fakeGateway = amount ->\n PaymentResult.success(\"TXN-123\");\n\n PaymentService service = new PaymentService(fakeGateway);\n\n PaymentResult result = service.process(payment);\n\n assertEquals(\"TXN-123\", result.getTransactionId());\n }\n}\n```\n\n**Without DIP:** Would need to mock concrete Stripe SDK, set up test credentials, etc.\n\n---\n\n### Question #5: When is it OK to violate these principles?\n\n**Strong answer:**\n\n**LSP violation acceptable:**\n- Null Object pattern (intentionally different behavior)\n- Decorator that adds preconditions (with documentation)\n- Legacy wrapper gradually migrating behavior\n\n**ISP violation acceptable:**\n- Small internal interfaces where splitting adds complexity\n- Performance-critical code where virtual dispatch matters\n- Marker interfaces (empty by design)\n\n**DIP violation acceptable:**\n- Simple applications without swappable implementations\n- Performance-critical hot paths\n- Frameworks/libraries (they ARE the low-level module)\n\n**Key:** Understand the principle, then make informed trade-offs.\n\n---\n\n### Question #6: How do these principles interact with each other?\n\n**Strong answer:**\n\nThey reinforce each other:\n\n**ISP enables LSP:**\n- Small, focused interfaces have clearer contracts\n- Easier to implement fully (no UnsupportedOperationException)\n\n**DIP requires ISP:**\n- High-level module defines focused interface it needs\n- Low-level implements only what's required\n\n**LSP enables DIP:**\n- Substitutable implementations make abstraction meaningful\n- Can swap implementations confidently\n\n**Together they create:**\n- Testable code (mock small interfaces)\n- Flexible architecture (swap implementations)\n- Stable high-level modules (insulated from changes)\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### Liskov Substitution Principle\n\n| Aspect | Key Point |\n|--------|-----------|\n| Definition | Subtypes must be substitutable for base types |\n| Rules | Preconditions, postconditions, invariants |\n| Detection | UnsupportedOperationException, instanceof checks |\n| Fix | Extract interface, composition, DbC |\n\n### Interface Segregation Principle\n\n| Aspect | Key Point |\n|--------|-----------|\n| Definition | Clients shouldn't depend on unused methods |\n| Detection | Empty implementations, UnsupportedOperationException |\n| Fix | Split into role-based interfaces |\n| Benefit | Smaller contracts, easier implementation |\n\n### Dependency Inversion Principle\n\n| Aspect | Key Point |\n|--------|-----------|\n| Definition | Depend on abstractions, not concretions |\n| Key insight | High-level owns the abstraction |\n| Not the same as | Dependency Injection (DI is technique, DIP is principle) |\n| Benefit | Swappable implementations, testability |\n\n### SOLID Summary Table\n\n| Principle | One-liner |\n|-----------|-----------|\n| **S**RP | One reason to change |\n| **O**CP | Extend without modifying |\n| **L**SP | Subtypes honor contracts |\n| **I**SP | Small, focused interfaces |\n| **D**IP | Depend on abstractions |\n\n---\n\n## 🏁 Conclusion\n\nLSP, ISP, and DIP complete the SOLID foundation. Together with SRP and OCP, they provide a framework for designing maintainable object-oriented systems.\n\n**Key insights:**\n- **LSP is about contracts**, not just inheritance\n- **ISP is about client needs**, not interface size\n- **DIP is about ownership**, not just abstraction\n\n**Your next step:** Continue to Part 4 (Code Smells - Complete Catalog) to learn how to detect problems that SOLID principles prevent.\n\n---\n\n## 📅 Review Schedule for This Article\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review LSP behavioral substitutability concept | 5 min |\n| Day 3 | Redo Exercise 1 (Fix LSP Violation - Bird/Ostrich) | 15 min |\n| Day 7 | Answer interview questions without looking | 10 min |\n| Day 14 | Redo Debug This (Square-Rectangle Paradox) | 10 min |\n| Day 30 | Review ISP in your current project - are there fat interfaces? | 10 min |\n\n---\n\n*Next in series: [Part 4: Code Smells - Complete Catalog]*\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:24.656230Z","createdAt","2026-06-10T07:19:24.657293Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",20,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Java","readingTime","seriesId","seriesOrder","author",{"_31":55,"_104":57,"_105":106,"_107":108,"_109":-5,"_110":-5,"_111":-5,"_112":-5,"_113":-5},"category",{"_31":100,"_71":59,"_35":101,"_74":102,"_103":-5},"tags",[77,78,79,80,81,82],"series",{"_31":16,"_71":72,"_35":73,"_74":75,"_76":23},"name","Advanced Clean Code Patterns: From Principles to Production Mastery","advanced-clean-code-patterns","description","A comprehensive 26-part series covering enterprise-grade clean code patterns for Java developers. From SOLID principles and code smells through refactoring patterns, error handling, validation, to legacy modernization and modern Java 21+ features. Includes real production stories, mental models, exercises, and 150+ interview questions.","isActive",{"_31":97,"_71":98,"_35":99},{"_31":94,"_71":95,"_35":96},{"_31":91,"_71":92,"_35":93},{"_31":88,"_71":89,"_35":90},{"_31":85,"_71":86,"_35":87},{"_31":52,"_71":83,"_35":84},"Solid","solid",25,"Lsp","lsp",28,"Liskov Substitution","liskov-substitution",26,"Isp","isp",27,"Dip","dip",29,"Dependency Inversion","dependency-inversion",5,"java","Category for Java","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]