When Your else if Framework Starts Fighting Back(Reboot)

at some point in every Salesforce project, the if statements start multiplying.

In every Salesforce project… there’s a moment. The moment when your “simple logic” starts growing teeth. It starts like this:

if(type == 'PERCENTAGE') {
    amount = amount * 0.9;
}
else if(type == 'FIXED') {
    amount = amount - 50;
}

Then the business says:

“We need VIP discounts.” “Oh, and seasonal pricing.” “And partner-based overrides.” “And bulk discounts.” “More, MOre, MORe, MORE!!!!”

Suddenly your class looks like a traffic jam. And every new condition feels like defusing a bomb. Lets not even talk about the test class, “The slow drain toward 74%”

That’s not scaling. That’s surviving.

🧠 My Learning Strategy: Stay Curious, Stay Sharp

• What Happens When You Ignore OCP?
• When Does the else if Pattern Collapse?
• Why Does It Break Systems at Scale?
• Where Does This Hurt the Most in Salesforce?
• Who Feels the Pain?
• How Do We Refactor the Right Way?

What Happens When You Ignore OCP?

Your class becomes:

• A rule engine
• A decision tree
• A performance bottleneck
• A regression risk factory

Every time you add logic, you modify existing code.

And modification = risk.

Even if tests pass, you’ve increased coupling.

And coupling is quiet technical debt.

When Does the else if Pattern Collapse?

The collapse usually happens when:

1. Multiple teams touch the same logic.
2. Logic becomes data-driven.
3. Rules depend on combinations (VIP + Seasonal + Region).
4. The class crosses 300+ lines.
5. A production bug requires a “quick patch.”

The danger isn’t the first else if.

It’s the 14th.

Why Does It Break Systems at Scale?

Because else if chains create:

1️⃣ Tight Coupling

All logic lives in one place. Every rule knows about every other rule.

2️⃣ High Merge Conflict Risk

Two developers adding different conditions? Boom.

Conflict.

3️⃣ Exponential Testing Surface

Each new condition interacts with all previous ones. Combinations explode.

Where Does This Hurt the Most in Salesforce?

Let’s be specific.

Trigger Frameworks

You start with:

if(Trigger.isInsert) {
   ...
}
else if(Trigger.isUpdate) {
   ...
}

Then object-specific logic creeps in. Then profile-based behavior. Then integration-specific bypass logic. Now your trigger handler is a rule engine pretending to be a class.

🔹 Integration Layers

Different API versions. Different payload structures. Different error handling rules.

If all logic sits in one class? You are one “minor update” away from chaos.

🔹 Validation & Pricing Engines

This is where else if goes to die.

Pricing logic grows. Discount logic grows. Exceptions grow.

Business volatility destroys rigid code.

Who Feels the Pain?

👨‍💻 Junior Developers

They’re afraid to touch the class.

👨‍🔧 Senior Developers

They become gatekeepers of “the scary file.”

🧪 QA Teams

Regression testing balloons.

🏢 The Business

Delivery slows down. Confidence drops.

And nobody knows why.

How Do We Refactor the Right Way?

We don’t rewrite everything. We introduce extension points. Let’s evolve our discount example properly.

Step 1 — Remove Conditionals

Instead of:

if(type == 'PERCENTAGE') { ... }
else if(type == 'FIXED') { ... }

We use a Factory.

Step 2 — Add a Factory Layer

public class DiscountStrategyFactory {

    public static DiscountStrategy getStrategy(String type) {

        if(type == 'PERCENTAGE') {
            return new PercentageDiscount();
        }
        if(type == 'FIXED') {
            return new FixedAmountDiscount();
        }

        throw new IllegalArgumentException('Unknown discount type');
    }
}

Now notice something powerful. The conditionals moved. And they shrank. Your core business service is clean.

Step 3 — Push Toward True OCP

Now imagine this:

Instead of modifying the factory every time… You register strategies dynamically.

Custom Metadata. Interface scanning. Dependency injection patterns.

Now adding a new discount type means:

• Create new class
• Add metadata record
• No edits to stable code

That’s when you move from Developer thinking…

To Architect thinking.

Gotchas ⚠️

“But the factory still has if statements!”

Yes.

OCP is not about eliminating conditionals. It’s about isolating volatility. Your goal isn’t zero if. Your goal is controlled change.

Don’t Refactor Too Early

If your logic has changed twice in two years…

It’s not volatile.

Architecture should follow pain.

Not ego.

💭 Final Thought

The else if isn’t evil.

It’s just honest.

It tells you:

“This logic is growing.”

OCP isn’t about elegance.

It’s about survivability.

When the business pivots, your code shouldn’t panic.

Extend. Don’t edit.

That’s the #SalesforceKlever™ way. 🚀