Open-Closed Principle

Overview

The Open-Closed Principle (OCP) says software entities should be open for extension but closed for modification: you should be able to add new behavior without editing existing, tested code. In practice, this means depending on abstractions so new cases are new classes.

OCP is the reason Strategy, Decorator, Observer, and plugin architectures exist. It does not mean code is never edited; it means the parts that change often (new payment types, discount rules, file formats) are designed as extension points, so adding one does not ripple through the system.

When to use it

• A class keeps growing a switch or if/else for new types.
• New variants arrive regularly (discounts, formats, providers).
• Existing behavior is critical and risky to modify.

Where it shows up in interviews

Where it is used in real software

Key terms

Extension point

An abstraction where new behavior can plug in.

Closed for modification

Existing code does not change for new cases.

Registry

Map of keys to implementations for lookup.

How it works, step by step

1. 1
   Identify the axis of change

   What new variants keep arriving?

2. 2
   Extract an abstraction for it

   DiscountRule.apply(cart).

3. 3
   Move each existing case into a class

   PercentageOff, BuyOneGetOne.

4. 4
   Register implementations

   List, map, or DI container.

5. 5
   Add new cases as new classes

   No edits to the engine.

Adding a new discount

Discount engine supports percentage and flat discounts; add 'buy 2 get 1'

OCP localizes change: the new feature lives in a new file.

Implementation

1type Cart = { items: { sku: string; qty: number; priceCents: number }[]; coupon?: string };2 3interface DiscountRule {4  appliesTo(cart: Cart): boolean;5  discountCents(cart: Cart): number;6}7 8const subtotal = (c: Cart) => c.items.reduce((s, i) => s + i.qty * i.priceCents, 0);9 10class PercentageOff implements DiscountRule {11  constructor(private code: string, private pct: number) {}12  appliesTo(c: Cart) { return c.coupon === this.code; }13  discountCents(c: Cart) { return Math.round(subtotal(c) * this.pct); }14}15 16class BuyTwoGetOne implements DiscountRule { // new rule: no existing code edited17  constructor(private sku: string) {}18  appliesTo(c: Cart) { return c.items.some((i) => i.sku === this.sku && i.qty >= 3); }19  discountCents(c: Cart) {20    const item = c.items.find((i) => i.sku === this.sku)!;21    return Math.floor(item.qty / 3) * item.priceCents;22  }23}24 25class DiscountEngine {26  constructor(private rules: DiscountRule[]) {}27  total(cart: Cart) {28    const discount = this.rules.filter((r) => r.appliesTo(cart)).reduce((s, r) => s + r.discountCents(cart), 0);29    return Math.max(0, subtotal(cart) - discount);30  }31}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Moving the switch into a factory and calling it OCP.

  Fix: A small registry is fine; keep business logic free of type checks.

• Applying OCP before a second variant exists.

  Fix: Refactor to an extension point when change actually repeats.

Interview questions

Practice problems