[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":91,"_72":92,"_35":93},"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",8,"title","Replacing Conditionals with Polymorphism","slug","clean-code-part-7-replace-conditionals","excerpt","Replace complex switch statements and if-else chains with polymorphic designs (Strategy, State, Pattern Matching) that are easier to extend and maintain.","# Advanced Clean Code Patterns Part 7: Replace Conditional with Polymorphism\n\nComplex conditional logic is one of the most common sources of bugs and maintenance headaches. This article covers techniques to replace switch statements and if-else chains with polymorphic designs that are easier to extend, test, and maintain.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Patterns Covered | Strategy, State, Pattern Matching |\n| Primary Benefit | Open for extension, closed for modification |\n| Best For | Type-based switches, algorithm selection |\n| Java Version | 8+ (lambdas), 17+ (pattern matching) |\n| Risk Level | Medium (requires careful testing) |\n\n---\n\n## 🎯 What You'll Learn\n\n- **Strategy Pattern** for algorithm selection\n- **State Pattern** for state-dependent behavior\n- **Pattern Matching** (Java 17+) for concise conditionals\n- **Enum-based dispatch** for simple cases\n- **Rule Engine Pattern** for complex business rules\n- **When to keep conditionals** (not everything needs polymorphism)\n\n---\n\n## 🔥 Production Story: The Payment Switch That Grew Out of Control\n\nA payment service started with a simple switch:\n\n```java\n// Year 1: Simple and manageable\npublic PaymentResult process(Payment payment) {\n switch (payment.getType()) {\n case CREDIT_CARD: return processCreditCard(payment);\n case PAYPAL: return processPayPal(payment);\n default: throw new UnsupportedPaymentException();\n }\n}\n```\n\nThree years later:\n\n```java\n// Year 3: Nightmare to maintain\npublic PaymentResult process(Payment payment) {\n switch (payment.getType()) {\n case CREDIT_CARD: return processCreditCard(payment);\n case PAYPAL: return processPayPal(payment);\n case APPLE_PAY: return processApplePay(payment);\n case GOOGLE_PAY: return processGooglePay(payment);\n case BANK_TRANSFER: return processBankTransfer(payment);\n case CRYPTO_BITCOIN: return processBitcoin(payment);\n case CRYPTO_ETHEREUM: return processEthereum(payment);\n case BUY_NOW_PAY_LATER: return processBNPL(payment);\n case GIFT_CARD: return processGiftCard(payment);\n case STORE_CREDIT: return processStoreCredit(payment);\n // ... 15 more cases, 2000 lines total\n }\n}\n```\n\n**The problems:**\n- Adding payment type required changes in 12 switch statements across codebase\n- Each payment type's code mixed together (no isolation)\n- Testing required understanding entire switch\n- Different teams couldn't work independently\n\n**The fix:** Strategy Pattern\n\n```java\n// Each payment type is independent\npublic interface PaymentProcessor {\n PaymentType getType();\n PaymentResult process(Payment payment);\n}\n\n@Component\npublic class CreditCardProcessor implements PaymentProcessor {\n public PaymentType getType() { return PaymentType.CREDIT_CARD; }\n public PaymentResult process(Payment payment) { /* isolated logic */ }\n}\n\n// Adding new payment = add new class, no modifications needed\n```\n\n---\n\n## 🧠 Mental Model: Conditional to Polymorphism\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ CONDITIONAL VS POLYMORPHISM │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ CONDITIONAL (Procedural) │\n│ ┌────────────────────────────────────────────────────────────┐ │\n│ │ if (type == A) { doA(); } │ │\n│ │ else if (type == B) { doB(); } │ │\n│ │ else if (type == C) { doC(); } │ │\n│ │ │ │\n│ │ Problem: Adding D requires modifying this code │ │\n│ └────────────────────────────────────────────────────────────┘ │\n│ ↓ │\n│ POLYMORPHISM (Object-Oriented) │\n│ ┌────────────────────────────────────────────────────────────┐ │\n│ │ interface Handler { void handle(); } │ │\n│ │ │ │\n│ │ class AHandler implements Handler { void handle(){doA();}}│ │\n│ │ class BHandler implements Handler { void handle(){doB();}}│ │\n│ │ class CHandler implements Handler { void handle(){doC();}}│ │\n│ │ │ │\n│ │ Benefit: Adding D = new class, no modification needed │ │\n│ └────────────────────────────────────────────────────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 🔬 Deep Dive\n\n### Pattern 1: Strategy Pattern\n\n**Use when:** Different algorithms can be selected at runtime.\n\n```java\n// ✅ Strategy Pattern Implementation\n\n// 1. Define the strategy interface\npublic interface ShippingCalculator {\n BigDecimal calculate(Order order);\n ShippingMethod getMethod();\n}\n\n// 2. Implement strategies\n@Component\npublic class StandardShipping implements ShippingCalculator {\n @Override\n public ShippingMethod getMethod() {\n return ShippingMethod.STANDARD;\n }\n\n @Override\n public BigDecimal calculate(Order order) {\n return order.getWeight()\n .multiply(new BigDecimal(\"0.50\"))\n .add(new BigDecimal(\"5.00\"));\n }\n}\n\n@Component\npublic class ExpressShipping implements ShippingCalculator {\n @Override\n public ShippingMethod getMethod() {\n return ShippingMethod.EXPRESS;\n }\n\n @Override\n public BigDecimal calculate(Order order) {\n BigDecimal base = order.getWeight()\n .multiply(new BigDecimal(\"1.50\"));\n return base.add(new BigDecimal(\"15.00\"));\n }\n}\n\n@Component\npublic class OvernightShipping implements ShippingCalculator {\n @Override\n public ShippingMethod getMethod() {\n return ShippingMethod.OVERNIGHT;\n }\n\n @Override\n public BigDecimal calculate(Order order) {\n return order.getWeight()\n .multiply(new BigDecimal(\"3.00\"))\n .add(new BigDecimal(\"30.00\"));\n }\n}\n\n// 3. Strategy registry with Spring auto-discovery\n@Service\npublic class ShippingService {\n private final Map calculators;\n\n public ShippingService(List calculatorList) {\n this.calculators = calculatorList.stream()\n .collect(Collectors.toMap(\n ShippingCalculator::getMethod,\n Function.identity()\n ));\n }\n\n public BigDecimal calculateShipping(Order order) {\n ShippingCalculator calculator = calculators.get(order.getShippingMethod());\n if (calculator == null) {\n throw new UnsupportedShippingMethodException(order.getShippingMethod());\n }\n return calculator.calculate(order);\n }\n}\n```\n\n**Adding new shipping method:**\n1. Create new `@Component` class implementing `ShippingCalculator`\n2. That's it! Spring auto-discovers and registers it.\n\n---\n\n### Pattern 2: State Pattern\n\n**Use when:** Object behavior depends on its current state.\n\n```java\n// ✅ State Pattern for Order Processing\n\n// 1. Define state interface\npublic interface OrderState {\n void next(Order order);\n void previous(Order order);\n void cancel(Order order);\n String getStatus();\n}\n\n// 2. Implement states\npublic class PendingState implements OrderState {\n @Override\n public void next(Order order) {\n order.setState(new PaidState());\n }\n\n @Override\n public void previous(Order order) {\n throw new IllegalStateException(\"Cannot go back from PENDING\");\n }\n\n @Override\n public void cancel(Order order) {\n order.setState(new CancelledState());\n }\n\n @Override\n public String getStatus() { return \"PENDING\"; }\n}\n\npublic class PaidState implements OrderState {\n @Override\n public void next(Order order) {\n order.setState(new ShippedState());\n }\n\n @Override\n public void previous(Order order) {\n // Refund logic\n order.setState(new PendingState());\n }\n\n @Override\n public void cancel(Order order) {\n // Refund required\n refundPayment(order);\n order.setState(new CancelledState());\n }\n\n @Override\n public String getStatus() { return \"PAID\"; }\n}\n\npublic class ShippedState implements OrderState {\n @Override\n public void next(Order order) {\n order.setState(new DeliveredState());\n }\n\n @Override\n public void previous(Order order) {\n throw new IllegalStateException(\"Cannot unship an order\");\n }\n\n @Override\n public void cancel(Order order) {\n throw new IllegalStateException(\"Cannot cancel shipped order\");\n }\n\n @Override\n public String getStatus() { return \"SHIPPED\"; }\n}\n\n// 3. Order delegates to current state\npublic class Order {\n private OrderState state;\n\n public Order() {\n this.state = new PendingState();\n }\n\n public void setState(OrderState state) {\n this.state = state;\n }\n\n public void proceed() {\n state.next(this);\n }\n\n public void rollback() {\n state.previous(this);\n }\n\n public void cancel() {\n state.cancel(this);\n }\n\n public String getStatus() {\n return state.getStatus();\n }\n}\n```\n\n---\n\n### Pattern 3: Pattern Matching (Java 17+)\n\n**Use when:** Need concise conditionals, fixed set of types.\n\n```java\n// ✅ Java 17+ Pattern Matching with Sealed Classes\n\npublic sealed interface Notification\n permits EmailNotification, SmsNotification, PushNotification {}\n\npublic record EmailNotification(String to, String subject, String body)\n implements Notification {}\n\npublic record SmsNotification(String phoneNumber, String message)\n implements Notification {}\n\npublic record PushNotification(String deviceId, String title, String message)\n implements Notification {}\n\n// Exhaustive pattern matching - compiler ensures all cases handled\npublic class NotificationSender {\n public void send(Notification notification) {\n switch (notification) {\n case EmailNotification e -> sendEmail(e.to(), e.subject(), e.body());\n case SmsNotification s -> sendSms(s.phoneNumber(), s.message());\n case PushNotification p -> sendPush(p.deviceId(), p.title(), p.message());\n // No default needed - compiler verified exhaustive!\n }\n }\n\n // Pattern matching with guards\n public String describe(Notification notification) {\n return switch (notification) {\n case EmailNotification e when e.body().length() > 1000 ->\n \"Long email to \" + e.to();\n case EmailNotification e ->\n \"Email to \" + e.to();\n case SmsNotification s ->\n \"SMS to \" + s.phoneNumber();\n case PushNotification p ->\n \"Push to device \" + p.deviceId();\n };\n }\n}\n```\n\n---\n\n### Pattern 4: Enum with Behavior\n\n**Use when:** Simple cases, limited number of fixed types.\n\n```java\n// ✅ Enum with embedded behavior\npublic enum DiscountType {\n PERCENTAGE {\n @Override\n public BigDecimal apply(BigDecimal price, BigDecimal value) {\n return price.multiply(BigDecimal.ONE.subtract(value));\n }\n },\n FIXED_AMOUNT {\n @Override\n public BigDecimal apply(BigDecimal price, BigDecimal value) {\n return price.subtract(value).max(BigDecimal.ZERO);\n }\n },\n BUY_X_GET_Y {\n @Override\n public BigDecimal apply(BigDecimal price, BigDecimal value) {\n // value = Y (free items per X purchased)\n // Implementation depends on quantity\n return price;\n }\n };\n\n public abstract BigDecimal apply(BigDecimal price, BigDecimal value);\n}\n\n// Usage - no switch needed\npublic class DiscountService {\n public BigDecimal applyDiscount(BigDecimal price, Discount discount) {\n return discount.getType().apply(price, discount.getValue());\n }\n}\n```\n\n---\n\n### Pattern 5: Rule Engine for Complex Conditions\n\n**Use when:** Many complex, changeable business rules.\n\n```java\n// ✅ Simple Rule Engine\n\npublic interface PricingRule {\n boolean applies(Order order);\n BigDecimal calculateDiscount(Order order);\n int getPriority(); // Lower = higher priority\n}\n\n@Component\npublic class VipDiscountRule implements PricingRule {\n @Override\n public boolean applies(Order order) {\n return order.getCustomer().isVip();\n }\n\n @Override\n public BigDecimal calculateDiscount(Order order) {\n return order.getSubtotal().multiply(new BigDecimal(\"0.10\"));\n }\n\n @Override\n public int getPriority() { return 10; }\n}\n\n@Component\npublic class BulkOrderRule implements PricingRule {\n @Override\n public boolean applies(Order order) {\n return order.getItems().size() > 10;\n }\n\n @Override\n public BigDecimal calculateDiscount(Order order) {\n return order.getSubtotal().multiply(new BigDecimal(\"0.05\"));\n }\n\n @Override\n public int getPriority() { return 20; }\n}\n\n@Service\npublic class PricingEngine {\n private final List rules;\n\n public PricingEngine(List rules) {\n this.rules = rules.stream()\n .sorted(Comparator.comparing(PricingRule::getPriority))\n .toList();\n }\n\n public BigDecimal calculateTotalDiscount(Order order) {\n return rules.stream()\n .filter(rule -> rule.applies(order))\n .map(rule -> rule.calculateDiscount(order))\n .reduce(BigDecimal.ZERO, BigDecimal::add);\n }\n}\n```\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: Over-Engineering Simple Cases\n\n```java\n// ❌ Over-engineered: 3 classes for 2 cases\npublic interface BooleanFormatter { String format(boolean value); }\npublic class TrueFormatter implements BooleanFormatter { ... }\npublic class FalseFormatter implements BooleanFormatter { ... }\n\n// ✅ Simple: Just use a conditional\npublic String formatBoolean(boolean value) {\n return value ? \"Yes\" : \"No\";\n}\n```\n\n### Mistake 2: Forgetting Null/Default Cases\n\n```java\n// ❌ Missing null check\npublic BigDecimal calculate(Order order) {\n return strategies.get(order.getType()).calculate(order);\n // NPE if type not in map!\n}\n\n// ✅ Handle missing cases\npublic BigDecimal calculate(Order order) {\n ShippingStrategy strategy = strategies.get(order.getType());\n if (strategy == null) {\n throw new UnsupportedTypeException(order.getType());\n }\n return strategy.calculate(order);\n}\n```\n\n---\n\n## 🐛 Debug This: The Missing Discount Type\n\nA developer reports: \"We added a new discount type LOYALTY_POINTS but customers aren't getting their discounts. The switch compiles fine!\"\n\n```java\npublic enum DiscountType {\n PERCENTAGE,\n FIXED_AMOUNT,\n BUY_ONE_GET_ONE,\n LOYALTY_POINTS // New type added\n}\n\npublic class DiscountCalculator {\n public BigDecimal calculate(DiscountType type, BigDecimal amount, int points) {\n switch (type) {\n case PERCENTAGE:\n return amount.multiply(new BigDecimal(\"0.1\"));\n case FIXED_AMOUNT:\n return new BigDecimal(\"10.00\");\n case BUY_ONE_GET_ONE:\n return amount.divide(new BigDecimal(\"2\"));\n // Forgot to add LOYALTY_POINTS case!\n default:\n return BigDecimal.ZERO;\n }\n }\n}\n\n// Usage\nDiscountType type = DiscountType.LOYALTY_POINTS;\nBigDecimal discount = calculator.calculate(type, order.getTotal(), customer.getPoints());\n// discount is 0! Customer gets no discount!\n```\n\n**Why doesn't the compiler catch this bug? How would you prevent it?**\n\n---\n\n**✅ Solution:**\n\nThe bug is the **silent default case** - when a new enum value is added, it falls through to `default` instead of causing a compile error.\n\n**Problems:**\n1. `default` case swallows new enum values silently\n2. No compiler warning for unhandled enum cases\n3. Business logic silently fails\n\n**Prevention strategies:**\n\n```java\n// Option 1: Throw in default (runtime protection)\ndefault:\n throw new UnsupportedOperationException(\"Unknown discount type: \" + type);\n\n// Option 2: Use exhaustive switch (Java 17+ pattern matching)\nreturn switch (type) {\n case PERCENTAGE -> amount.multiply(new BigDecimal(\"0.1\"));\n case FIXED_AMOUNT -> new BigDecimal(\"10.00\");\n case BUY_ONE_GET_ONE -> amount.divide(new BigDecimal(\"2\"));\n case LOYALTY_POINTS -> calculateFromPoints(points);\n // No default - compiler error if new enum added!\n};\n\n// Option 3: Strategy pattern (compile-time safety)\nMap strategies = Map.of(\n PERCENTAGE, new PercentageDiscount(),\n FIXED_AMOUNT, new FixedDiscount(),\n // Missing entry = explicit failure at startup\n);\n```\n\n**The lesson:** Avoid `default` cases in enum switches when possible. Use exhaustive switches (Java 17+) or Strategy pattern to ensure all cases are handled.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Convert Switch to Strategy\n⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes\n\n**Task:** Refactor this switch to Strategy pattern.\n\n```java\npublic BigDecimal calculateTax(Order order) {\n switch (order.getCountry()) {\n case \"US\": return order.getTotal().multiply(new BigDecimal(\"0.08\"));\n case \"UK\": return order.getTotal().multiply(new BigDecimal(\"0.20\"));\n case \"DE\": return order.getTotal().multiply(new BigDecimal(\"0.19\"));\n case \"FR\": return order.getTotal().multiply(new BigDecimal(\"0.20\"));\n default: return BigDecimal.ZERO;\n }\n}\n```\n\n**✅ Solution:**\n\n```java\npublic interface TaxStrategy {\n BigDecimal calculateTax(BigDecimal amount);\n String getCountryCode();\n}\n\n@Component\npublic class UsTaxStrategy implements TaxStrategy {\n public String getCountryCode() { return \"US\"; }\n public BigDecimal calculateTax(BigDecimal amount) {\n return amount.multiply(new BigDecimal(\"0.08\"));\n }\n}\n\n@Service\npublic class TaxCalculator {\n private final Map strategies;\n\n public TaxCalculator(List strategies) {\n this.strategies = strategies.stream()\n .collect(Collectors.toMap(TaxStrategy::getCountryCode, Function.identity()));\n }\n\n public BigDecimal calculateTax(Order order) {\n TaxStrategy strategy = strategies.get(order.getCountry());\n return strategy != null ? strategy.calculateTax(order.getTotal()) : BigDecimal.ZERO;\n }\n}\n```\n\n---\n\n### Exercise 2: Apply State Pattern\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n**Task:** Replace these conditionals with State pattern.\n\n```java\npublic class Order {\n private String status;\n\n public void next() {\n if (status.equals(\"NEW\")) {\n status = \"PAID\";\n } else if (status.equals(\"PAID\")) {\n status = \"SHIPPED\";\n } else if (status.equals(\"SHIPPED\")) {\n status = \"DELIVERED\";\n }\n }\n\n public void cancel() {\n if (status.equals(\"NEW\") || status.equals(\"PAID\")) {\n status = \"CANCELLED\";\n } else {\n throw new IllegalStateException(\"Cannot cancel order in \" + status);\n }\n }\n}\n```\n\n**✅ Solution:**\n\n```java\npublic interface OrderState {\n OrderState next();\n OrderState cancel();\n}\n\npublic class NewState implements OrderState {\n public OrderState next() { return new PaidState(); }\n public OrderState cancel() { return new CancelledState(); }\n}\n\npublic class PaidState implements OrderState {\n public OrderState next() { return new ShippedState(); }\n public OrderState cancel() { return new CancelledState(); }\n}\n\npublic class ShippedState implements OrderState {\n public OrderState next() { return new DeliveredState(); }\n public OrderState cancel() { throw new IllegalStateException(\"Cannot cancel shipped order\"); }\n}\n\npublic class Order {\n private OrderState state = new NewState();\n public void next() { state = state.next(); }\n public void cancel() { state = state.cancel(); }\n}\n```\n\n---\n\n### Exercise 3: Use Enum with Behavior\n⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes\n\n**Task:** Add behavior to this enum to eliminate the switch.\n\n```java\npublic enum Shape {\n CIRCLE, SQUARE, TRIANGLE\n}\n\npublic double calculateArea(Shape shape, double size) {\n switch (shape) {\n case CIRCLE: return Math.PI * size * size;\n case SQUARE: return size * size;\n case TRIANGLE: return (Math.sqrt(3) / 4) * size * size;\n default: throw new IllegalArgumentException();\n }\n}\n```\n\n**✅ Solution:**\n\n```java\npublic enum Shape {\n CIRCLE {\n public double calculateArea(double size) {\n return Math.PI * size * size;\n }\n },\n SQUARE {\n public double calculateArea(double size) {\n return size * size;\n }\n },\n TRIANGLE {\n public double calculateArea(double size) {\n return (Math.sqrt(3) / 4) * size * size;\n }\n };\n\n public abstract double calculateArea(double size);\n}\n\n// Usage: shape.calculateArea(5.0) - no switch needed!\n```\n\n---\n\n### Exercise 4: Pattern Matching (Java 17+)\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 20 minutes\n\n**Task:** Refactor to use pattern matching.\n\n```java\npublic String format(Object value) {\n if (value instanceof String) {\n return \"\\\"\" + ((String) value) + \"\\\"\";\n } else if (value instanceof Integer) {\n return String.valueOf((Integer) value);\n } else if (value instanceof List) {\n return \"[\" + ((List) value).size() + \" items]\";\n } else if (value instanceof Map) {\n return \"{\" + ((Map) value).size() + \" entries}\";\n } else {\n return String.valueOf(value);\n }\n}\n```\n\n**✅ Solution:**\n\n```java\npublic String format(Object value) {\n return switch (value) {\n case String s -> \"\\\"\" + s + \"\\\"\";\n case Integer i -> String.valueOf(i);\n case List list -> \"[\" + list.size() + \" items]\";\n case Map map -> \"{\" + map.size() + \" entries}\";\n case null -> \"null\";\n default -> String.valueOf(value);\n };\n}\n```\n\n---\n\n### Exercise 5: Rule Engine Pattern\n⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 25 minutes\n\n**Task:** Replace nested conditionals with Rule Engine.\n\n```java\npublic BigDecimal calculateDiscount(Customer customer, Order order) {\n if (customer.isVip()) {\n if (order.getTotal().compareTo(new BigDecimal(\"1000\")) > 0) {\n return new BigDecimal(\"0.20\"); // VIP + high value\n } else {\n return new BigDecimal(\"0.10\"); // VIP standard\n }\n } else if (customer.getOrderCount() > 10) {\n return new BigDecimal(\"0.05\"); // Loyal customer\n } else if (order.isHolidaySale()) {\n return new BigDecimal(\"0.15\"); // Holiday sale\n }\n return BigDecimal.ZERO;\n}\n```\n\n**✅ Solution:**\n\n```java\npublic interface DiscountRule {\n boolean applies(Customer customer, Order order);\n BigDecimal getDiscount();\n int getPriority(); // Higher = checked first\n}\n\npublic class VipHighValueRule implements DiscountRule {\n public boolean applies(Customer c, Order o) {\n return c.isVip() && o.getTotal().compareTo(new BigDecimal(\"1000\")) > 0;\n }\n public BigDecimal getDiscount() { return new BigDecimal(\"0.20\"); }\n public int getPriority() { return 100; }\n}\n\npublic class VipStandardRule implements DiscountRule {\n public boolean applies(Customer c, Order o) { return c.isVip(); }\n public BigDecimal getDiscount() { return new BigDecimal(\"0.10\"); }\n public int getPriority() { return 90; }\n}\n\n@Service\npublic class DiscountEngine {\n private final List rules;\n\n public DiscountEngine(List rules) {\n this.rules = rules.stream()\n .sorted(Comparator.comparing(DiscountRule::getPriority).reversed())\n .toList();\n }\n\n public BigDecimal calculateDiscount(Customer customer, Order order) {\n return rules.stream()\n .filter(rule -> rule.applies(customer, order))\n .map(DiscountRule::getDiscount)\n .findFirst()\n .orElse(BigDecimal.ZERO);\n }\n}\n```\n\n---\n\n## 🎤 Senior-Level Interview Questions\n\n### Q1: When should you keep a switch instead of using polymorphism?\n\n**Answer:**\n- Few cases (2-3) that won't grow\n- Simple, one-liner cases\n- Performance-critical code\n- Pattern matching is cleaner (Java 17+)\n- Cases aren't really \"types\" but just values\n\n### Q2: Strategy vs State - what's the difference?\n\n**Answer:**\n- **Strategy:** Client chooses which algorithm to use\n- **State:** Object changes its own behavior based on internal state\n- Strategy = same object, different algorithms\n- State = same algorithm, different behavior per state\n\n---\n\n## 📝 Summary\n\n| Approach | Use When |\n|----------|----------|\n| Strategy | Algorithm selection, extensible |\n| State | Behavior depends on state |\n| Pattern Matching | Fixed types, Java 17+ |\n| Enum with behavior | Simple, fixed cases |\n| Rule Engine | Complex business rules |\n| Keep Switch | 2-3 simple cases |\n\n---\n\n## 📅 Review Schedule for This Article\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review Strategy vs State vs Pattern Matching table | 5 min |\n| Day 3 | Redo Exercise 1 (Convert Switch to Strategy) | 15 min |\n| Day 7 | Answer interview questions without looking | 10 min |\n| Day 14 | Redo Debug This (Missing Discount Type) | 10 min |\n| Day 30 | Find one switch in your project that could use Strategy | 15 min |\n\n---\n\n*Next in series: [Part 8: Null Handling Patterns]*\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:24.717126Z","createdAt","2026-06-10T07:19:24.717861Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",12,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Java","readingTime","seriesId","seriesOrder",7,"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},43,"Strategy Pattern","strategy-pattern",31,"Refactoring","refactoring",42,"Polymorphism","polymorphism",41,"Conditionals","conditionals",5,"java","Category for Java","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]