[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":85,"_72":86,"_35":87},"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":63,"_64":65,"_66":67,"_68":69,"_70":71},"id",26,"title","Decision Guide and Cheatsheet","slug","clean-code-part-25-decision-guide","excerpt","Comprehensive reference: pattern selection decision trees, refactoring recipes, code smell mappings, 50 interview questions, and curated resources.","# Advanced Clean Code Patterns Part 25: Decision Guide & Cheatsheet\n\nThis final article serves as your comprehensive reference for the entire series. Bookmark it, print it, keep it open while coding. Here you'll find decision trees for pattern selection, quick refactoring recipes, a complete code smell catalog, 50 interview questions, and curated resources for further learning.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Purpose | Quick reference for pattern selection |\n| Contents | Decision trees, cheatsheets, Q&A bank |\n| Usage | Keep open while coding, review before interviews |\n| Interview Questions | 50 questions organized by topic |\n| Best For | Fast recall, decision making, interview prep |\n\n---\n\n## 🎯 What You'll Learn\n\nThis reference article provides:\n\n- **Pattern Decision Trees** - Flowcharts to choose the right pattern\n- **Refactoring Quick Reference** - Step-by-step recipes for common refactorings\n- **Code Smell → Refactoring Map** - What to apply when you detect a smell\n- **Interview Questions Bank** - 50 senior-level questions with answers\n- **IDE Shortcuts** - IntelliJ/VS Code refactoring commands\n- **Recommended Resources** - Books, courses, tools for further learning\n- **Complete Series Index** - Quick navigation to any topic\n\n---\n\n## 🔥 Production Story: The Refactoring Decision Paralysis\n\nA development team had a clear mandate: \"Clean up the payment module before Black Friday.\" They identified 47 code smells across 12 classes. But after two weeks, almost no progress had been made.\n\n**The problem?** Every code smell led to endless debates:\n\n```text\nDeveloper A: \"This switch statement needs Strategy pattern\"\nDeveloper B: \"No, it's fine with pattern matching\"\nDeveloper C: \"We should extract it to a separate service first\"\nResult: Nothing gets done\n```\n\nThe team was suffering from **decision paralysis**. Too many options, no clear criteria for choosing between them.\n\n**The solution?** They created decision trees with objective criteria:\n\n```text\nSwitch statement has > 5 cases?\n├── Yes → Does it switch on type? → Strategy Pattern\n├── No → Is it likely to grow?\n│ ├── Yes → Strategy Pattern (future-proof)\n│ └── No → Pattern Matching (simpler)\n```\n\nWith clear decision criteria, the team refactored all 47 smells in one week. This article is that decision guide, refined over years of real projects.\n\n---\n\n## 🧠 Mental Model: The Pattern Selection Framework\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ PATTERN SELECTION FRAMEWORK │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ Step 1: IDENTIFY THE SMELL │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ Long Method? Large Class? Primitive Obsession? │ │\n│ │ Switch Statement? Null Checks? Deep Inheritance? │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │ │\n│ ↓ │\n│ Step 2: MEASURE THE PROBLEM │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ Lines of code? Cyclomatic complexity? Number of cases? │ │\n│ │ Change frequency? Bug density? Test difficulty? │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │ │\n│ ↓ │\n│ Step 3: SELECT PATTERN (use decision trees below) │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ Match smell + metrics → Recommended pattern │ │\n│ │ Consider: team familiarity, codebase conventions │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │ │\n│ ↓ │\n│ Step 4: APPLY SAFELY │\n│ ┌──────────────────────────────────────────────────────────┐ │\n│ │ Characterization test → Refactor → Verify → Commit │ │\n│ │ Small steps, frequent commits, preserve behavior │ │\n│ └──────────────────────────────────────────────────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 🔬 Pattern Decision Trees\n\n### Decision Tree 1: Long Method (> 20 lines)\n\n```text\nMethod has > 20 lines?\n│\n├── Can you identify distinct \"paragraphs\" of logic?\n│ ├── Yes → EXTRACT METHOD for each paragraph\n│ │ (Part 6: Extract Patterns)\n│ │\n│ └── No → Is it mostly conditional logic?\n│ ├── Yes → See \"Conditional Logic\" tree below\n│ └── No → Is it a sequence of transformations?\n│ ├── Yes → PIPELINE PATTERN\n│ │ (Part 12: Chain & Pipeline)\n│ └── No → EXTRACT CLASS (too many responsibilities)\n│ (Part 6: Extract Patterns)\n```\n\n---\n\n### Decision Tree 2: Conditional Logic (switch/if-else)\n\n```text\nSwitch or if-else chain?\n│\n├── How many cases/branches?\n│ ├── 2-3 cases → Keep as-is or use PATTERN MATCHING (Java 17+)\n│ │ (Part 7: Replace Conditionals)\n│ │\n│ ├── 4-6 cases → Does it switch on TYPE?\n│ │ ├── Yes → STRATEGY PATTERN\n│ │ └── No → Is behavior stateful?\n│ │ ├── Yes → STATE PATTERN\n│ │ └── No → STRATEGY PATTERN or enum\n│ │\n│ └── 7+ cases → STRATEGY PATTERN with registration\n│ Consider: Rule Engine if complex conditions\n│ (Part 7: Replace Conditionals)\n│\n├── Will cases grow over time?\n│ ├── Yes → STRATEGY PATTERN (open for extension)\n│ └── No → PATTERN MATCHING may suffice\n│\n└── Cases have shared behavior?\n ├── Yes → TEMPLATE METHOD + Strategy\n └── No → Pure STRATEGY PATTERN\n```\n\n---\n\n### Decision Tree 3: Null Handling\n\n```text\nNull checks scattered in code?\n│\n├── Is null a valid domain state? (e.g., \"no discount\")\n│ ├── Yes → NULL OBJECT PATTERN\n│ │ (Part 8: Null Handling)\n│ │\n│ └── No → Where does null come from?\n│ │\n│ ├── Return value from method?\n│ │ └── Return OPTIONAL instead\n│ │\n│ ├── External API/database?\n│ │ └── Validate at boundary, fail fast\n│ │ Use Objects.requireNonNull()\n│ │\n│ └── Optional field in object?\n│ ├── Truly optional → Optional field\n│ └── Rare case → Consider splitting class\n│\n├── Java version?\n│ ├── Java 8+ → Use Optional\n│ └── Pre-Java 8 → Null Object or Guava Optional\n│\n└── Functional style preferred?\n ├── Yes → Consider Vavr Option/Either\n └── No → Standard Optional\n```\n\n---\n\n### Decision Tree 4: Object Creation Complexity\n\n```text\nComplex object creation?\n│\n├── How many constructor parameters?\n│ ├── 1-3 → Regular constructor is fine\n│ │\n│ ├── 4-6 → PARAMETER OBJECT or BUILDER\n│ │ Parameters related? → Parameter Object\n│ │ Parameters independent? → Builder\n│ │\n│ └── 7+ → Definitely BUILDER PATTERN\n│ Consider: Step Builder for required fields\n│ (Part 9: Builder & Factory)\n│\n├── Need multiple creation methods? (of, from, create)\n│ ├── Yes → STATIC FACTORY METHODS\n│ └── No → Constructor or Builder\n│\n├── Family of related objects?\n│ ├── Yes → ABSTRACT FACTORY\n│ └── No → Simple Factory or Builder\n│\n└── Object must be immutable?\n ├── Yes → Builder + Record (Java 16+)\n └── No → Builder or regular constructor\n```\n\n---\n\n### Decision Tree 5: Inheritance Problems\n\n```text\nInheritance causing problems?\n│\n├── What's the issue?\n│ │\n│ ├── Deep hierarchy (> 3 levels)?\n│ │ └── FLATTEN with COMPOSITION\n│ │ Replace inheritance with delegation\n│ │ (Part 10: Composition over Inheritance)\n│ │\n│ ├── Parallel hierarchies?\n│ │ └── BRIDGE PATTERN or composition\n│ │\n│ ├── Refused bequest (child doesn't use parent methods)?\n│ │ └── Replace with DELEGATION\n│ │ Child is-not-a Parent, extract common interface\n│ │\n│ └── Adding behavior dynamically?\n│ └── DECORATOR PATTERN\n│ (Part 10: Composition over Inheritance)\n│\n├── Need to share behavior across unrelated classes?\n│ ├── Yes → Interface with DEFAULT METHODS (Java 8+)\n│ │ or DELEGATION\n│ └── No → Regular composition\n│\n└── Spring AOP could solve it?\n ├── Yes → Use @Aspect for cross-cutting concerns\n └── No → Explicit Decorator\n```\n\n---\n\n### Decision Tree 6: Exception Handling\n\n```text\nException handling needs improvement?\n│\n├── What's the problem?\n│ │\n│ ├── Catching generic Exception?\n│ │ └── Define EXCEPTION HIERARCHY\n│ │ Domain → Application → Infrastructure\n│ │ (Part 14: Exception Hierarchy)\n│ │\n│ ├── Checked exceptions everywhere?\n│ │ └── Wrap in UNCHECKED exceptions\n│ │ Use exception chaining\n│ │\n│ ├── Exceptions used for flow control?\n│ │ └── RESULT PATTERN (Try/Either)\n│ │ (Part 15: Result Pattern)\n│ │\n│ └── Inconsistent error responses (API)?\n│ └── RFC 7807 Problem Details\n│ @ControllerAdvice\n│ (Part 16: Global Error Handling)\n│\n├── Expected vs unexpected failures?\n│ ├── Expected (validation, business rules) → Result Pattern\n│ └── Unexpected (bugs, infrastructure) → Exceptions\n│\n└── Need error accumulation?\n ├── Yes → Validation with error collection\n └── No → Fail-fast approach\n```\n\n---\n\n### Decision Tree 7: Legacy Code Refactoring\n\n```text\nLegacy code needs changes?\n│\n├── Is there test coverage?\n│ │\n│ ├── No tests → CHARACTERIZATION TESTS first!\n│ │ Document current behavior before changing\n│ │ (Part 20: Characterization Testing)\n│ │\n│ └── Has tests → Proceed with refactoring\n│\n├── Scope of change?\n│ │\n│ ├── Small (< 1 class) → SPROUT METHOD/CLASS\n│ │ Add new code in new method/class\n│ │ (Part 21: Breaking Dependencies)\n│ │\n│ ├── Medium (few classes) → WRAP METHOD/CLASS\n│ │ Wrap existing with new behavior\n│ │\n│ └── Large (module) → STRANGLER FIG PATTERN\n│ Incremental replacement\n│ (Part 22: Strangler Fig)\n│\n├── Can you test the class?\n│ ├── Yes → Refactor with test safety net\n│ └── No → BREAK DEPENDENCIES first\n│ Extract Interface, Parameterize Constructor\n│ (Part 21: Breaking Dependencies)\n│\n└── Need backward compatibility?\n ├── Yes → Branch by Abstraction + Feature Flags\n └── No → Direct replacement (still incremental)\n```\n\n---\n\n## 📋 Refactoring Quick Reference\n\n### Extract Method\n\n**When**: Method doing multiple things, comments explaining sections\n\n**Steps**:\n1. Identify code block to extract\n2. Create new method with descriptive name\n3. Pass needed variables as parameters\n4. Return any modified values\n5. Replace original code with method call\n6. Run tests\n\n**IntelliJ**: `Ctrl+Alt+M` (Windows) / `Cmd+Option+M` (Mac)\n\n```java\n// ❌ Before\npublic void processOrder(Order order) {\n // validate order\n if (order.getItems().isEmpty()) {\n throw new InvalidOrderException(\"No items\");\n }\n if (order.getTotal().isNegative()) {\n throw new InvalidOrderException(\"Invalid total\");\n }\n\n // calculate discount\n BigDecimal discount = BigDecimal.ZERO;\n if (order.getCustomer().isVip()) {\n discount = order.getTotal().multiply(new BigDecimal(\"0.1\"));\n }\n\n // save order\n order.setDiscount(discount);\n orderRepository.save(order);\n}\n\n// ✅ After\npublic void processOrder(Order order) {\n validateOrder(order);\n BigDecimal discount = calculateDiscount(order);\n saveOrder(order, discount);\n}\n\nprivate void validateOrder(Order order) {\n if (order.getItems().isEmpty()) {\n throw new InvalidOrderException(\"No items\");\n }\n if (order.getTotal().isNegative()) {\n throw new InvalidOrderException(\"Invalid total\");\n }\n}\n\nprivate BigDecimal calculateDiscount(Order order) {\n if (order.getCustomer().isVip()) {\n return order.getTotal().multiply(new BigDecimal(\"0.1\"));\n }\n return BigDecimal.ZERO;\n}\n\nprivate void saveOrder(Order order, BigDecimal discount) {\n order.setDiscount(discount);\n orderRepository.save(order);\n}\n```\n\n---\n\n### Extract Parameter Object\n\n**When**: Method has 4+ related parameters\n\n**Steps**:\n1. Create new class/record for parameters\n2. Move parameters to new class\n3. Update method signature\n4. Update all call sites\n5. Run tests\n\n**IntelliJ**: `Refactor → Extract Parameter Object`\n\n```java\n// ❌ Before\npublic void createUser(String firstName, String lastName,\n String email, String phone,\n String street, String city, String zipCode) {\n // ...\n}\n\n// ✅ After\npublic record CreateUserRequest(\n String firstName,\n String lastName,\n String email,\n String phone,\n Address address\n) {}\n\npublic record Address(String street, String city, String zipCode) {}\n\npublic void createUser(CreateUserRequest request) {\n // ...\n}\n```\n\n---\n\n### Replace Conditional with Strategy\n\n**When**: Switch/if-else with 4+ cases, especially on type\n\n**Steps**:\n1. Create Strategy interface\n2. Create implementation for each case\n3. Create factory/registry for strategies\n4. Replace switch with strategy lookup and call\n5. Run tests\n\n```java\n// ❌ Before\npublic BigDecimal calculateShipping(Order order) {\n return switch (order.getShippingType()) {\n case STANDARD -> order.getWeight().multiply(new BigDecimal(\"1.5\"));\n case EXPRESS -> order.getWeight().multiply(new BigDecimal(\"3.0\"));\n case OVERNIGHT -> order.getWeight().multiply(new BigDecimal(\"5.0\"));\n case INTERNATIONAL -> order.getWeight().multiply(new BigDecimal(\"10.0\"))\n .add(new BigDecimal(\"25.0\"));\n };\n}\n\n// ✅ After\npublic interface ShippingCalculator {\n BigDecimal calculate(Order order);\n}\n\n@Component\npublic class StandardShipping implements ShippingCalculator {\n public BigDecimal calculate(Order order) {\n return order.getWeight().multiply(new BigDecimal(\"1.5\"));\n }\n}\n\n@Component\npublic class ExpressShipping implements ShippingCalculator {\n public BigDecimal calculate(Order order) {\n return order.getWeight().multiply(new BigDecimal(\"3.0\"));\n }\n}\n// ... other implementations\n\n@Service\npublic class ShippingService {\n private final Map calculators;\n\n public ShippingService(List calculators) {\n this.calculators = calculators.stream()\n .collect(toMap(c -> c.getType(), identity()));\n }\n\n public BigDecimal calculateShipping(Order order) {\n return calculators.get(order.getShippingType())\n .calculate(order);\n }\n}\n```\n\n---\n\n### Introduce Null Object\n\n**When**: Null checks for same object repeated throughout code\n\n**Steps**:\n1. Create interface for the object (if not exists)\n2. Create NullObject implementation\n3. Return NullObject instead of null\n4. Remove null checks\n5. Run tests\n\n```java\n// ❌ Before\npublic class OrderService {\n public void process(Order order) {\n Discount discount = discountRepository.findForCustomer(order.getCustomer());\n\n BigDecimal discountAmount = BigDecimal.ZERO;\n if (discount != null) {\n discountAmount = discount.calculate(order.getTotal());\n }\n\n String discountCode = \"\";\n if (discount != null) {\n discountCode = discount.getCode();\n }\n\n // ... more null checks\n }\n}\n\n// ✅ After\npublic interface Discount {\n BigDecimal calculate(BigDecimal total);\n String getCode();\n\n Discount NONE = new Discount() {\n public BigDecimal calculate(BigDecimal total) { return BigDecimal.ZERO; }\n public String getCode() { return \"\"; }\n };\n}\n\npublic class PercentageDiscount implements Discount {\n private final String code;\n private final BigDecimal percentage;\n\n public BigDecimal calculate(BigDecimal total) {\n return total.multiply(percentage);\n }\n\n public String getCode() { return code; }\n}\n\n// Repository returns Discount.NONE instead of null\npublic class OrderService {\n public void process(Order order) {\n Discount discount = discountRepository.findForCustomer(order.getCustomer());\n // No null checks needed!\n BigDecimal discountAmount = discount.calculate(order.getTotal());\n String discountCode = discount.getCode();\n }\n}\n```\n\n---\n\n### Extract Interface for Testing\n\n**When**: Class is hard to test due to dependencies\n\n**Steps**:\n1. Identify methods used by clients\n2. Create interface with those methods\n3. Have class implement interface\n4. Update clients to depend on interface\n5. Create test double implementing interface\n6. Run tests\n\n**IntelliJ**: `Refactor → Extract Interface`\n\n```java\n// ❌ Before - hard to test\npublic class PaymentService {\n private final StripeClient stripeClient = new StripeClient();\n\n public PaymentResult process(Payment payment) {\n return stripeClient.charge(payment); // Can't mock this!\n }\n}\n\n// ✅ After - testable\npublic interface PaymentGateway {\n PaymentResult charge(Payment payment);\n}\n\npublic class StripePaymentGateway implements PaymentGateway {\n private final StripeClient stripeClient;\n\n public PaymentResult charge(Payment payment) {\n return stripeClient.charge(payment);\n }\n}\n\npublic class PaymentService {\n private final PaymentGateway paymentGateway;\n\n public PaymentService(PaymentGateway paymentGateway) {\n this.paymentGateway = paymentGateway;\n }\n\n public PaymentResult process(Payment payment) {\n return paymentGateway.charge(payment);\n }\n}\n\n// Test\n@Test\nvoid processPayment_success() {\n PaymentGateway mockGateway = mock(PaymentGateway.class);\n when(mockGateway.charge(any())).thenReturn(PaymentResult.success());\n\n PaymentService service = new PaymentService(mockGateway);\n // Now we can test!\n}\n```\n\n---\n\n## 📊 Code Smell → Refactoring Map\n\n| Code Smell | Severity | Refactoring | Article |\n|------------|----------|-------------|---------|\n| **Long Method** (> 20 lines) | High | Extract Method | Part 6 |\n| **Large Class** (> 200 lines) | High | Extract Class | Part 6 |\n| **Long Parameter List** (> 4) | Medium | Parameter Object | Part 6 |\n| **Primitive Obsession** | Medium | Value Object, Record | Part 6, 23 |\n| **Switch Statements** (> 4 cases) | Medium | Strategy Pattern | Part 7 |\n| **Parallel Conditionals** | High | Strategy, Template Method | Part 7, 13 |\n| **Null Checks Scattered** | High | Null Object, Optional | Part 8 |\n| **Telescoping Constructor** | Medium | Builder Pattern | Part 9 |\n| **Deep Inheritance** (> 3 levels) | High | Composition | Part 10 |\n| **Refused Bequest** | Medium | Delegation | Part 10 |\n| **Feature Envy** | Medium | Move Method | Part 6 |\n| **Inappropriate Intimacy** | Medium | Extract Class | Part 6 |\n| **Message Chains** | Low | Hide Delegate | Part 10 |\n| **Middle Man** | Low | Remove Middle Man | Part 10 |\n| **Comments Explaining Code** | Medium | Extract Method (self-documenting) | Part 6 |\n| **Duplicate Code** | High | Extract Method/Class | Part 6 |\n| **Dead Code** | Low | Delete it | - |\n| **Speculative Generality** | Medium | Remove unused abstraction | - |\n| **Divergent Change** | High | Extract Class (SRP) | Part 2, 6 |\n| **Shotgun Surgery** | High | Move Method, Extract Class | Part 2, 6 |\n| **Data Clumps** | Medium | Parameter Object | Part 6 |\n| **Lazy Class** | Low | Inline Class | - |\n| **Temporary Field** | Medium | Extract Class | Part 6 |\n| **Alternative Classes** | Medium | Extract Superclass/Interface | Part 6 |\n| **Incomplete Library Class** | Low | Decorator, Wrapper | Part 10 |\n\n---\n\n## 🎤 Interview Questions Bank (50 Questions)\n\n### SOLID Principles (10 Questions)\n\n#### Q1: What is Single Responsibility Principle and how do you identify violations?\n\n**Answer**: SRP states that a class should have only one reason to change - meaning it should serve only one actor or stakeholder.\n\n**Identifying violations**:\n- Class has methods serving different stakeholders (e.g., both UI and reporting)\n- Method names suggest different responsibilities (\"calculate\" and \"format\")\n- Change requests from different teams affect same class\n- LCOM (Lack of Cohesion) metric is high\n\n**Example**: `UserService` with methods like `createUser()`, `sendWelcomeEmail()`, `generateUserReport()` - these serve different actors.\n\n---\n\n#### Q2: Explain Open/Closed Principle with a real example.\n\n**Answer**: OCP states that software entities should be open for extension but closed for modification. You should be able to add new behavior without changing existing code.\n\n**Example**: Payment processing with Strategy pattern:\n\n```java\n// ✅ Open for extension (add new payment types)\n// ✅ Closed for modification (don't change existing code)\npublic interface PaymentProcessor {\n void process(Payment payment);\n}\n\n// Adding Bitcoin doesn't require modifying existing code\n@Component\npublic class BitcoinProcessor implements PaymentProcessor {\n public void process(Payment payment) { /* ... */ }\n}\n```\n\n---\n\n#### Q3: What's the Liskov Substitution Principle and what's the classic Rectangle/Square violation?\n\n**Answer**: LSP states that objects of a superclass should be replaceable with objects of subclasses without breaking the program.\n\n**Rectangle/Square violation**:\n```java\nclass Rectangle {\n void setWidth(int w) { this.width = w; }\n void setHeight(int h) { this.height = h; }\n}\n\nclass Square extends Rectangle {\n void setWidth(int w) {\n this.width = w;\n this.height = w; // Violates LSP!\n }\n}\n\n// Client code breaks:\nRectangle r = new Square();\nr.setWidth(5);\nr.setHeight(10);\nassert r.getArea() == 50; // Fails! Area is 100\n```\n\n**Solution**: Square is-not-a Rectangle. Use separate classes or immutable shapes.\n\n---\n\n#### Q4: When should you apply Interface Segregation Principle?\n\n**Answer**: Apply ISP when:\n- Clients are forced to implement methods they don't use\n- Interface has methods for multiple different purposes\n- Changes to unused methods force client recompilation\n- Test mocks become complex because of unneeded methods\n\n**Example of violation**:\n```java\n// ❌ Fat interface\ninterface Worker {\n void work();\n void eat();\n void sleep();\n}\n\nclass Robot implements Worker {\n void work() { /* OK */ }\n void eat() { throw new UnsupportedOperationException(); } // Violation!\n void sleep() { throw new UnsupportedOperationException(); } // Violation!\n}\n```\n\n---\n\n#### Q5: What's the difference between Dependency Inversion and Dependency Injection?\n\n**Answer**:\n\n**Dependency Inversion (DIP)** - design principle:\n- High-level modules shouldn't depend on low-level modules\n- Both should depend on abstractions\n- Abstractions shouldn't depend on details\n\n**Dependency Injection (DI)** - implementation technique:\n- Way to provide dependencies to an object\n- Constructor injection, setter injection, field injection\n\nDIP tells you *what* to do (depend on abstractions).\nDI tells you *how* to do it (inject dependencies).\n\nYou can have DI without DIP (injecting concrete classes).\nYou can have DIP without DI (factory patterns).\n\n---\n\n### Refactoring Patterns (10 Questions)\n\n#### Q6: How do you safely refactor a 500-line method?\n\n**Answer**:\n\n1. **Write characterization tests** - capture current behavior\n2. **Identify code \"paragraphs\"** - blocks separated by blank lines/comments\n3. **Extract one method at a time** - start with clearest, most isolated block\n4. **Run tests after each extraction**\n5. **Look for patterns** - repeated code → Extract Method\n6. **Identify responsibilities** - multiple responsibilities → Extract Class\n7. **Commit frequently** - small, reversible steps\n\n**Tools**: IntelliJ's Extract Method (`Ctrl+Alt+M`), automated tests\n\n---\n\n#### Q7: When would you use Strategy vs State pattern?\n\n**Answer**:\n\n**Strategy Pattern**:\n- Algorithm selection at runtime\n- Strategies are stateless/interchangeable\n- Client chooses the strategy\n- Example: Sorting algorithms, payment methods\n\n**State Pattern**:\n- Object behavior changes based on internal state\n- States manage transitions to other states\n- Object doesn't know current state details\n- Example: Order status, document workflow\n\n**Key difference**: Strategy = same input, different algorithms. State = same algorithm, different behavior based on state.\n\n---\n\n#### Q8: What's the Null Object pattern and when should you avoid it?\n\n**Answer**:\n\n**Null Object** provides an object with default/neutral behavior instead of null.\n\n**Use when**:\n- Null checks are repeated for same object\n- \"No action\" is a valid domain behavior\n- Want to simplify client code\n\n**Avoid when**:\n- Null has specific meaning (error, not found)\n- Masking errors would be dangerous (null in payment = problem!)\n- Object has side effects (logging, persistence)\n\n```java\n// Good: NullDiscount with zero discount\n// Bad: NullPaymentProcessor that silently does nothing\n```\n\n---\n\n#### Q9: Explain Builder pattern. When is Step Builder better?\n\n**Answer**:\n\n**Basic Builder**: Fluent interface for object construction with many parameters.\n\n**Step Builder**: Enforces required parameters at compile time by returning different types.\n\n```java\n// Step Builder - required fields enforced\nUser user = User.builder()\n .email(\"test@test.com\") // Returns RequiredName\n .name(\"John\") // Returns OptionalFields\n .age(30) // Optional\n .build();\n\n// Can't call .build() without email and name - compile error!\n```\n\n**Use Step Builder when**:\n- Some parameters are required\n- Want compile-time safety\n- API must be foolproof\n\n---\n\n#### Q10: How does composition solve the inheritance problems?\n\n**Answer**:\n\n**Inheritance problems**:\n- Fragile base class (changes break subclasses)\n- Forced to inherit unwanted behavior\n- Can only inherit from one class\n- Deep hierarchies hard to understand\n\n**Composition solves these**:\n```java\n// ❌ Inheritance\nclass Stack extends ArrayList { } // Gets all ArrayList methods!\n\n// ✅ Composition\nclass Stack {\n private final List items = new ArrayList<>();\n\n public void push(E item) { items.add(item); }\n public E pop() { return items.remove(items.size() - 1); }\n // Only exposes what Stack needs\n}\n```\n\n**Key insight**: \"has-a\" is usually better than \"is-a\".\n\n---\n\n### Error Handling (10 Questions)\n\n#### Q11: How do you design a good exception hierarchy?\n\n**Answer**:\n\n```text\nApplicationException (extends RuntimeException)\n├── DomainException\n│ ├── ValidationException\n│ ├── BusinessRuleException\n│ └── EntityNotFoundException\n├── InfrastructureException\n│ ├── DatabaseException\n│ └── ExternalServiceException\n└── SecurityException\n ├── AuthenticationException\n └── AuthorizationException\n```\n\n**Best practices**:\n- Extend RuntimeException (unchecked)\n- Include context (error code, correlation ID)\n- Layer-appropriate messages (no SQL errors to users)\n- Exception chaining (preserve root cause)\n\n---\n\n#### Q12: When should you use Result pattern vs exceptions?\n\n**Answer**:\n\n**Use Exceptions for**:\n- Truly exceptional situations (bugs, infrastructure failures)\n- Unrecoverable errors\n- When caller can't reasonably handle the error\n\n**Use Result Pattern for**:\n- Expected failures (validation, business rules)\n- When caller must handle the failure\n- Functional programming style\n- Accumulating multiple errors\n\n```java\n// Exceptions - unexpected\npublic User findById(Long id) {\n return repository.findById(id)\n .orElseThrow(() -> new EntityNotFoundException(\"User\", id));\n}\n\n// Result - expected failures\npublic Either createUser(UserRequest request) {\n return validate(request)\n .flatMap(this::checkDuplicates)\n .map(this::save);\n}\n```\n\n---\n\n#### Q13: What is RFC 7807 and why use it?\n\n**Answer**: RFC 7807 \"Problem Details for HTTP APIs\" is a standard format for error responses.\n\n**Structure**:\n```json\n{\n \"type\": \"https://api.example.com/problems/validation-error\",\n \"title\": \"Validation Error\",\n \"status\": 400,\n \"detail\": \"The email field is invalid\",\n \"instance\": \"/users/123\",\n \"errors\": [...]\n}\n```\n\n**Why use it**:\n- Industry standard (clients know what to expect)\n- Machine-readable error types (URI)\n- Extensible (add custom fields)\n- Spring 6 has built-in support\n\n---\n\n#### Q14: How do you prevent exceptions from leaking sensitive information?\n\n**Answer**:\n\n1. **Sanitize before logging**: Remove credentials, PII\n2. **Generic client messages**: \"An error occurred\" (details in logs)\n3. **Map internal to external**: SQLException → \"Database unavailable\"\n4. **Remove stack traces in production**: Only log correlation ID\n5. **Review exception messages**: No SQL, no file paths\n\n```java\n@ExceptionHandler(DatabaseException.class)\npublic ProblemDetail handleDatabase(DatabaseException ex) {\n log.error(\"Database error [correlationId={}]: {}\",\n correlationId, ex.getMessage(), ex); // Full details in logs\n\n return ProblemDetail.forStatus(503)\n .withDetail(\"Service temporarily unavailable\"); // Safe for client\n}\n```\n\n---\n\n#### Q15: What's exception chaining and why is it important?\n\n**Answer**: Exception chaining preserves the original cause when wrapping exceptions.\n\n```java\ntry {\n repository.save(entity);\n} catch (SQLException e) {\n // ❌ Bad - loses original cause\n throw new DataAccessException(\"Failed to save\");\n\n // ✅ Good - preserves cause\n throw new DataAccessException(\"Failed to save\", e);\n}\n```\n\n**Why important**:\n- Root cause visible in stack trace\n- Debugging is possible\n- Original exception type available via `getCause()`\n- Required for proper error analysis in production\n\n---\n\n### Validation (5 Questions)\n\n#### Q16: Bean Validation vs Fluent Validation - when to use each?\n\n**Answer**:\n\n**Bean Validation (JSR-380)**:\n- Annotation-based (`@NotNull`, `@Size`)\n- Standard, well-supported\n- Good for simple constraints\n- Integrates with Spring MVC\n\n**Fluent Validation**:\n- Programmatic, composable\n- Complex, conditional rules\n- Cross-field validation\n- Testable in isolation\n\n**Use Bean Validation for**: DTOs, simple objects, standard constraints\n**Use Fluent for**: Complex business rules, conditional validation, domain objects\n\n---\n\n#### Q17: How do you implement cross-field validation?\n\n**Answer**:\n\n```java\n// Custom constraint\n@Target(TYPE)\n@Constraint(validatedBy = DateRangeValidator.class)\npublic @interface ValidDateRange {\n String message() default \"End date must be after start date\";\n Class[] groups() default {};\n Class[] payload() default {};\n}\n\n// Validator\npublic class DateRangeValidator implements ConstraintValidator {\n public boolean isValid(DateRange range, ConstraintValidatorContext ctx) {\n if (range.getStart() == null || range.getEnd() == null) {\n return true; // Other validators handle null\n }\n return range.getEnd().isAfter(range.getStart());\n }\n}\n\n// Usage\n@ValidDateRange\npublic record DateRange(LocalDate start, LocalDate end) {}\n```\n\n---\n\n#### Q18: Fail-fast vs accumulate-all validation - trade-offs?\n\n**Answer**:\n\n**Fail-fast** (stop on first error):\n- ✅ Simple implementation\n- ✅ Efficient (no wasted checks)\n- ❌ Poor UX (fix one error, see next)\n- Use for: Security validation, quick checks\n\n**Accumulate-all** (collect all errors):\n- ✅ Better UX (see all problems at once)\n- ✅ Fewer round trips\n- ❌ More complex code\n- ❌ May waste resources on invalid input\n- Use for: Form validation, API requests\n\n```java\n// Accumulate-all with Vavr\npublic Validation, User> validate(UserRequest req) {\n return Validation.combine(\n validateEmail(req.getEmail()),\n validateName(req.getName()),\n validateAge(req.getAge())\n ).ap(User::new);\n}\n```\n\n---\n\n### Legacy Code (5 Questions)\n\n#### Q19: What are characterization tests and when do you write them?\n\n**Answer**: Characterization tests document the *current* behavior of code, not the *intended* behavior. They act as a safety net for refactoring.\n\n**When to write**:\n- Before refactoring legacy code\n- When specification is unclear\n- When you can't afford to break existing behavior\n\n**How to write**:\n1. Call the method with known input\n2. Capture actual output\n3. Assert that output (even if \"wrong\")\n4. Repeat for edge cases\n\n```java\n@Test\nvoid characterize_calculateDiscount_with_null_customer() {\n // Document current behavior (may be a bug!)\n BigDecimal result = service.calculateDiscount(null);\n assertEquals(BigDecimal.ZERO, result);\n // Now we know: null returns ZERO, not exception\n}\n```\n\n---\n\n#### Q20: Explain Strangler Fig pattern for legacy modernization.\n\n**Answer**: Strangler Fig is a pattern for incrementally replacing a legacy system by growing a new system around it.\n\n**Steps**:\n1. **Identify a feature** to replace\n2. **Build new implementation** alongside old\n3. **Route traffic** to new (start with small percentage)\n4. **Gradually increase** traffic to new\n5. **Remove old** when new is proven\n6. **Repeat** for next feature\n\n**Benefits**:\n- No big bang rewrite\n- Can roll back if issues\n- Continuous delivery\n- Lower risk\n\n**Implementation**: Feature flags, API gateway routing, database replication\n\n---\n\n### Modern Java (5 Questions)\n\n#### Q21: When should you use Records vs Classes?\n\n**Answer**:\n\n**Use Records for**:\n- Immutable data carriers (DTOs, events, value objects)\n- Simple data aggregation\n- Pattern matching targets\n\n**Use Classes for**:\n- Mutable state needed\n- Complex validation in constructor\n- Non-data behavior (services, controllers)\n- Inheritance needed (records are final)\n\n```java\n// Perfect for Record\npublic record Money(BigDecimal amount, Currency currency) {}\n\n// Better as Class\npublic class BankAccount {\n private BigDecimal balance;\n public void deposit(Money money) { ... }\n}\n```\n\n---\n\n#### Q22: How do Sealed Classes enable exhaustive pattern matching?\n\n**Answer**: Sealed classes restrict which classes can extend them, enabling compiler-verified exhaustive matching.\n\n```java\npublic sealed interface Shape\n permits Circle, Rectangle, Triangle {}\n\npublic record Circle(double radius) implements Shape {}\npublic record Rectangle(double width, double height) implements Shape {}\npublic record Triangle(double a, double b, double c) implements Shape {}\n\n// Compiler knows all cases - no default needed!\npublic double area(Shape shape) {\n return switch (shape) {\n case Circle c -> Math.PI * c.radius() * c.radius();\n case Rectangle r -> r.width() * r.height();\n case Triangle t -> heronFormula(t);\n // No default needed - compiler verified exhaustive\n };\n}\n```\n\n---\n\n### Spring Boot (5 Questions)\n\n#### Q23: Why prefer constructor injection over field injection?\n\n**Answer**:\n\n**Constructor injection**:\n- ✅ Explicit dependencies (visible in signature)\n- ✅ Immutable (final fields)\n- ✅ Testable (easy to pass mocks)\n- ✅ Fails fast if dependency missing\n- ✅ No reflection needed\n\n**Field injection**:\n- ❌ Hidden dependencies\n- ❌ Mutable (non-final)\n- ❌ Requires reflection or Spring for testing\n- ❌ Can create partially initialized objects\n\n```java\n// ✅ Constructor injection\n@Service\npublic class OrderService {\n private final PaymentGateway paymentGateway;\n private final OrderRepository orderRepository;\n\n public OrderService(PaymentGateway paymentGateway,\n OrderRepository orderRepository) {\n this.paymentGateway = paymentGateway;\n this.orderRepository = orderRepository;\n }\n}\n```\n\n---\n\n#### Q24: How do you structure packages in a Spring Boot application?\n\n**Answer**:\n\n**Package by Feature** (recommended):\n```text\ncom.example.app/\n├── order/\n│ ├── OrderController.java\n│ ├── OrderService.java\n│ ├── OrderRepository.java\n│ └── Order.java\n├── customer/\n│ ├── CustomerController.java\n│ └── ...\n└── common/\n └── ...\n```\n\n**Benefits**:\n- Related code together\n- Easy to find everything about a feature\n- Clearer module boundaries\n- Easier to extract microservices later\n\n**Avoid Package by Layer**:\n```text\n❌ controllers/, services/, repositories/\n```\n\n---\n\n#### Q25: What are test slices and when to use them?\n\n**Answer**: Test slices load only part of Spring context for faster, focused tests.\n\n| Slice | Loads | Use For |\n|-------|-------|---------|\n| `@WebMvcTest` | Controllers, MVC config | Controller tests (no service/repo) |\n| `@DataJpaTest` | JPA, repositories | Repository tests (in-memory DB) |\n| `@JsonTest` | Jackson config | JSON serialization tests |\n| `@WebFluxTest` | WebFlux controllers | Reactive controller tests |\n\n```java\n@WebMvcTest(OrderController.class)\nclass OrderControllerTest {\n @Autowired MockMvc mockMvc;\n @MockBean OrderService orderService; // Mock the service\n\n @Test\n void createOrder_returns201() { ... }\n}\n```\n\n---\n\n## 🛠️ IDE Shortcuts\n\n### IntelliJ IDEA\n\n| Action | Windows/Linux | Mac |\n|--------|---------------|-----|\n| Extract Method | `Ctrl+Alt+M` | `Cmd+Option+M` |\n| Extract Variable | `Ctrl+Alt+V` | `Cmd+Option+V` |\n| Extract Field | `Ctrl+Alt+F` | `Cmd+Option+F` |\n| Extract Constant | `Ctrl+Alt+C` | `Cmd+Option+C` |\n| Extract Parameter | `Ctrl+Alt+P` | `Cmd+Option+P` |\n| Inline | `Ctrl+Alt+N` | `Cmd+Option+N` |\n| Rename | `Shift+F6` | `Shift+F6` |\n| Change Signature | `Ctrl+F6` | `Cmd+F6` |\n| Move | `F6` | `F6` |\n| Safe Delete | `Alt+Delete` | `Cmd+Delete` |\n| Extract Interface | `Ctrl+Shift+Alt+T` | `Ctrl+T` → menu |\n| Pull Up / Push Down | `Ctrl+Shift+Alt+T` | `Ctrl+T` → menu |\n\n### VS Code (with Java extensions)\n\n| Action | Windows/Linux | Mac |\n|--------|---------------|-----|\n| Extract Method | `Ctrl+Shift+R` | `Cmd+Shift+R` |\n| Extract Variable | Context menu | Context menu |\n| Rename | `F2` | `F2` |\n| Quick Fix | `Ctrl+.` | `Cmd+.` |\n\n---\n\n## 📚 Recommended Resources\n\n### Books\n\n| Book | Author | Focus |\n|------|--------|-------|\n| **Clean Code** | Robert C. Martin | Fundamentals of clean code |\n| **Refactoring** | Martin Fowler | Refactoring catalog |\n| **Working Effectively with Legacy Code** | Michael Feathers | Legacy modernization |\n| **Effective Java** | Joshua Bloch | Java best practices |\n| **Head First Design Patterns** | Freeman & Robson | Pattern introduction |\n| **Design Patterns** (GoF) | Gamma et al. | Classic pattern reference |\n| **Implementing DDD** | Vaughn Vernon | Domain-Driven Design |\n| **Clean Architecture** | Robert C. Martin | Architecture patterns |\n\n### Online Resources\n\n- **Refactoring Guru** - https://refactoring.guru (patterns, refactorings)\n- **SourceMaking** - https://sourcemaking.com (smells, patterns)\n- **Baeldung** - https://baeldung.com (Java/Spring tutorials)\n- **Martin Fowler's Blog** - https://martinfowler.com (architecture)\n\n### Tools\n\n| Tool | Purpose |\n|------|---------|\n| **SonarQube** | Code quality metrics |\n| **JaCoCo** | Code coverage |\n| **PIT** | Mutation testing |\n| **SpotBugs** | Bug detection |\n| **Checkstyle** | Code style |\n| **ArchUnit** | Architecture tests |\n| **IntelliJ Inspections** | Real-time analysis |\n\n---\n\n## 📝 Complete Series Index\n\n### Part I: Fundamentals\n- **Part 0**: How to Use This Series\n- **Part 1**: Clean Code Philosophy & Business Value\n- **Part 2**: SOLID - Single Responsibility & Open/Closed\n- **Part 3**: SOLID - Liskov, Interface Segregation, Dependency Inversion\n- **Part 4**: Code Smells - Complete Catalog\n- **Part 5**: Code Quality Metrics Framework\n\n### Part II: Refactoring Patterns\n- **Part 6**: Extract Patterns (Method, Class, Interface)\n- **Part 7**: Replace Conditional with Polymorphism\n- **Part 8**: Null Handling Patterns\n- **Part 9**: Builder & Factory Patterns\n- **Part 10**: Composition Over Inheritance\n- **Part 11**: Functional Clean Code (Java 8-21)\n- **Part 12**: Chain of Responsibility & Pipeline\n- **Part 13**: Template Method & Hooks\n\n### Part III: Error Handling\n- **Part 14**: Exception Hierarchy Design\n- **Part 15**: Result Pattern & Functional Error Handling\n- **Part 16**: Global Error Handling & RFC 7807\n\n### Part IV: Validation\n- **Part 17**: Bean Validation & Custom Constraints\n- **Part 18**: Fluent Validation & Input Sanitization\n\n### Part V: Legacy Modernization\n- **Part 19**: Understanding Legacy Code\n- **Part 20**: Characterization Testing\n- **Part 21**: Breaking Dependencies\n- **Part 22**: Strangler Fig & Incremental Refactoring\n\n### Part VI: Modern Java\n- **Part 23**: Records, Sealed Classes & Modern Java\n- **Part 24**: Clean Code in Spring Boot\n\n### Part VII: Reference\n- **Part 25**: Decision Guide & Cheatsheet (this article)\n\n---\n\n## 🐛 Debug This: The Wrong Pattern\n\nA team followed the decision tree for a switch statement but the refactoring made things worse. \"We used Strategy pattern like the guide says, but now we have 15 tiny classes and the code is harder to follow!\"\n\n```java\n// Original: 5-case switch in a utility method\npublic class TaxCalculator {\n\n public BigDecimal calculateTax(Order order) {\n return switch (order.getState()) {\n case \"CA\" -> order.getTotal().multiply(new BigDecimal(\"0.0725\"));\n case \"NY\" -> order.getTotal().multiply(new BigDecimal(\"0.08\"));\n case \"TX\" -> BigDecimal.ZERO; // No sales tax\n case \"WA\" -> order.getTotal().multiply(new BigDecimal(\"0.065\"));\n default -> order.getTotal().multiply(new BigDecimal(\"0.05\"));\n };\n }\n}\n\n// Their \"refactoring\": 6 classes for a simple calculation\npublic interface TaxStrategy {\n BigDecimal calculate(Order order);\n String getState();\n}\n\npublic class CaliforniaTaxStrategy implements TaxStrategy {\n public BigDecimal calculate(Order order) {\n return order.getTotal().multiply(new BigDecimal(\"0.0725\"));\n }\n public String getState() { return \"CA\"; }\n}\n\npublic class NewYorkTaxStrategy implements TaxStrategy { /* ... */ }\npublic class TexasTaxStrategy implements TaxStrategy { /* ... */ }\npublic class WashingtonTaxStrategy implements TaxStrategy { /* ... */ }\npublic class DefaultTaxStrategy implements TaxStrategy { /* ... */ }\n\n@Component\npublic class StrategyTaxCalculator {\n private final Map strategies;\n\n public StrategyTaxCalculator(List strategies) {\n this.strategies = strategies.stream()\n .collect(toMap(TaxStrategy::getState, identity()));\n }\n\n public BigDecimal calculateTax(Order order) {\n return strategies.getOrDefault(order.getState(), defaultStrategy)\n .calculate(order);\n }\n}\n```\n\n**They followed the decision tree, but the result is over-engineered. What went wrong?**\n\n---\n\n**✅ Solution:**\n\nThey followed the letter of the decision tree but missed the context questions:\n\n**Decision Tree Check:**\n```\nSwitch/if-else chain?\n├── How many cases? → 5 cases → Consider Strategy\n├── Will cases grow over time? → NO! Tax rates are configuration, not code\n├── Does each case have complex logic? → NO! Just a multiplication\n└── Is this behavior that needs to be injected/tested separately? → NO!\n```\n\n**Key questions they missed:**\n\n1. **\"Will cases grow over time?\"** - No. Tax rates are data, not behavior. If rates change, you update config, not add classes.\n\n2. **\"Is each case complex enough to warrant its own class?\"** - No. Each is a single line of multiplication.\n\n3. **\"YAGNI: Do you need this flexibility?\"** - No. They're solving a problem they don't have.\n\n**Better solution: Data-driven approach**\n\n```java\npublic class TaxCalculator {\n\n private final Map taxRates;\n private final BigDecimal defaultRate;\n\n public TaxCalculator(TaxRatesConfig config) {\n this.taxRates = config.rates();\n this.defaultRate = config.defaultRate();\n }\n\n public BigDecimal calculateTax(Order order) {\n BigDecimal rate = taxRates.getOrDefault(order.getState(), defaultRate);\n return order.getTotal().multiply(rate);\n }\n}\n\n// Configuration (YAML, database, etc.)\n@ConfigurationProperties(prefix = \"tax\")\npublic record TaxRatesConfig(\n Map rates,\n BigDecimal defaultRate\n) {}\n\n// tax:\n// default-rate: 0.05\n// rates:\n// CA: 0.0725\n// NY: 0.08\n// TX: 0\n// WA: 0.065\n```\n\n**When to use Strategy instead:**\n\n```java\n// Strategy IS appropriate when each case has DIFFERENT LOGIC:\npublic interface ShippingCalculator {\n BigDecimal calculate(Order order);\n}\n\npublic class StandardShipping implements ShippingCalculator {\n public BigDecimal calculate(Order order) {\n return order.getWeight().multiply(RATE_PER_KG)\n .add(HANDLING_FEE);\n }\n}\n\npublic class ExpressShipping implements ShippingCalculator {\n public BigDecimal calculate(Order order) {\n BigDecimal base = order.getWeight().multiply(EXPRESS_RATE);\n if (order.isFragile()) base = base.add(FRAGILE_FEE);\n if (order.needsSignature()) base = base.add(SIGNATURE_FEE);\n return base.add(PRIORITY_FEE);\n }\n}\n```\n\n**The lesson:** Decision trees give guidance, not commands. Always ask: \"Does this case have enough complexity and variability to justify the pattern?\" Simple data lookups don't need Strategy pattern.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Pattern Selection Practice\n⭐ Difficulty: Easy | ⏱️ Time: 10 minutes\n\n**Task:** For each code smell, use the decision trees to select the appropriate pattern.\n\n| # | Smell | Your Answer |\n|---|-------|-------------|\n| 1 | Method with 7 parameters | Pattern: ___ (Part: ___) |\n| 2 | Switch on payment type (8 cases, complex logic each) | Pattern: ___ (Part: ___) |\n| 3 | Repeated null checks for `order.getDiscount()` | Pattern: ___ (Part: ___) |\n| 4 | 400-line class handling orders, payments, emails | Pattern: ___ (Part: ___) |\n| 5 | 4-level deep inheritance hierarchy | Pattern: ___ (Part: ___) |\n\n**✅ Solution:**\n\n| # | Pattern | Part |\n|---|---------|------|\n| 1 | Parameter Object or Builder | Part 6, 9 |\n| 2 | Strategy Pattern | Part 7 |\n| 3 | Null Object Pattern | Part 8 |\n| 4 | Extract Class (split by responsibility) | Part 6 |\n| 5 | Composition over Inheritance | Part 10 |\n\n---\n\n### Exercise 2: Refactoring Recipe Application\n⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes\n\n**Task:** Apply the \"Replace Conditional with Strategy\" recipe to this code.\n\n```java\npublic BigDecimal calculateDiscount(Customer customer, BigDecimal orderTotal) {\n if (customer.getType().equals(\"BRONZE\")) {\n return orderTotal.multiply(new BigDecimal(\"0.02\"));\n } else if (customer.getType().equals(\"SILVER\")) {\n return orderTotal.multiply(new BigDecimal(\"0.05\"));\n } else if (customer.getType().equals(\"GOLD\")) {\n BigDecimal base = orderTotal.multiply(new BigDecimal(\"0.10\"));\n if (orderTotal.compareTo(new BigDecimal(\"1000\")) > 0) {\n base = base.add(new BigDecimal(\"25\"));\n }\n return base;\n } else if (customer.getType().equals(\"PLATINUM\")) {\n BigDecimal base = orderTotal.multiply(new BigDecimal(\"0.15\"));\n base = base.add(new BigDecimal(\"50\"));\n if (customer.getYearsActive() > 5) {\n base = base.add(orderTotal.multiply(new BigDecimal(\"0.02\")));\n }\n return base;\n }\n return BigDecimal.ZERO;\n}\n```\n\n**✅ Solution:**\n\n```java\npublic sealed interface DiscountStrategy\n permits BronzeDiscount, SilverDiscount, GoldDiscount, PlatinumDiscount, NoDiscount {\n\n BigDecimal calculate(Customer customer, BigDecimal orderTotal);\n}\n\npublic record BronzeDiscount() implements DiscountStrategy {\n public BigDecimal calculate(Customer customer, BigDecimal orderTotal) {\n return orderTotal.multiply(new BigDecimal(\"0.02\"));\n }\n}\n\npublic record SilverDiscount() implements DiscountStrategy {\n public BigDecimal calculate(Customer customer, BigDecimal orderTotal) {\n return orderTotal.multiply(new BigDecimal(\"0.05\"));\n }\n}\n\npublic record GoldDiscount() implements DiscountStrategy {\n public BigDecimal calculate(Customer customer, BigDecimal orderTotal) {\n BigDecimal base = orderTotal.multiply(new BigDecimal(\"0.10\"));\n if (orderTotal.compareTo(new BigDecimal(\"1000\")) > 0) {\n base = base.add(new BigDecimal(\"25\"));\n }\n return base;\n }\n}\n\npublic record PlatinumDiscount() implements DiscountStrategy {\n public BigDecimal calculate(Customer customer, BigDecimal orderTotal) {\n BigDecimal base = orderTotal.multiply(new BigDecimal(\"0.15\"));\n base = base.add(new BigDecimal(\"50\"));\n if (customer.getYearsActive() > 5) {\n base = base.add(orderTotal.multiply(new BigDecimal(\"0.02\")));\n }\n return base;\n }\n}\n\npublic record NoDiscount() implements DiscountStrategy {\n public BigDecimal calculate(Customer customer, BigDecimal orderTotal) {\n return BigDecimal.ZERO;\n }\n}\n\n// Usage\n@Service\npublic class DiscountService {\n private static final Map STRATEGIES = Map.of(\n \"BRONZE\", new BronzeDiscount(),\n \"SILVER\", new SilverDiscount(),\n \"GOLD\", new GoldDiscount(),\n \"PLATINUM\", new PlatinumDiscount()\n );\n\n public BigDecimal calculateDiscount(Customer customer, BigDecimal orderTotal) {\n return STRATEGIES.getOrDefault(customer.getType(), new NoDiscount())\n .calculate(customer, orderTotal);\n }\n}\n```\n\n---\n\n### Exercise 3: Interview Question Practice\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n**Task:** Answer these questions without looking at the answers. Then compare.\n\n1. **What is Single Responsibility Principle and how do you identify violations?**\n\nYour answer:\n```text\n_____________________________________________\n_____________________________________________\n_____________________________________________\n```\n\n2. **When would you use Strategy vs State pattern?**\n\nYour answer:\n```text\n_____________________________________________\n_____________________________________________\n_____________________________________________\n```\n\n3. **How do you safely refactor a 500-line method?**\n\nYour answer:\n```text\n_____________________________________________\n_____________________________________________\n_____________________________________________\n```\n\n**After writing your answers, compare with Q1, Q7, and Q6 in the Interview Questions Bank above.**\n\n---\n\n### Exercise 4: Code Smell Diagnosis\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 20 minutes\n\n**Task:** Identify ALL code smells in this class and map each to a refactoring.\n\n```java\npublic class OrderManager {\n private Connection dbConnection;\n @Autowired private EmailService emailService;\n\n public String processOrder(String customerId, String productId, int qty,\n String street, String city, String zip, String country,\n String cardNumber, String expiry, String cvv, boolean expressShipping) {\n\n // Validate customer\n if (customerId == null || customerId.isEmpty()) {\n return \"ERROR: No customer\";\n }\n Customer c = null;\n try {\n c = dbConnection.query(\"SELECT * FROM customers WHERE id = ?\", customerId);\n } catch (Exception e) {\n // Ignore\n }\n if (c == null) {\n return \"ERROR: Customer not found\";\n }\n\n // Check stock\n Product p = dbConnection.query(\"SELECT * FROM products WHERE id = ?\", productId);\n if (p == null || p.stock < qty) {\n return \"ERROR: Out of stock\";\n }\n\n // Calculate price\n double price = p.price * qty;\n if (expressShipping) {\n price += 25.0;\n }\n if (qty > 10) {\n price = price * 0.9; // 10% discount\n }\n\n // Process payment\n if (cardNumber != null && cardNumber.length() == 16) {\n // Call payment API\n String result = PaymentAPI.charge(cardNumber, expiry, cvv, price);\n if (!result.equals(\"OK\")) {\n return \"ERROR: Payment failed\";\n }\n } else {\n return \"ERROR: Invalid card\";\n }\n\n // Update stock\n dbConnection.execute(\"UPDATE products SET stock = stock - ? WHERE id = ?\", qty, productId);\n\n // Create order\n String orderId = UUID.randomUUID().toString();\n dbConnection.execute(\"INSERT INTO orders VALUES (?, ?, ?, ?, ?)\",\n orderId, customerId, productId, qty, price);\n\n // Send email\n emailService.send(c.email, \"Order Confirmed\", \"Your order \" + orderId + \" is confirmed\");\n\n return orderId;\n }\n}\n```\n\n**Your Analysis:**\n\n| Smell | Location | Refactoring | Part |\n|-------|----------|-------------|------|\n| 1. ___ | ___ | ___ | ___ |\n| 2. ___ | ___ | ___ | ___ |\n| 3. ___ | ___ | ___ | ___ |\n| ... | ... | ... | ... |\n\n**✅ Solution:**\n\n| Smell | Location | Refactoring | Part |\n|-------|----------|-------------|------|\n| Long Parameter List | processOrder (11 params) | Extract Parameter Objects (OrderRequest, Address, PaymentInfo) | Part 6 |\n| Long Method | processOrder (~60 lines) | Extract Method (validate, checkStock, calculatePrice, processPayment, createOrder) | Part 6 |\n| Field Injection | @Autowired emailService | Constructor Injection | Part 24 |\n| Raw SQL/Connection | dbConnection.query/execute | Repository Pattern | Part 24 |\n| Empty Catch Block | catch (Exception e) {} | Proper Exception Handling | Part 14 |\n| String Return for Errors | \"ERROR: ...\" | Result Pattern or Exceptions | Part 15 |\n| Primitive Obsession | double price, String cardNumber | Money, CreditCard value objects | Part 6 |\n| Feature Envy | PaymentAPI.charge in OrderManager | Extract PaymentService | Part 6 |\n| Multiple Responsibilities | Validation, Stock, Payment, Order, Email | Extract Services | Part 2, 6 |\n| Magic Numbers | 16, 25.0, 10, 0.9 | Named Constants | - |\n| Static Method Call | PaymentAPI.charge | Inject PaymentGateway | Part 21 |\n\n---\n\n### Exercise 5: Create Your Own Decision Tree\n⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 25 minutes\n\n**Task:** Create a decision tree for a pattern or problem you encounter frequently at work.\n\n**Template:**\n\n```text\n[Your Problem/Smell]?\n│\n├── [Condition 1]?\n│ ├── Yes → [Pattern A]\n│ └── No → [Continue to next condition]\n│\n├── [Condition 2]?\n│ ├── Yes → [Pattern B]\n│ │ Considerations: ___\n│ └── No → [Continue]\n│\n├── [Condition 3]?\n│ └── [Decision based on measurement]\n│\n└── Default → [Simplest solution]\n```\n\n**Your Decision Tree:**\n\n```text\n_____________________________________________\n│\n├── _____________________________________________\n│ ├── _____________________________________________\n│ └── _____________________________________________\n│\n├── _____________________________________________\n│\n└── _____________________________________________\n```\n\n**Test your tree:** Apply it to 3 real examples from your codebase. Does it give the right guidance?\n\n---\n\n## 📅 Review Schedule for This Article\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review the Pattern Decision Trees (all 7) | 10 min |\n| Day 3 | Redo Exercise 1 (Pattern Selection Practice) | 10 min |\n| Day 7 | Practice answering 5 interview questions without looking | 15 min |\n| Day 14 | Redo Debug This (The Wrong Pattern) | 10 min |\n| Day 30 | Apply a decision tree to a real refactoring in your project | 20 min |\n\n---\n\n## 🏁 Conclusion\n\nYou now have a complete reference for making clean code decisions. The key to using this guide effectively:\n\n1. **Bookmark the decision trees** - use them when facing a refactoring choice\n2. **Memorize key metrics** - lines > 20, parameters > 4, complexity > 10\n3. **Practice the recipes** - apply Extract Method, Strategy Pattern regularly\n4. **Review before interviews** - the 50 questions cover senior-level topics\n5. **Apply incrementally** - one pattern at a time, not revolutionary rewrites\n\n### Final Checklist\n\nBefore any refactoring:\n- [ ] Tests exist (or write characterization tests)\n- [ ] Identified the code smell\n- [ ] Measured the problem (metrics)\n- [ ] Selected pattern using decision tree\n- [ ] Small, reversible steps planned\n\nDuring refactoring:\n- [ ] Preserve behavior (run tests after each change)\n- [ ] Commit frequently\n- [ ] Use IDE refactoring tools\n- [ ] Review for new smells introduced\n\nAfter refactoring:\n- [ ] All tests pass\n- [ ] Metrics improved\n- [ ] Code review with team\n- [ ] Document decision if significant\n\n---\n\n**Congratulations on completing the Advanced Clean Code Patterns series!**\n\nRemember: Clean code is not about perfection. It's about continuous improvement, pragmatic decisions, and code that your future self (and teammates) will thank you for.\n\nKeep refactoring. Keep learning. Keep shipping.\n\n---\n\n*This is the final article in the Advanced Clean Code Patterns series.*\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:24.971773Z","createdAt","2026-06-10T07:19:24.972909Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",34,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Java","readingTime","seriesId","seriesOrder",25,"author",{"_31":55,"_98":57,"_99":100,"_101":102,"_103":-5,"_104":-5,"_105":-5,"_106":-5,"_107":-5},"category",{"_31":94,"_72":59,"_35":95,"_75":96,"_97":-5},"tags",[78,79,80,81],"series",{"_31":16,"_72":73,"_35":74,"_75":76,"_77":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":91,"_72":92,"_35":93},{"_31":88,"_72":89,"_35":90},{"_31":85,"_72":86,"_35":87},{"_31":82,"_72":83,"_35":84},114,"Quick Reference","quick-reference",112,"Pattern Selection","pattern-selection",111,"Decision Guide","decision-guide",113,"Cheatsheet","cheatsheet",5,"java","Category for Java","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]