Introduction to Open Closed Principle

The Open/Closed Principle works by hiding the part that varies behind a stable abstraction — an interface or base type — so that calling code talks to the abstraction and never to the concrete variants; adding a new variant then means writing a new class the caller already knows how to use, not editing the caller. That single sentence is the whole mechanism: polymorphic dispatch through a fixed contract turns "edit existing code" into "add new code."

Bertrand Meyer's original 1988 phrasing: a module is open for extension (its behaviour can be enriched) yet closed for modification (its source — and the clients depending on it — stay frozen).

The gaming-console analogy captures it precisely: the console exposes a fixed USB / controller port (the contract). A racing wheel, a VR headset, a motion controller are new "implementations" of that port. You extend the system by plugging in, never by opening the case and re-soldering the mainboard. The port is closed; the set of things you can plug into it is open.

Why the naive design forces modification

Before any abstraction, code that varies usually lives in a growing if/else or switch on a type tag. Suppose a payments service computes a processing fee per provider:

// NAIVE — closed to nothing, open to bugs
double fee(String provider, double amount) {
    if (provider.equals("CARD"))   return amount * 0.029 + 0.30;
    if (provider.equals("UPI"))    return 0.0;
    if (provider.equals("PAYPAL")) return amount * 0.034 + 0.49;
    throw new IllegalArgumentException(provider);
}

The day Product adds CRYPTO, you must open this method and edit it. Every edit re-touches the already-tested CARD and UPI branches, risks a typo in a string compare, and re-triggers review and regression of code that did not change in intent. The method is a single point that every new provider forces you back into — the exact opposite of closed-for-modification.

The OCP shape: dispatch through a contract

Pull the varying part behind an interface and let a registry pick the implementation. Adding CRYPTO is now a brand-new file plus one registration line — the calculator engine and all three existing providers are never reopened.

interface FeePolicy {                 // the FIXED contract
    double fee(double amount);
}

class CardFee   implements FeePolicy { public double fee(double a){ return a*0.029 + 0.30; } }
class UpiFee    implements FeePolicy { public double fee(double a){ return 0.0; } }
class PaypalFee implements FeePolicy { public double fee(double a){ return a*0.034 + 0.49; } }

class FeeEngine {                     // CLOSED: never edited to add a provider
    private final Map<String, FeePolicy> registry;
    FeeEngine(Map<String, FeePolicy> registry){ this.registry = registry; }
    double charge(String provider, double amount){
        FeePolicy p = registry.get(provider);
        if (p == null) throw new IllegalArgumentException(provider);
        return p.fee(amount);          // polymorphic dispatch — engine never names CardFee etc.
    }
}

// EXTENSION — a new file, plus one registration line, zero edits to the above:
class CryptoFee implements FeePolicy { public double fee(double a){ return a*0.015; } }

Traced example — charging a $100 payment

Engine is built with registry = { CARD→CardFee, UPI→UpiFee, PAYPAL→PaypalFee }. Caller invokes engine.charge("PAYPAL", 100.00):

Now Product ships crypto. We add CryptoFee (above) and register CRYPTO→CryptoFee. Calling engine.charge("CRYPTO", 100.00) dispatches at step 4 to CryptoFee.fee → 100.00 × 0.015 = $1.50. Notice what we did not touch: FeeEngine, CardFee, UpiFee, PaypalFee, and every test covering them. That untouched set is what "closed for modification" buys you.

Pitfalls

