System Design (HLD)Open for Extension, Closed for Modification

Open for Extension, Closed for Modification

LevelIntermediate

Duration60 mins

TopicOpen for Extension, Closed for Modification

3 / 4

The Apparent Contradiction — Open AND Closed?

The Paradox at the Heart of OCP

When developers first encounter the Open/Closed Principle, a natural question arises: How can something be both open and closed at the same time?

This seems like a logical impossibility. A door is either open or closed, not both. A store is either accepting customers or shuttered. How can software defy this basic logic?

The apparent contradiction isn't a flaw in the principle—it's a feature. Understanding why these requirements seem contradictory, and how they're actually compatible, reveals deep insights about software design. This page explores the paradox and sets the stage for its elegant resolution.

What You Will Learn

By the end of this page, you will understand why open and closed seem contradictory, recognize the different perspectives that create this tension, and prepare for the resolution through abstraction.

The Surface-Level Contradiction

Let's state the apparent contradiction explicitly:

The "Open" Requirement: Software should accommodate new behaviors and requirements. It should be extensible, adaptable, capable of evolution.

The "Closed" Requirement: Software should not be changed. Its source code should remain stable, its behavior predictable, its tests valid.

The Apparent Conflict: If we can't change the code, how can we add new behavior? Doesn't adding new behavior require writing new code? And if we're writing to a file, isn't that changing it?

This confusion is understandable. It comes from conflating several distinct concepts:

Concepts Often Conflated in OCP Discussions
Concept A	Concept B	Why They're Different
Adding code	Modifying code	Adding a new file ≠ changing an existing file
Behavior extension	Behavior modification	Enabling new capabilities ≠ changing existing ones
The system	A component	System evolves ≠ every component changes
What code does	How code is structured	Functionality ≠ implementation

The Key Insight: Scope of 'Open' vs. 'Closed'

The resolution begins with recognizing that "open" and "closed" apply to different aspects of the same entity:

Closed applies to the source code and current behavior
Open applies to the behavioral possibilities and system capabilities

