{"title":"Encapsulate what Varies","description":null,"content":"Have you ever had to modify one part of your system, only to touch five other files?\n\nOr noticed that every time a business rule changes, you need to dig through unrelated code just to find where that logic lives?\n\nIf yes, then your code is likely violating one of the foundational design principles behind flexible and maintainable systems: **Encapsulate What Varies**.\n\nIn this chapter, we’ll break down what this principle means, why it matters, and how you can apply it to isolate change and protect your code from ripple effects.\n\n---\n\n# What Does “Encapsulate What Varies” Mean?\n\n> **Identify the parts of your code that are likely to change and separate them from the parts that stay the same.**\n\nThis principle comes from the **Strategy Pattern** and other object-oriented design ideas that encourage you to wrap volatile behavior in a separate class or module.\n\nInstead of letting changes leak into your stable code, you **encapsulate the variation behind an interface, abstract class, or delegation**.\n\nIn simpler terms:\n\n- If something keeps changing, put it in a box.\n- If something stays the same, leave it alone.\n\n---\n\n# A Real-World Problem\n\nLet’s say you are building a payment system that currently supports credit card payments.\n\nHere’s your first version:\n\n\n```java\npublic class PaymentService {\n public void pay(double amount) {\n System.out.println(\"Processing credit card payment of $\" + amount);\n // logic for credit card payment\n }\n}\n```\n\n\nThen one day, the business wants to support UPI.\n\nThen PayPal. Then Apple Pay.\n\nSo you keep adding `if-else` statements:\n\n\n```java\npublic void pay(String method, double amount) {\n if (\"credit\".equals(method)) {\n // credit card logic\n } else if (\"upi\".equals(method)) {\n // upi logic\n } else if (\"paypal\".equals(method)) {\n // paypal logic\n }\n}\n```\n\n\nThis approach becomes messy fast:\n\n- Each new method requires modifying the `pay()` function\n- Payment logic gets tangled together\n- Testing becomes harder\n- The code violates **Open/Closed Principle** and **Single Responsibility Principle**\n\n---\n\n# Applying “Encapsulate What Varies”\n\nThe part that **varies** here is the **payment strategy**.\n\nLet’s encapsulate it.\n\n#### Step 1: Define an Interface\n\n\n```java\npublic interface PaymentStrategy {\n void pay(double amount);\n}\n```\n\n\n#### Step 2: Implement Different Strategies\n\n\n```java\npublic class CreditCardPayment implements PaymentStrategy {\n public void pay(double amount) {\n System.out.println(\"Paid $\" + amount + \" using Credit Card\");\n }\n}\n\npublic class UpiPayment implements PaymentStrategy {\n public void pay(double amount) {\n System.out.println(\"Paid $\" + amount + \" using UPI\");\n }\n}\n\npublic class PaypalPayment implements PaymentStrategy {\n public void pay(double amount) {\n System.out.println(\"Paid $\" + amount + \" using PayPal\");\n }\n}\n```\n\n\n### Step 3: Delegate to the Strategy\n\n\n```java\npublic class PaymentService {\n private final PaymentStrategy strategy;\n\n public PaymentService(PaymentStrategy strategy) {\n this.strategy = strategy;\n }\n\n public void pay(double amount) {\n strategy.pay(amount);\n }\n}\n```\n\n\nNow, if a new payment method is introduced, no existing code needs to be modified. You simply implement a new strategy.\n\n---\n\n# Benefits of Encapsulating What Varies\n\n- **Isolates change: **Keeps volatile logic away from stable parts of your system\n- **Improves readability: **Each variant is cleanly separated from the others\n- **Follows Open/Closed Principle: **You can extend behavior without modifying existing code\n- **Increases reusability: **Strategies can be reused in other parts of the application\n- **Simplifies testing: **Each strategy can be tested independently\n\n---\n\n# When to Apply This Principle\n\nApply “Encapsulate What Varies” when:\n\n- You notice logic that changes frequently\n- You have conditional branches that check for modes, types, or behaviors\n- New features often require changes to the same part of the codebase\n- You want to allow plug-and-play behaviors\n\n---\n\n# When to Delay It\n\nWhile encapsulating variation is powerful, don’t apply it prematurely.\n\nIf you only have one behavior and no foreseeable need to change it, abstraction may introduce unnecessary complexity.\n\nFollow the **Rule of Three**:\n\n> The third time you need to change something, consider extracting it.\n\n---\n\n# Final Thought\n\nSoftware is always changing. The key is to change it **without breaking everything else**.\n\nEncapsulating variation allows you to build flexible systems where each piece can evolve independently.\n\nSo the next time you write a function with too many `if` statements or see logic changing in unpredictable ways, ask yourself:\n\n**“What’s the part that keeps changing?”** **“Can I put that in its own class or module?”**\n\nBecause once you identify what varies, you can design for change—without fear of chaos.","pageType":"lld-interviews"}

Encapsulate what Varies

Ashish Pratap Singh

Get Premium