Open/Closed Principle

Description

The Open/Closed Principle says code should be open for extension but closed for modification: when a new case comes along, you add code instead of editing code that already works. It's how plugin systems, payment providers and discount engines grow without every change re-opening (and re-testing) the core. This skill covers extension points, how to refactor a growing switch into them, and when not to bother.

Here's the kind of code it's about:

double discount(Order order, String campaign) {
    switch (campaign) {
        case "SUMMER": return order.total() * 0.10;
        case "BLACK_FRIDAY": return order.total() * 0.30;
        case "LOYALTY": return Math.min(20, order.total() * 0.05);
        default: return 0;
    }
}

def discount(order: Order, campaign: str) -> float:
    match campaign:
        case "SUMMER":
            return order.total() * 0.10
        case "BLACK_FRIDAY":
            return order.total() * 0.30
        case "LOYALTY":
            return min(20, order.total() * 0.05)
        case _:
            return 0

Marketing launches a new campaign every month. Each one edits this method, re-tests every existing campaign, and risks breaking the ones that already work.

We'll go from simple to more technical:

1. The principle, and the extension point that makes it work.
2. Refactoring a switch into implementations and a registry, step by step.
3. Where you'll see it: patterns, plugins and middleware.
4. Choosing which changes to close against - and which not to.

The principle

Software entities should be open for extension, but closed for modification.

Give the varying behavior an extension point - usually an interface - so new cases are new classes:

interface DiscountRule {
    boolean appliesTo(String campaign);
    double discount(Order order);
}

class Checkout {
    private final List<DiscountRule> rules;
    Checkout(List<DiscountRule> rules) { this.rules = rules; }

    double discount(Order order, String campaign) {
        for (DiscountRule r : rules) if (r.appliesTo(campaign)) return r.discount(order);
        return 0;
    }
}

from abc import ABC, abstractmethod


class DiscountRule(ABC):
    @abstractmethod
    def applies_to(self, campaign: str) -> bool: ...

    @abstractmethod
    def discount(self, order: Order) -> float: ...


class Checkout:
    def __init__(self, rules: list[DiscountRule]):
        self._rules = rules

    def discount(self, order: Order, campaign: str) -> float:
        for r in self._rules:
            if r.applies_to(campaign):
                return r.discount(order)
        return 0

A new campaign is a new DiscountRule class added to the list. Checkout never changes. (In Python, when each rule is a single method, the extension point is often just a callable: a dict from campaign name to function works as well as a class per campaign.)

How to apply it, step by step

1. Find the part that keeps changing - typically a switch or if chain over "kinds".
2. Define an interface for what each kind does.
3. Move each branch into its own implementation.
4. Let the stable code receive the implementations (constructor, list, registry map).
5. Adding a kind now means adding a class and registering it - no edits to tested code.

Where you'll see it

• Strategy, Decorator, Observer and Template Method are all OCP in practice.
• Plugin systems: IDE extensions, java.util.ServiceLoader (Python: package entry points, loaded with importlib.metadata.entry_points(), and pytest's plugin hooks), Spring picking up every bean that implements an interface.
• Web frameworks let you add filters/middleware without editing the framework.

Which tool for which job?

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. Your ReportExporter has if (format == PDF) ... else if (format == CSV) .... How would OCP restructure it?

2. Is an interface with exactly one implementation always good OCP design?

3. Which other principle does OCP depend on so the stable code can stay unchanged?

Key takeaways

• Add behavior by adding code, not editing tested code.
• Put an interface where variation keeps happening; register new implementations.
• Close against the changes you actually expect - not every imaginable one.
• Strategy, Decorator, Observer and plugins are OCP in action.