Skip to main content
Category: Principles
Type: Systems design principle
Origin: Bertrand Meyer, Object-Oriented Software Construction, Prentice Hall, 1988
Also known as: OCP; Open/Closed Principle
Quick Answer — The Open-Closed Principle says a working module should stay usable as-is, while new behavior is added beside it rather than carved into it. Bertrand Meyer named the idea in 1988; Robert C. Martin later restated it as “open for extension, closed for modification.” The practical test is simple: a new case should land as a new piece, not as another edit to a file that already works.

​
What is the Open-Closed Principle?

The Open-Closed Principle is a design rule that a software entity—or any similarly structured system—should accept new behavior by extension, without rewriting the parts that clients already depend on.
A module will be said to be open if it is still available for extension… A module will be said to be closed if it is available for use by other modules.
The everyday picture is a wall socket. You do not rewire the house every time you buy a lamp. The socket is closed: its shape is a contract other people can trust. The socket is also open: a kettle, a charger, or a radio can plug in without changing the wall. In code, that hinge is an interface, a hook, or a plugin slot. A long chain of if branches that you reopen for every new tax, payment method, or student type is the opposite shape. The Single Responsibility Principle helps by isolating one reason to change. The Open-Closed Principle asks you to place that reason behind a stable door, so yesterday’s clients do not have to move. Meyer’s 1988 version leaned on inheritance: a compiled class stays closed for its clients, while a descendant adds features. In the 1990s, Martin and others recast the same hinge as abstract interfaces and plugins. The family name stayed. The mechanism shifted from “subclass the old module” to “depend on a contract, then add a new implementer.”

​
Open-Closed Principle in 3 Depths

  • Beginner: When a new case arrives, ask whether you can add a piece instead of editing the old one. If every extra lamp means opening the wall, the socket was never designed.
  • Practitioner: Name the variation you actually expect this quarter—payment type, report format, club kind—and put a stable interface around it. Then add the new case as a new handler. Do not invent slots for futures you cannot name; that fight belongs to YAGNI.
  • Advanced: You can close a module only against predicted variation. Guess the wrong hinge and you get a speculative framework that every change still has to visit. Guess none, and every change becomes shotgun surgery. The principle is a bet about where the next difference will land, not a vow never to touch a file.

​
Origin

The Open-Closed Principle began as a modularity puzzle, not as a slogan on a team wall. Bertrand Meyer, then building the Eiffel language and method, stated it in Object-Oriented Software Construction, published by Prentice Hall in 1988. On page 23 of that first edition he required a “satisfactory modular decomposition” to yield modules that are both open and closed. Open meant you could still add fields or functions. Closed meant other modules could use it from a stable interface—compiled, stored in a library, and published as a baseline. His technical answer at the time was inheritance: a class can be frozen for clients and still extended by a descendant, without disturbing the original. The short line most people quote is not Meyer’s wording. In the January 1996 C++ Report, Robert C. Martin paraphrased him: software entities “should be open for extension, but closed for modification.” Martin’s article, later reused in his 2000 paper “Design Principles and Design Patterns” and in Agile Software Development: Principles, Patterns, and Practices (2003, Prentice Hall), moved the hinge from implementation inheritance to abstract interfaces. New behavior is a new class that satisfies the contract. Old source stays untouched. Two older ideas sit underneath. In December 1972, David Parnas argued in Communications of the ACM (15(12): 1053–1058) that you decompose a system by hiding the design decisions most likely to change—information hiding, not merely wrapping data. In 1996, Alistair Cockburn described Protected Variations: identify predicted variation and put a stable interface around it. Craig Larman, in IEEE Software 18(3): 89–91 (May/June 2001), treated Open-Closed, Protected Variations, and Parnas’s hiding as one principle with different names. Around 2004, Michael Feathers arranged Martin’s “first five” principles into the SOLID mnemonic. The Open-Closed Principle is the “O.” That packaging made the name famous. It did not freeze the mechanism. On 12 May 2014, Martin wrote that plugin systems—Eclipse, Vim, Minecraft—are “the ultimate consummation” of the principle: the core does not point at the plugins; the plugins point at the core.
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

​
Key Points

The Open-Closed Principle earns its keep when the next difference is likely, and you can name the kind of difference before it arrives. It is not a ban on editing. It is a rule about where the edit should land.
1

Closed means clients can trust a contract

A module is closed when other people can use it without watching you rewrite it. The published shape—an interface, a form, a socket—stays still enough that their work does not crumble. If every new request forces you to reopen the same function, those clients are coupled to your private decisions, not to a contract. Closure is for them, not a trophy for the author.
2

Open means new behavior arrives as a new piece

Extension is adding code, a plugin, a handler, or a subclass—not inserting another branch into yesterday’s logic. A shop that adds a payment method by dropping in a new adapter is open. A shop that reopens the checkout file for every card brand is not. The old piece keeps working because you did not carve it.
3

The hinge is a predicted variation point

You cannot close against the unknown. You close against a difference you can name: how a shape is drawn, how a tax is computed, how a club is run. Put a stable door there. Separation of concerns tells you which decisions to keep apart. The Open-Closed Principle tells you which of those decisions should be pluggable. If you cannot name the variation, wait. Premature hinges are how YAGNI gets violated.
4

Do not confuse a sealed file with a sealed defect

Closed-for-modification is not a vow never to patch a bug, a security hole, or a wrong abstraction. A module that must not change behavior for clients can still receive a fix. If the contract itself is wrong, you change the contract and accept the cost. Pretending the file is sacred while the design is rotten is cargo cult, not the principle.

​
Applications

