(O)pen/Closed Principle: Add Features Without Fear 🚪

💭 Ever updated a class for a “tiny change”… and suddenly broke five unrelated features?

Author Created Image

Yeah, that’s why we need the Open/Closed Principle (OCP) — the “O” in SOLID. No more drowning in if statements. Lets not even speak of the else if statement(How to nuke the classes run time with one line of code).

🧠 My Learning Strategy: Stay Curious, Stay Sharp

What is OCP? When Would You Use OCP? Why Would You Use OCP? Where Would You Use OCP? Who Benefits? How Would You Use OCP?

What is OCP?

Classes, modules, and functions should be open for extension but closed for modification.

Translation? Once a piece of code is written and tested, stop poking and prodding it. Instead, design it so you can add new functionality without changing existing code.

When Would You Use OCP?

• When business rules change more often than Salesforce releases.
• When adding a new feature currently means opening up old classes and hoping for the best.
• When your project is large enough that one tiny change could ripple across multiple modules.

Why Would You Use OCP?

• Prevents Regression Bugs — If it’s not edited, it can’t break.
• Improves Maintainability — New features live in new classes, away from proven code.
• Encourages Reusable Design Patterns — Strategy, Factory, and Plug-in patterns love OCP.
• Speeds Up Development — No more digging through legacy code to cram in new logic.

Where Would You Use OCP?

• Apex Services — Pricing engines, discount calculators, tax logic.
• Trigger Frameworks — Add a new handler for new logic, no rewrites.
• Validation & Workflow Engines — New rules? Plug ’em in.
• Lightning Web Components — Config-driven or slot-based behavior extensions.

Who Benefits?

• Developers → Less risk when adding features.
• Testers → Only new code needs new tests.
• Businesses → Faster delivery with fewer nasty surprises.

How Would You Use OCP?

Interface + Strategy Pattern Example

public interface DiscountStrategy {
    Decimal applyDiscount(Decimal amount);
}

// Existing Strategy
public class PercentageDiscount implements DiscountStrategy {
    public Decimal applyDiscount(Decimal amount) {
        return amount * 0.9; // 10% discount
    }
}

// New Strategy – No edits to old code
public class FixedAmountDiscount implements DiscountStrategy {
    public Decimal applyDiscount(Decimal amount) {
        return amount - 50; // R50 off
    }
}

public class DiscountService {
    private DiscountStrategy strategy;

    public DiscountService(DiscountStrategy strategy) {
        this.strategy = strategy;
    }

    public Decimal calculateFinalAmount(Decimal amount) {
        return strategy.applyDiscount(amount);
    }
}

Usage

DiscountService service = new DiscountService(new PercentageDiscount());
System.debug(service.calculateFinalAmount(1000)); // 900

service = new DiscountService(new FixedAmountDiscount());
System.debug(service.calculateFinalAmount(1000)); // 950

Gotchas ⚠️

• “But this means more classes!” Correct. But clean, focused classes beat spaghetti code every time.
• Over-Engineering Alert 🚨 Not every method needs to be an extension point. Start with areas that change often.

💭 Final Thought

OCP keeps your code calm when the business isn’t. Add features, not bugs. Extend, don’t edit. That’s the #SalesforceKlever™ way. 🚀

Side note: If you would like me to write up a demonstrates on how the else if is not your friend, my friend. Say the word, as in actually type the word=>‘word’.

Author Created Image