Open/Closed Principle

Add new behavior by adding new code, not by editing code that already works. Abstractions make that possible; choosing which changes to close against makes it practical.

Overview

The Open/Closed Principle (OCP) says that software entities (classes, modules, functions) should be open for extension but closed for modification. Bertrand Meyer coined the phrase in Object-Oriented Software Construction in 1988. Robert C. Martin made it the first of his design principles in a 1996 C++ Report column, and it became the O in SOLID.

The two halves sound like a contradiction. Open for extension means the module's behavior can grow. Closed for modification means its source does not change. Martin's answer is abstraction: a module that depends on an abstract type is closed, because that type is fixed, yet its behavior can be extended by writing a new subtype.

Open for extension — new behavior can be added — write a new class that implements the abstraction
Closed for modification — working code is not edited — the module calls the abstraction, never a concrete type

Abstraction is the key

Martin's example is a drawing program. The procedural version keeps a type code on each shape and a function that switches on it. Every new shape means editing that function, and every edit risks the shapes that already work.

The switch smell

A conditional on a type tag is the classic sign that a module is not closed. Here is a discount rule that must be edited for every new customer type.

The fix replaces the conditional with polymorphism. Each rule is a class; the caller depends on the abstraction. Adding a student rule is a new class and one registry line.

Not every if is a violation. if amount > 1000: require_approval() is a business rule, not a type switch. The smell is branching on what kind of thing you have in order to pick behavior, which is the job polymorphism was built for.

Strategic closure

Martin is clear that no significant program can be 100 percent closed. The shape program above is closed against new shapes, but not against a new rule that all circles must be drawn before squares. You cannot close against every change, so you choose. Closure is strategic: pick the changes that are most likely and design the abstraction for those.

New payment methods — a PaymentMethod interface with one class per provider
New export formats — an Exporter interface
New pricing rules — a DiscountRule strategy
A change nobody expects — nothing yet; refactor when it arrives

Closing against everything is its own failure: a codebase of interfaces with one implementation each, which nobody can follow. The principle is about the changes you can predict.

Patterns that deliver OCP

Most of the classic patterns from the Gang of Four book (Gamma, Helm, Johnson and Vlissides, 1994) exist to make some module closed against some change.

Strategy — the code that calls the algorithm — a new algorithm class
Template Method — the outline of the algorithm in the base class — a subclass that fills in steps
Decorator — the wrapped object and its callers — a wrapper that adds behavior
Observer — the subject that raises events — a new listener
Plugin or registry — the host that looks up implementations — a new entry in the registry

What you will be able to do

State the principle with both halves and explain how abstraction reconciles them.
Turn a type switch into polymorphism and show that the caller no longer changes.
Say which changes a design is closed against, and which it is not.
Name the pattern that closes a module against a given kind of change.

Interview questions

How do you achieve the Open/Closed Principle in practice?
What is the relationship between OCP and switch or if-else chains on a type?
When is it fine to modify existing code?
What does OCP cost, and when does it go too far?
Refactor a shape-area calculator to follow OCP.