Use the Open-Closed Principle when a family of cases will keep growing and the old cases should keep working. Do not use it to freeze a design you have not yet understood.

Add a new assignment type, not a new tangle

A teaching assistant who keeps editing one 400-line grading script for every new homework is reopening the wall. Name the shared contract—input, rubric, output—and add each assignment as a small handler. The old scripts stay closed. The new week is a new file. KISS still applies: the contract should be short.

Plug in a payment or tax rule

Checkout, payroll, and tax engines rot when every new method is another if. Publish one adapter interface. Add Apple Pay, a regional VAT, or a student discount as a new implementer. Test the new piece alone. Do not retest the whole till because you touched the old branches.

Write a club charter that new groups can join

A school or community group often rewrites its constitution each time a robotics club or a choir appears. Write the rules for clubs—who can start one, how money is reported, when they meet—and leave the list of clubs as an appendix. The charter is closed. Membership is open. The same pattern holds for a household chore rota with a fixed slot shape and changing names.

Keep a public form stable, grow the schedules

Tax returns, grant applications, and building permits already do this when they work: a short core form, then extra schedules for special cases. Adding a new schedule should not rewrite the first page. If every exception forces a new edition of the whole booklet, citizens and clerks both pay for a missing hinge.

​
Case Study

The numbered window onto the Open-Closed Principle as an operating choice is WordPress and its plugin architecture—not a claim that blogging software became Meyer-perfect. Before 2004, people extended WordPress, and its ancestor b2, with “hacks”: copies of instructions that said edit this core file, paste this block. An upgrade overwrote the paste. Custom work and the product fought. On 22 May 2004, Matt Mullenweg announced WordPress 1.2, “Mingus.” Among the features: a “new plugin architecture” so plugins could “hook into nearly every action WordPress does.” The hooks—actions and filters—were extension points. New behavior lived in wp-content/plugins/, not in the files that upgrades replace. The design also changed who owned a feature. Ryan Boren, who had pushed the plugin system into the project, later described the core team’s rule of thumb: if a feature is not useful to about 80 percent of users, try it as a plugin. The first bundled example, Hello Dolly, shipped with 1.2: a tiny plugin that prints a lyric, sitting beside the core rather than inside it. The mechanism is the Open-Closed Principle without the name. Core presents a contract. New behavior is a new piece. Old sites can keep their plugins when they upgrade—when the hooks themselves remain stable. The later scale is public, and it is a directory count, not a quality audit. As of August 2026, the WordPress.org plugin directory advertised “over 71,000 free plugins.” That number measures how wide the slot became. It does not prove every plugin is safe, or that core itself never changes. Boundary note: WordPress still modifies core for bugs, security, and new editor work. Many plugins still break on major releases when a hook moves. A plugin that asks you to edit core is the old hack in a new folder. The case shows the hinge—stable hooks, new files—not a claim that an ecosystem of 71,000 add-ons is automatically well designed.

​
Boundaries and Failure Modes

The Open-Closed Principle fails when you cannot yet name the variation. Building a “flexible framework” for futures that never arrive is the classic over-close: many empty sockets, one real lamp, and a house no one can rewire. That is why the principle has to sit next to YAGNI and iterate and improve. Close the hinge after the second or third similar case, not before the first. It also fails where the artifact must be modified and re-certified. A medical device, an aircraft procedure, or a legal form that courts have already interpreted cannot grow by unofficial plugins. There the “closed” part is regulatory, and extension still has to go through a new approved edition. Calling a forbidden fork “open for extension” is a category error. The common misuse is inheritance as a reflex. Meyer’s 1988 answer was subclassing. Martin’s later answer was plugins and abstract interfaces. A deep tree of subclasses that share the wrong parent is not open-closed design. It is a hierarchy you will have to reopen. Another misuse is DRY taken as “never copy a line, always add a strategy object.” Duplication of a five-line case can be cheaper than a premature hinge.

​
Common Misconceptions

The English name collides with “never edit old code,” with “always use inheritance,” and with SOLID as a personality test for classes.
Bugs, security holes, and wrong contracts still get fixed. Closure is relative to clients of a behavior: they should not have to move because you added a case they do not use. If the published contract is wrong, you change it and pay the ripple. A file that cannot be patched is not closed. It is abandoned.
Meyer’s first edition used inheritance because that was the tool he was teaching. Plugin hooks, function tables, configuration, and even a paper appendix are the same shape: a stable door, new pieces beside it. Martin’s 2014 point was that plugin architectures are the principle at full size. A wall socket is not a subclass.
You cannot close against a variation you have not seen. Speculative strategy objects, empty plugin APIs, and “just in case” frameworks are how teams drown in sockets. Wait for a second real case. Then extract the hinge. Until then, a clear if is honest. The principle is a response to predicted change, not a tax on every new file.
These pages sit next to the same problem: how to change a system without shaking everything that already works.

Single Responsibility Principle

One reason to change per module. The Open-Closed Principle decides where that reason is allowed to land.

Separation of Concerns

Keep different decisions apart. Pluggability needs a clean cut before it needs a plugin slot.

YAGNI Principle

Do not build the hinge until the variation is real. Open-closed without YAGNI becomes speculative architecture.

DRY Principle

One representation of a fact. Over-DRY can force a fake hinge; under-DRY keeps reopening the same file.

KISS Principle

Keep the contract short. A bloated plugin API is not simpler than a few honest branches.

Law of Demeter

Talk to your immediate neighbors. A closed module that leaks its insides is not closed.

​
One-Line Takeaway

When the next case is a kind you can already name, add a new piece behind a stable door—do not reopen the wall for every lamp.