Skip to content
Software Architecture Guide

Open-Closed Principle

Explanation

Section titled “Explanation”

The principle has two halves. A module is open if you can still extend it. A module is closed if other modules can already use it, because it offers a stable, well-defined interface.

The common slogan says software entities such as classes, modules, and functions should be open for extension but closed for modification. The idea is to add behavior without editing the original code.

Two readings. Meyer’s 1988 book introduced the principle. His idea was extension by inheriting from existing code without changing it. A later, polymorphic reading keeps the abstract interface fixed. New implementations of that interface supply new behavior, and each must at least implement the interface.

Plug-ins. Plug-in style extension relies on inversion of control. Your code plugs something into a framework, and the framework calls it back. The framework stays closed. The plug-in adds behavior.

Dependency inversion. The Dependency Inversion Principle is about shape. Abstractions and high-level policy should not depend on low-level details. Depending on an abstraction is what lets the interface stay fixed while implementations change.

Beyond classes. The slogan names modules as well as classes. Fowler also notes the same idea in building blocks that are extended to handle new scenarios as a system grows.

Example

Section titled “Example”

A shop system calculates shipping costs. The checkout component talks only to a “shipping calculator” interface. At first there is one implementation, for standard delivery. Later the shop adds express delivery and pickup. Each is a new implementation of the same interface. The checkout component does not change.

Trade-offs

Section titled “Trade-offs”

Extension points cost effort. An extension point that is never used is wasted work, and it is likely to get in the way. Abstractions that make the code harder to understand for current requirements are suspect. So add openness where change is expected, not everywhere.

Checkout depends on a fixed interface; new delivery options are added as new implementations.

Diagram source 
@startuml
interface ShippingCalculator
class Checkout
class StandardDelivery
class ExpressDelivery
class Pickup
Checkout --> ShippingCalculator : uses
StandardDelivery ..|> ShippingCalculator
ExpressDelivery ..|> ShippingCalculator
Pickup ..|> ShippingCalculator
@enduml

Checks

Section titled “Checks”
  • Components that are expected to change expose a stable, well-defined interface that other components use.
  • Extension points exist only where change is expected, and unused extension points are removed.
  • New behavior is added through new implementations of an existing interface or through plug-ins, not by editing existing code.
Section titled “Related”

Sources

Section titled “Sources”