• Speculative abstraction (the worst sin). Building a FeePolicy hierarchy when there is exactly one provider, on a hunch that more are coming, is over-engineering. OCP pays off on the axis that actually varies. If providers never multiply but tax rules do, you abstracted the wrong axis and still edit code on every real change. Wait for the second variant before generalising (the "Rule of Three").
• The leaky registry. You move the if/else out of the engine but still have a switch somewhere that builds the registry or maps the type tag to a class. If that spot must be edited for every new variant, you only relocated the violation. Push registration to where the variant is defined (a self-registering module, DI container, or a service-loader file) so the new class truly is the only change.
• Abstraction that doesn't actually close anything. If clients downcast (if (policy instanceof PaypalFee) …) or read a type field off the interface, they're coupled to concretes again and a new variant reopens them. The contract must be rich enough that callers never need to know which implementation they hold.
• Confusing OCP with "never edit code." Bug fixes, contract changes, and refactors absolutely modify existing code. OCP is about not modifying existing code to add anticipated kinds of new behaviour — not a ban on all edits.

When to apply it — and when not

Decision signal: reach for OCP when you can name a family of variants that will keep growing (payment providers, export formats, notification channels, shape types in a renderer) and the cost of editing a shared dispatch point is real — shared ownership, heavy test surface, deployment risk. The clincher is having already seen the second or third variant arrive.

Trade-off vs. the plain if/else / switch: the conditional is concrete, local, and trivially readable — all logic in one place — but it is the modification magnet OCP removes. OCP buys you closure at the cost of indirection (you now jump through an interface to find the real code), more classes/files, and harder "where does this actually run?" navigation. For 2–3 stable cases, the switch usually wins on clarity.

Trade-off vs. Strategy / Template Method: these are the concrete techniques that implement OCP. Strategy (composition + injected interface, as above) varies whole algorithms and is what you want when variants are independent. Template Method (an abstract base class with overridable hooks) suits the case where variants share a fixed skeleton and differ only in steps — but it leans on inheritance and bakes the call order into the base, which is harder to recombine than composed strategies.

One-line rule: choose OCP via a strategy interface when a variant family is open-ended and edits to a shared point are costly; prefer a plain switch when the cases are few and stable, and accept the edit-on-change cost as cheaper than the indirection.

Takeaways

• OCP is mechanical, not magical: it works by routing callers through a fixed contract so a new behaviour is a new class, not an edit to a tested one.
• The win is concentrated on the axis that genuinely varies — abstract that axis, and only after a real second variant appears.
• Inheritance, interfaces, and polymorphism are the means; "add code, don't change code" is the test you apply to check you actually achieved it.
• Watch for the relocated violation: a leaky registry or a downcasting client reopens everything the abstraction was meant to close.

Sources: Bertrand Meyer, Object-Oriented Software Construction (1988, 1997 2nd ed.) for the original open/closed formulation; Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices (2002) and his SOLID articles for the polymorphic-abstraction reading; Gamma et al., Design Patterns (1994) for Strategy and the composition-over-inheritance trade-offs. Re-authored and deepened for this guide: replaced the definition-only treatment and decorative image with the dispatch mechanism, a traced $100 fee example, a hand-drawn naive-vs-OCP diagram, real pitfalls, and selection trade-offs versus switch / Strategy / Template Method. The runnable code is developed in the next lesson, Real World Analogies and Code Example.

Interview drills

Q1. Is OCP absolute — should you never edit existing code?
No. Bug fixes, contract changes, and refactors necessarily modify existing code. OCP only targets one kind of change: adding an anticipated new variant along a known axis without reopening the tested dispatch point. It reduces the frequency and blast-radius of edits on hot change axes; it is not a ban on all edits.

Q2. What is the classic way to fake OCP and still lose?
The "leaky registry": you move the if/else out of the engine but leave a switch that maps type tags to classes and must be edited for every new variant. You only relocated the violation. Make the new class self-register (DI container, service-loader) so adding a variant is genuinely one new file and zero edits.

Q3. OCP via Strategy vs Template Method?
Both implement OCP. Strategy composes an injected interface — independent, recombinable variants (the fee example above). Template Method uses an abstract base with overridable hooks — good when variants share a fixed skeleton and differ only in steps, but it leans on inheritance and bakes in the call order, so it is harder to recombine than composed strategies.