Have you ever had to modify one part of your system, only to touch five other files?

Or noticed that every time a business rule changes, you need to dig through unrelated code just to find where that logic lives?

If yes, then your code is likely violating one of the foundational design principles behind flexible and maintainable systems: Encapsulate What Varies.

In 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.

What Does “Encapsulate What Varies” Mean?

Identify the parts of your code that are likely to change and separate them from the parts that stay the same.

This 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.

Instead of letting changes leak into your stable code, you encapsulate the variation behind an interface, abstract class, or delegation.

In simpler terms:

If something keeps changing, put it in a box.
If something stays the same, leave it alone.

A Real-World Problem

Let’s say you are building a payment system that currently supports credit card payments.

Here’s your first version:

Then one day, the business wants to support UPI.

Then PayPal.Then Apple Pay.

So you keep adding if-else statements:

This approach becomes messy fast:

Each new method requires modifying the pay() function
Payment logic gets tangled together
Testing becomes harder
The code violates Open/Closed Principle and Single Responsibility Principle

Applying “Encapsulate What Varies”

The part that varies here is the payment strategy.

Let’s encapsulate it.

Step 1: Define an Interface

Step 2: Implement Different Strategies

Step 3: Delegate to the Strategy

Now, if a new payment method is introduced, no existing code needs to be modified. You simply implement a new strategy.

Benefits of Encapsulating What Varies

Isolates change: Keeps volatile logic away from stable parts of your system
Improves readability: Each variant is cleanly separated from the others
Follows Open/Closed Principle: You can extend behavior without modifying existing code
Increases reusability: Strategies can be reused in other parts of the application
Simplifies testing: Each strategy can be tested independently

When to Apply This Principle

Apply “Encapsulate What Varies” when:

You notice logic that changes frequently
You have conditional branches that check for modes, types, or behaviors
New features often require changes to the same part of the codebase
You want to allow plug-and-play behaviors

When to Delay It

While encapsulating variation is powerful, don’t apply it prematurely.

If you only have one behavior and no foreseeable need to change it, abstraction may introduce unnecessary complexity.

Follow the Rule of Three:

The third time you need to change something, consider extracting it.

Final Thought

Software is always changing. The key is to change it without breaking everything else.

Encapsulating variation allows you to build flexible systems where each piece can evolve independently.

So the next time you write a function with too many if statements or see logic changing in unpredictable ways, ask yourself:

“What’s the part that keeps changing?”“Can I put that in its own class or module?”

Because once you identify what varies, you can design for change—without fear of chaos.

Encapsulate what Varies