Practical Tips for Implementing the Open-Closed Principle

You've probably been there: a one-line requirement change forces edits across a dozen files, and the regression tests start lighting up. That's the symptom the Open-Closed Principle (OCP) is designed to prevent. One of the SOLID principles of object-oriented design, OCP holds that a class should be open for extension but closed for modification. In short, you extend behavior by adding code, not by rewriting what already works. This post covers the concrete techniques we use to apply that idea day-to-day.

• What is the Open-Closed Principle?

  Bertrand Meyer coined the term in 1988. The idea is simple: design components so you don't need to crack them open every time requirements shift. Done right, it produces more stable code, cuts regression risk, and makes reuse a natural outcome rather than an afterthought.

• Abstraction and Interface Design

  • Use interfaces. An interface pins down what a component does without dictating how. New implementations slot in without touching the original.

  • Abstract base classes. They give you a skeletal structure: shared logic in the base, custom logic in the subclass. That's the split you want.

• Apply Inheritance

  • Base classes. Declare common behavior and mark the varying parts as abstract methods. Callers don't need to know which subclass they're talking to.

  • Derived classes. Each subclass owns its specific behavior. The contract stays fixed; only the implementation differs.

• Use Polymorphism

  • Method overriding. A derived class replaces a specific method with its own version. The rest of the system doesn't care which variant runs.

  • Run-time binding. Dynamic dispatch picks the right implementation at runtime. You don't write a switch statement; you just add a new class.

• Identify Stable and Volatile Parts

  • Stable components. Some things rarely change: core domain logic, well-understood algorithms. Encapsulate those tightly so they're shielded from churn elsewhere.

  • Volatile components. Know which parts will change: business rules, third-party integrations, pricing logic. Those are your extension points. Plan for them explicitly, not as an afterthought.

• Design for Future Requirements

  • Anticipate change. You won't predict every requirement, but you can spot the categories of things that shift. Build abstractions around those seams before the pressure arrives.

  • Modular design. A module with a single clear responsibility is much easier to extend safely. When a change only touches one module, your blast radius is small.

• Unit Testing and Refactoring

  • Test-driven development. Write the test first. If your new extension breaks an existing test, OCP is violated. The test catches it before a bug does.

  • Continuous refactoring. Don't wait until the code is a mess. Small, regular refactors keep abstractions clean and make the next extension cheaper.

Designing for extensibility is a habit you build, not a rule you consult after the fact. The core tools are abstractions and well-placed extension points. The payoff is concrete: code reviews get smaller, regressions drop, and the next feature request stops requiring a rewrite of something that was working fine. Start by mapping your stable and volatile parts — that single step changes how you design everything downstream.