A module can be closed (its code doesn't change) while the system containing it remains open (new modules can be added). The module's code is frozen; the system's capabilities grow.

The Drawer Analogy

Think of a filing cabinet. Each drawer can be 'closed' (sealed, contents fixed) while the cabinet itself remains 'open' (you can add more drawers). The existing drawers don't change when you add new ones. OCP operates on this principle—individual components are closed, but their container is open.

The Historical Context

Understanding the paradox requires understanding its historical context. When Bertrand Meyer formulated OCP in 1988, software development looked very different:

The 1988 Reality:

Compilation was expensive (hours for large systems)
Integration testing was manual and time-consuming
Code changes required full recompilation of dependent modules
Version control was primitive or nonexistent
Deployment was complex and risky

In this environment, any modification to existing code was costly:

Changed modules required recompilation
Dependent modules required relinking
Everything required retesting
Risks compounded with each change

Meyer's insight was pragmatic: if we could design systems where new features required only new code, we could avoid the cascade of recompilation, relinking, and retesting.

1988CompilationCosts.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 1988: Adding a new shape to a graphics system
 
## Without OCP (Modification-Based)
1. Modify graphics_base.h     → All dependent files recompile
2. Modify shape.c             → Recompile shape module
3. Modify renderer.c          → Recompile renderer module
4. Modify test_graphics.c     → Recompile tests
5. Full link of system        → 45 minutes
6. Manual regression testing  → 2 hours
 
Total impact: 3+ hours, high risk
 
## With OCP (Extension-Based)
1. Create new file: circle.c  → Compile only this file
2. Register circle in config  → No recompilation
3. Test circle only           → 10 minutes
 
Total impact: 15 minutes, isolated risk

The Principle Endures

While compilation costs have decreased dramatically, Meyer's principle remains relevant for different reasons today:

1988 Motivation	2024 Motivation
Compilation time	Reduced cognitive load
Linking complexity	Isolated testing
Retest burden	Safer deployments
Binary distribution	Microservice evolution
Physical media updates	Continuous delivery

The mechanism of the benefit has changed, but the principle remains sound: changes isolated to new code are safer than changes to existing code.

Standing on Giants' Shoulders

OCP didn't emerge in a vacuum. It built on earlier ideas: David Parnas's work on information hiding (1972), the concept of abstract data types, and the emerging field of object-oriented programming. Understanding this lineage helps appreciate OCP's depth.

The Real-World Tension

Beyond the logical paradox, there's a practical tension that makes OCP challenging. Real-world requirements don't always fit neatly into "extension" categories:

Requirements That Challenge OCP

•Changing existing behavior — 'The discount calculation should work differently' (not add a new discount—change the existing one)
•Cross-cutting modifications — 'Add logging to all service methods' (affects many existing files)
•Schema changes — 'Add a new required field to User' (existing code must handle it)
•Algorithm replacement — 'Use a faster sorting algorithm' (replace, not extend)
•Bug fixes in production — 'Fix the race condition in OrderProcessor' (must change existing code)

These scenarios reveal an important truth: OCP is an ideal, not an absolute law. Some changes genuinely require modifying existing code. The goal isn't to achieve perfect closure (impossible) but to:

Maximize the proportion of changes that can be extensions
Design extension points at boundaries likely to change
Minimize modification when modification is necessary
Isolate modifications to reduce blast radius

The 80/20 Observation

In well-designed systems, roughly:

80% of new requirements can be met through extension
20% require modification of existing code

Poorly designed systems flip this ratio:

20% of new requirements can be met through extension
80% require modification of existing code

OCP is about engineering your way toward the good ratio.

Perfection Is Not The Goal

Developers sometimes reject OCP because 'some modifications are inevitable.' This misses the point. OCP guides design toward extension over modification, not toward eliminating all modification. A system where 90% of changes are extensions is far better than one where 90% of changes are modifications.

The Levels of the Paradox

The open/closed paradox operates at multiple levels, and understanding each level clarifies the resolution:

Level 1: The Source Code Level

At this level, the paradox is most acute. A file is either edited or not. Bytes change or they don't.

Resolution: OCP at the source level means new files, not edited files. The system expands through addition, not modification.

SourceCodeResolution.txt
1
2
3
4
5
6
7
8
9
10
11
12
Initial State:
├── PaymentProcessor.java       (100 lines, tested)
├── CreditCardHandler.java      (50 lines, tested)
└── PayPalHandler.java          (45 lines, tested)
 
After adding Apple Pay support (OCP-compliant):
├── PaymentProcessor.java       (100 lines, UNCHANGED)
├── CreditCardHandler.java      (50 lines, UNCHANGED)
├── PayPalHandler.java          (45 lines, UNCHANGED)
└── ApplePayHandler.java        (55 lines, NEW)
 
The existing files are closed. The system is open via new files.

Level 2: The Behavioral Level

At this level, we consider what the system does.

Resolution: Existing behaviors are closed (CreditCard processing works identically). New behaviors are open (ApplePay now works too). The system's behavioral repertoire expands without altering existing behaviors.

Level 3: The Contract Level

At this level, we consider interfaces and APIs.

Resolution: Contracts are highly closed (the PaymentHandler interface doesn't change). But contracts define extension points (any new class can implement PaymentHandler). Closed contracts enable open implementation.

Level 4: The Architectural Level

At this level, we consider system structure.

Resolution: Architecture defines where openness lives. A payment system is "open at the handler boundary" and "closed at the processor core." Architecture maps openness to the points most likely to need extension.

Multi-Level Thinking

When evaluating OCP compliance, specify the level. 'Is this open?' is ambiguous. 'Is this open for new payment handlers at the behavioral level?' is precise and answerable.

The False Dichotomy

Much confusion around OCP stems from treating "open" and "closed" as mutually exclusive states of a single property. In reality, they describe different properties entirely:

Wrong Mental Model

•Open and closed are opposites
•A module is either open OR closed
•Being more open means being less closed
•Choose between flexibility and stability

Correct Mental Model

•Open and closed describe different dimensions
•A module is open FOR X and closed FOR Y
•Openness and closure can both increase
•Design determines which dimensions are which

The Multi-Dimensional View

Think of openness and closure as independent axes:

                    HIGH OPENNESS
                         ↑
                         |
    Fragile              |              Ideal
    (extensible but      |    (extensible AND stable)
     unstable)           |
                         |
LOW CLOSURE ←------------+------------→ HIGH CLOSURE
                         |
    Rigid                |              Encapsulated
    (neither extensible  |    (stable but not extensible)
     nor stable)         |
                         |
                         ↓
                    LOW OPENNESS

The goal is the upper-right quadrant: high openness (extensible) AND high closure (stable).

This isn't a paradox—it's a design challenge. And the solution lies in abstraction.

Independence of Dimensions

The best designs maximize BOTH openness and closure. This seems impossible only if you think they're inversely related. They're not. A well-designed abstraction can be maximally open (infinite implementations possible) AND maximally closed (interface never changes).

Previewing the Resolution

Before diving into the full resolution (next page), let's preview how abstraction resolves the paradox:

The Core Mechanism

Abstraction creates a separation between:

What something does (interface/contract) — This is CLOSED
How something does it (implementation) — This is OPEN

The interface defines a stable contract. Implementations vary. Clients depend on the stable interface. New implementations extend capabilities without changing anything clients depend on.

AbstractionPreview.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// CLOSED: This interface never changes
public interface Encoder {
    byte[] encode(String data);
}
 
// OPEN: New implementations can be added indefinitely
public class Base64Encoder implements Encoder { /* ... */ }
public class HexEncoder implements Encoder { /* ... */ }
public class UrlEncoder implements Encoder { /* ... */ }
// Future: Brotli, custom protocols, whatever
 
// Client code: depends on the closed interface
public class DataProcessor {
    private final Encoder encoder;  // Can be any implementation
    
    public void process(String data) {
        byte[] encoded = encoder.encode(data);  // Same call, different behavior
        // ...
    }
}
 
// The client is CLOSED (doesn't change for new encoders)
// The system is OPEN (new encoders can be added)
// The interface is CLOSED (contract is stable)
// The implementations are OPEN (unlimited variety)

The Abstraction Inversion

The key insight is that abstraction inverts the relationship between stability and flexibility:

Without abstraction:

To be flexible → code must change → unstable

With abstraction:

Contract is stable → code that depends on it is stable
Implementations vary → system is flexible
Stability enables flexibility rather than opposing it

This inversion is why abstraction resolves the open/closed paradox. The next page explores this mechanism in full depth.

The Resolution Ahead

Abstraction is not just a programming technique—it's the fundamental mechanism that makes OCP possible. By separating 'what' from 'how,' abstraction creates stable interfaces that enable unlimited implementation variation.

Summary — The Paradox Explained

We've dissected the apparent contradiction at OCP's heart. Let's consolidate:

Key Takeaways

•The paradox is apparent, not real — Open and closed apply to different aspects of software, not the same aspect.
•Historical context matters — OCP emerged to minimize costly recompilation/relinking, but its principles remain valuable for cognitive and testing reasons.
•OCP is an ideal, not absolute — Some modifications are inevitable. The goal is maximizing the proportion of changes that can be extensions.
•The paradox operates at multiple levels — Source code, behavior, contract, and architecture each have their own open/closed dynamics.
•Open and closed are independent dimensions — Not opposites. The best designs are high on BOTH axes.
•Abstraction resolves the paradox — By separating interface (closed) from implementation (open), abstraction enables simultaneous openness and closure.

Coming Next:

We've set up the puzzle. Now it's time to solve it. The next page provides a comprehensive treatment of how abstraction—through interfaces, abstract classes, and polymorphism—resolves the open/closed paradox and enables the design of truly extensible, stable systems.

Page Complete

You now understand why the Open/Closed Principle appears paradoxical and why that appearance is misleading. The paradox dissolves once we recognize that open and closed describe independent dimensions of software design. Next, we'll see how abstraction provides the mechanism to achieve both.

3 / 4

Loading learning content...

System Design (HLD)Open for Extension, Closed for Modification

Open for Extension, Closed for Modification

LevelIntermediate

Duration60 mins

TopicOpen for Extension, Closed for Modification

3 / 4

The Apparent Contradiction — Open AND Closed?

The Paradox at the Heart of OCP

When developers first encounter the Open/Closed Principle, a natural question arises: How can something be both open and closed at the same time?

This seems like a logical impossibility. A door is either open or closed, not both. A store is either accepting customers or shuttered. How can software defy this basic logic?

What You Will Learn

By the end of this page, you will understand why open and closed seem contradictory, recognize the different perspectives that create this tension, and prepare for the resolution through abstraction.

The Surface-Level Contradiction

Let's state the apparent contradiction explicitly:

The "Open" Requirement: Software should accommodate new behaviors and requirements. It should be extensible, adaptable, capable of evolution.

The "Closed" Requirement: Software should not be changed. Its source code should remain stable, its behavior predictable, its tests valid.

The Apparent Conflict: If we can't change the code, how can we add new behavior? Doesn't adding new behavior require writing new code? And if we're writing to a file, isn't that changing it?

This confusion is understandable. It comes from conflating several distinct concepts:

Concepts Often Conflated in OCP Discussions
Concept A	Concept B	Why They're Different
Adding code	Modifying code	Adding a new file ≠ changing an existing file
Behavior extension	Behavior modification	Enabling new capabilities ≠ changing existing ones
The system	A component	System evolves ≠ every component changes
What code does	How code is structured	Functionality ≠ implementation

The Key Insight: Scope of 'Open' vs. 'Closed'

The resolution begins with recognizing that "open" and "closed" apply to different aspects of the same entity:

Closed applies to the source code and current behavior
Open applies to the behavioral possibilities and system capabilities

A module can be closed (its code doesn't change) while the system containing it remains open (new modules can be added). The module's code is frozen; the system's capabilities grow.

The Drawer Analogy

The Historical Context

Understanding the paradox requires understanding its historical context. When Bertrand Meyer formulated OCP in 1988, software development looked very different:

The 1988 Reality:

Compilation was expensive (hours for large systems)
Integration testing was manual and time-consuming
Code changes required full recompilation of dependent modules
Version control was primitive or nonexistent
Deployment was complex and risky

In this environment, any modification to existing code was costly:

Changed modules required recompilation
Dependent modules required relinking
Everything required retesting
Risks compounded with each change

Meyer's insight was pragmatic: if we could design systems where new features required only new code, we could avoid the cascade of recompilation, relinking, and retesting.

1988CompilationCosts.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 1988: Adding a new shape to a graphics system
 
## Without OCP (Modification-Based)
1. Modify graphics_base.h     → All dependent files recompile
2. Modify shape.c             → Recompile shape module
3. Modify renderer.c          → Recompile renderer module
4. Modify test_graphics.c     → Recompile tests
5. Full link of system        → 45 minutes
6. Manual regression testing  → 2 hours
 
Total impact: 3+ hours, high risk
 
## With OCP (Extension-Based)
1. Create new file: circle.c  → Compile only this file
2. Register circle in config  → No recompilation
3. Test circle only           → 10 minutes
 
Total impact: 15 minutes, isolated risk

The Principle Endures

While compilation costs have decreased dramatically, Meyer's principle remains relevant for different reasons today:

1988 Motivation	2024 Motivation
Compilation time	Reduced cognitive load
Linking complexity	Isolated testing
Retest burden	Safer deployments
Binary distribution	Microservice evolution
Physical media updates	Continuous delivery

The mechanism of the benefit has changed, but the principle remains sound: changes isolated to new code are safer than changes to existing code.

Standing on Giants' Shoulders

The Real-World Tension

Beyond the logical paradox, there's a practical tension that makes OCP challenging. Real-world requirements don't always fit neatly into "extension" categories:

Requirements That Challenge OCP

•Changing existing behavior — 'The discount calculation should work differently' (not add a new discount—change the existing one)
•Cross-cutting modifications — 'Add logging to all service methods' (affects many existing files)
•Schema changes — 'Add a new required field to User' (existing code must handle it)
•Algorithm replacement — 'Use a faster sorting algorithm' (replace, not extend)
•Bug fixes in production — 'Fix the race condition in OrderProcessor' (must change existing code)

Maximize the proportion of changes that can be extensions
Design extension points at boundaries likely to change
Minimize modification when modification is necessary
Isolate modifications to reduce blast radius

The 80/20 Observation

In well-designed systems, roughly:

80% of new requirements can be met through extension
20% require modification of existing code

Poorly designed systems flip this ratio:

20% of new requirements can be met through extension
80% require modification of existing code

OCP is about engineering your way toward the good ratio.

Perfection Is Not The Goal

The Levels of the Paradox

The open/closed paradox operates at multiple levels, and understanding each level clarifies the resolution:

Level 1: The Source Code Level

At this level, the paradox is most acute. A file is either edited or not. Bytes change or they don't.

Resolution: OCP at the source level means new files, not edited files. The system expands through addition, not modification.

SourceCodeResolution.txt
1
2
3
4
5
6
7
8
9
10
11
12
Initial State:
├── PaymentProcessor.java       (100 lines, tested)
├── CreditCardHandler.java      (50 lines, tested)
└── PayPalHandler.java          (45 lines, tested)
 
After adding Apple Pay support (OCP-compliant):
├── PaymentProcessor.java       (100 lines, UNCHANGED)
├── CreditCardHandler.java      (50 lines, UNCHANGED)
├── PayPalHandler.java          (45 lines, UNCHANGED)
└── ApplePayHandler.java        (55 lines, NEW)
 
The existing files are closed. The system is open via new files.

Level 2: The Behavioral Level

At this level, we consider what the system does.

Level 3: The Contract Level

At this level, we consider interfaces and APIs.

Level 4: The Architectural Level

At this level, we consider system structure.

Multi-Level Thinking

When evaluating OCP compliance, specify the level. 'Is this open?' is ambiguous. 'Is this open for new payment handlers at the behavioral level?' is precise and answerable.

The False Dichotomy

Much confusion around OCP stems from treating "open" and "closed" as mutually exclusive states of a single property. In reality, they describe different properties entirely:

Wrong Mental Model

•Open and closed are opposites
•A module is either open OR closed
•Being more open means being less closed
•Choose between flexibility and stability

Correct Mental Model

•Open and closed describe different dimensions
•A module is open FOR X and closed FOR Y
•Openness and closure can both increase
•Design determines which dimensions are which

The Multi-Dimensional View

Think of openness and closure as independent axes:

                    HIGH OPENNESS
                         ↑
                         |
    Fragile              |              Ideal
    (extensible but      |    (extensible AND stable)
     unstable)           |
                         |
LOW CLOSURE ←------------+------------→ HIGH CLOSURE
                         |
    Rigid                |              Encapsulated
    (neither extensible  |    (stable but not extensible)
     nor stable)         |
                         |
                         ↓
                    LOW OPENNESS

The goal is the upper-right quadrant: high openness (extensible) AND high closure (stable).

This isn't a paradox—it's a design challenge. And the solution lies in abstraction.

Independence of Dimensions

Previewing the Resolution

Before diving into the full resolution (next page), let's preview how abstraction resolves the paradox:

The Core Mechanism

Abstraction creates a separation between:

What something does (interface/contract) — This is CLOSED
How something does it (implementation) — This is OPEN

The interface defines a stable contract. Implementations vary. Clients depend on the stable interface. New implementations extend capabilities without changing anything clients depend on.

AbstractionPreview.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// CLOSED: This interface never changes
public interface Encoder {
    byte[] encode(String data);
}
 
// OPEN: New implementations can be added indefinitely
public class Base64Encoder implements Encoder { /* ... */ }
public class HexEncoder implements Encoder { /* ... */ }
public class UrlEncoder implements Encoder { /* ... */ }
// Future: Brotli, custom protocols, whatever
 
// Client code: depends on the closed interface
public class DataProcessor {
    private final Encoder encoder;  // Can be any implementation
    
    public void process(String data) {
        byte[] encoded = encoder.encode(data);  // Same call, different behavior
        // ...
    }
}
 
// The client is CLOSED (doesn't change for new encoders)
// The system is OPEN (new encoders can be added)
// The interface is CLOSED (contract is stable)
// The implementations are OPEN (unlimited variety)

The Abstraction Inversion

The key insight is that abstraction inverts the relationship between stability and flexibility:

Without abstraction:

To be flexible → code must change → unstable

With abstraction:

Contract is stable → code that depends on it is stable
Implementations vary → system is flexible
Stability enables flexibility rather than opposing it

This inversion is why abstraction resolves the open/closed paradox. The next page explores this mechanism in full depth.

The Resolution Ahead

Summary — The Paradox Explained

We've dissected the apparent contradiction at OCP's heart. Let's consolidate:

Key Takeaways

•The paradox is apparent, not real — Open and closed apply to different aspects of software, not the same aspect.
•Historical context matters — OCP emerged to minimize costly recompilation/relinking, but its principles remain valuable for cognitive and testing reasons.
•OCP is an ideal, not absolute — Some modifications are inevitable. The goal is maximizing the proportion of changes that can be extensions.
•The paradox operates at multiple levels — Source code, behavior, contract, and architecture each have their own open/closed dynamics.
•Open and closed are independent dimensions — Not opposites. The best designs are high on BOTH axes.
•Abstraction resolves the paradox — By separating interface (closed) from implementation (open), abstraction enables simultaneous openness and closure.

Coming Next:

Page Complete

3 / 4