Open/closed O

01 / MEET THE PRINCIPLE

What is Open/closed?

Design a stable part of the system so a chosen kind of new behaviour can be added through an extension.

First understand the idea. Then explore why it helps, before bringing it to life in the harbour.

WHERE THE IDEA BEGAN

A little history.

Bertrand Meyer introduced the open/closed principle in his 1988 book Object-Oriented Software Construction. Robert C. Martin later discussed how abstractions can protect selected parts of a design from recurring changes.

02 / WHY IT MATTERS

Why use it?

Where it helps

Useful for payment methods, export formats, discount policies and delivery strategies when new variants are a realistic requirement.

Why use it?

An extension point can contain the effect of a new variant. Existing code still needs suitable regression tests, but the central algorithm need not gain another special case.

What if you ignore it?

Repeated edits to a growing conditional can entangle unrelated variants. Adding a ticket type may accidentally alter an existing price or leave a branch unhandled.

KNOW THE TRADE-OFF

Useful, not absolute.

Closed does not mean never fix bugs or edit code. Choose which variation to support; no design is closed to every possible change. One simple conditional may be the best starting point.

Next, step into the story and see this problem through a familiar situation.

03 / ONCE UPON A CHANGE

The festival that
keeps growing.

The festival ticket desk has one long instruction sheet: if adult, do this; if child, do that. Every new ticket type sends someone back into the desk’s core rules. A family pass is coming next. Must the desk be rebuilt again?

Keep the desk and give it interchangeable price cards. A new card supplies a price in the agreed way, so the desk can keep doing its job.

Turn to “Try it” to change the design and see what happens.

04 / PULL THE PAPER TAB

What happens
when things change?

Every new pass changes the desk’s conditional.

Every new pass changes the desk’s conditional.

Choose a scenario, then try the change.

An illustrative model, not a benchmark or a claim that every design change causes a bug.

05 / FROM STORY TO CODE

Spot the dependency.

Design a stable part of the system so a chosen kind of new behaviour can be added through an extension.

Before

decimal Price(string pass)
{
    if (pass == "adult") return 20m;
    if (pass == "child") return 8m;
    // Each new pass adds another branch here.
    throw new ArgumentException("Unknown pass");
}

A MORE FOCUSED DESIGN

After

interface IPriceRule { decimal Price(); }
class FamilyPass : IPriceRule
{
    public decimal Price() => 45m;
}

decimal Sell(IPriceRule rule) => rule.Price();
// Setup still selects or registers the new rule.

Illustrative C# sketches. Supporting types and method bodies are omitted; these snippets are not executed in the page.

06 / MAKE IT STICK

Take the idea
with you.

Design a stable part of the system so a chosen kind of new behaviour can be added through an extension.

Try the question opposite, then continue to the next principle.