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

Open for Extension, Closed for Modification

LevelIntermediate

Duration60 mins

TopicOpen for Extension, Closed for Modification

1 / 4

What 'Open' Means — Understanding Extension Points

The Promise of Extensibility

When Bertrand Meyer introduced the Open/Closed Principle in 1988, he articulated a profound insight about software evolution: "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

The word "open" in this principle carries tremendous weight. It represents nothing less than a promise—a guarantee that your software can accommodate new behaviors, features, and requirements without requiring surgery on existing, working code.

But what does it truly mean for software to be "open"? This isn't merely a philosophical question—the answer directly shapes how you architect systems, design interfaces, and structure class hierarchies. Understanding "openness" transforms how you think about software evolution.

What You Will Learn

By the end of this page, you will understand the technical meaning of 'open for extension,' recognize the difference between mechanical extension and semantic extension, and master the patterns that create genuine extension points in your designs.

Defining 'Open' Precisely

In software design, "open for extension" has a precise technical meaning that goes beyond the casual interpretation. Let's establish a rigorous definition:

Open for Extension (Technical Definition):

A software entity is open for extension if its behavior can be extended to accommodate new requirements without modifying its source code.

This definition has several critical implications:

Behavioral extension, not code addition: Extension means adding new behaviors or capabilities, not simply appending lines of code to a file.
Source code preservation: The original source remains untouched. We don't edit existing functions, classes, or modules.
Mechanism independence: The definition doesn't prescribe how extension happens—it could be through inheritance, composition, plugins, configuration, or other mechanisms.

The Subtlety of 'Behavior'

When we say 'extend behavior,' we mean enabling the system to do something it couldn't do before—process a new file format, apply a new discount rule, render a new report type. We're not talking about fixing bugs or optimizing performance. Extension adds capabilities; it doesn't repair them.

Why This Precision Matters

Many developers have a fuzzy understanding of "open," leading to designs that appear extensible but fail in practice. Consider these common misconceptions:

Misconception	Reality
"Open means I can add new methods"	Adding methods often requires modifying the class—the opposite of OCP
"Open means the code is readable"	Readability is valuable but unrelated to extensibility
"Open means I can subclass anything"	Subclassing without designed extension points creates fragile hierarchies
"Open means public access to internals"	Exposing internals typically prevents safe extension

True openness is architectural, not mechanical. It requires deliberate design of extension points—places where new behavior can be injected without touching existing code.

Extension Points — The Heart of Openness

An extension point is a deliberately designed location in your software where new behavior can be introduced without modifying existing code. Extension points are the mechanism by which "openness" becomes real.

Extension points come in several forms, each appropriate for different situations:

Types of Extension Points

•Abstract Methods / Interfaces — Declare a contract that implementations must fulfill. New implementations = new behaviors without touching the contract.
•Composition Slots — Objects that accept collaborators implementing specific roles. Swapping collaborators changes behavior.
•Configuration Points — External data (config files, environment variables, feature flags) that alter behavior without code changes.
•Plugin/Hook Systems — Registries where new handlers can be registered at runtime or compile time.
•Template Methods — Abstract base classes that define a skeleton algorithm, with abstract methods as customization points.

Extension Points in Action: A Payment Processing Example

Consider a payment processing system that initially supports credit cards. A poorly designed system might look like this:

NonExtensiblePaymentProcessor.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
26
// ❌ BAD: Not open for extension
public class PaymentProcessor {
    public PaymentResult process(PaymentRequest request) {
        // Directly handles credit card logic
        if (request.getType().equals("CREDIT_CARD")) {
            CreditCardDetails card = (CreditCardDetails) request.getDetails();
            // Validate card number
            if (!validateLuhn(card.getNumber())) {
                return PaymentResult.failure("Invalid card number");
            }
            // Call payment gateway
            GatewayResponse response = creditCardGateway.charge(
                card.getNumber(),
                card.getExpiry(),
                card.getCvv(),
                request.getAmount()
            );
            return mapGatewayResponse(response);
        }
        // What happens when we need PayPal? We must modify this class.
        // What happens when we need Apple Pay? More modifications.
        // Every new payment method = changes to this file.
        
        return PaymentResult.failure("Unsupported payment type");
    }
}

This design has no extension points. Every new payment method requires modifying the PaymentProcessor class. Now consider an extensible design:

ExtensiblePaymentProcessor.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
26
27
28
// ✅ GOOD: Open for extension through abstraction
public interface PaymentHandler {
    boolean supports(PaymentRequest request);
    PaymentResult process(PaymentRequest request);
}
 
public class PaymentProcessor {
    private final List<PaymentHandler> handlers;  // Extension point!
    
    public PaymentProcessor(List<PaymentHandler> handlers) {
        this.handlers = handlers;
    }
    
    public PaymentResult process(PaymentRequest request) {
        // Find the appropriate handler - no knowledge of specific payment types
        for (PaymentHandler handler : handlers) {
            if (handler.supports(request)) {
                return handler.process(request);
            }
        }
        return PaymentResult.failure("No handler found for payment type");
    }
}
 
// New payment types = new classes, not modifications
public class CreditCardHandler implements PaymentHandler { /* ... */ }
public class PayPalHandler implements PaymentHandler { /* ... */ }
public class ApplePayHandler implements PaymentHandler { /* ... */ }  // Added later!

The Extension Point Pattern

The PaymentProcessor is now open for extension. Adding Apple Pay requires creating a new ApplePayHandler class and registering it—the PaymentProcessor class remains completely unchanged. The List<PaymentHandler> is the extension point.

Mechanical vs. Semantic Extension

A critical distinction often overlooked is the difference between mechanical extension and semantic extension. Understanding this distinction separates amateur designs from professional ones.

Mechanical Extension: The programming language allows you to subclass or implement an interface. The compiler accepts it.

Semantic Extension: The design intends for you to subclass or implement. The abstraction makes sense, the contract is clear, and extending produces predictable results.

Many designs enable mechanical extension while semantically resisting it. This leads to brittle hierarchies, violated invariants, and the infamous "Fragile Base Class Problem."

Mechanical-Only Extension

•Class is public, so you can subclass it
•No documentation on extension contract
•Implementation details leak through
•Protected members expose internal state
•Overriding methods breaks invariants
•Base class changes break subclasses

Semantic Extension

•Clear interfaces document extension contract
•Abstract methods define customization points
•Implementation details are hidden
•Extension doesn't require internal knowledge
•Contract specifies what must be preserved
•Base class changes don't break extensions

Example: The StringBuilder Trap

Consider Java's StringBuilder. It's a public, non-final class. Mechanically, you can extend it:

DangerousExtension.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ❌ Dangerous: Mechanical extension without semantic support
public class LoggingStringBuilder extends StringBuilder {
    
    @Override
    public StringBuilder append(String str) {
        System.out.println("Appending: " + str);
        return super.append(str);
    }
    
    // BUT... StringBuilder has 13+ append overloads!
    // We've only overridden one. The others bypass our logging.
    // This extension is brittle and incomplete.
    // Future JDK versions might add more overloads, breaking us further.
}

StringBuilder wasn't designed for extension. It has no documented extension contract. The correct approach uses composition:

SafeComposition.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
// ✅ Safe: Composition instead of fragile inheritance
public class LoggingStringBuilder {
    private final StringBuilder delegate = new StringBuilder();
    
    public LoggingStringBuilder append(String str) {
        System.out.println("Appending: " + str);
        delegate.append(str);
        return this;
    }
    
    public LoggingStringBuilder append(int i) {
        System.out.println("Appending int: " + i);
        delegate.append(i);
        return this;
    }
    
    // We explicitly choose which operations to expose
    // No hidden backdoors, no fragile base class problems
    
    @Override
    public String toString() {
        return delegate.toString();
    }
}

The Inheritance Trap

Just because you CAN extend a class doesn't mean you SHOULD. True openness requires deliberate design. When encountering a class without clear extension documentation, prefer composition over inheritance.

Designing for Openness

Creating genuinely open software requires deliberate design decisions. Here are the key principles for designing extension points:

1. Define Abstractions, Not Implementations

The foundation of openness is abstraction. Instead of encoding specific behaviors, define the shape of behaviors:

AbstractionForOpenness.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Define the abstraction (what we need)
public interface ReportGenerator {
    String getFormat();
    byte[] generate(ReportData data);
}
 
// The system depends on the abstraction
public class ReportingService {
    private final Map<String, ReportGenerator> generators;
    
    public byte[] generateReport(String format, ReportData data) {
        ReportGenerator generator = generators.get(format);
        if (generator == null) {
            throw new UnsupportedFormatException(format);
        }
        return generator.generate(data);
    }
    
    // Extension point: register new generators without modifying this class
    public void registerGenerator(ReportGenerator generator) {
        generators.put(generator.getFormat(), generator);
    }
}

2. Separate Stable from Unstable Elements

Not all code changes at the same rate. Identify which parts are likely to change (unstable) and which should remain constant (stable). Design extension points at the boundaries:

Stable vs. Unstable Elements
Typically Stable	Typically Unstable
Core domain logic	Presentation/formatting
Data model structure	Validation rules
Workflow orchestration	Specific step implementations
Security framework	Authentication providers
Persistence abstraction	Database-specific queries

3. Use Dependency Injection

Extension points are only useful if new implementations can be provided. Dependency injection enables this by externalizing the choice of implementations:

DependencyInjectionOpenness.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Without DI: Extensions are impossible without source changes
public class OrderService {
    private final InventoryChecker checker = new DatabaseInventoryChecker(); // Hardcoded!
}
 
// With DI: Extensions are trivial
public class OrderService {
    private final InventoryChecker checker;  // Abstract dependency
    
    public OrderService(InventoryChecker checker) {
        this.checker = checker;  // Injected at construction
    }
}
 
// Now we can extend without modification:
OrderService standard = new OrderService(new DatabaseInventoryChecker());
OrderService realTime = new OrderService(new WarehouseApiInventoryChecker());
OrderService cached = new OrderService(new CachedInventoryChecker(underlyingChecker));

Injection = Extension

Every constructor parameter that accepts an interface is a potential extension point. When you inject a collaborator rather than instantiate it, you're creating a seam where new behavior can be introduced.

The Spectrum of Openness

Openness isn't binary—it exists on a spectrum. Understanding this spectrum helps you choose the appropriate level of extensibility for each component:

Levels of Openness
Level	Description	Extension Mechanism	When to Use
Closed	No extension possible	None—code must be modified	Simple utilities, final implementations
Configuration-Open	Behavior adjustable via config	Properties, feature flags	Toggle existing behaviors
Composition-Open	New collaborators accepted	Dependency injection	Most extensibility needs
Inheritance-Open	Subclassing explicitly supported	Abstract classes, template methods	Frameworks, scaffolding code
Plugin-Open	Runtime discovery/loading	Plugin registries, service loaders	Extensible platforms, ecosystems

Choosing the Right Level

More openness isn't always better. Every extension point adds complexity:

More abstractions to understand
More flexibility to abuse
More testing combinations
Higher cognitive load

The goal is appropriate openness—enough to accommodate likely changes, not so much that the system becomes a framework for everything.

Guidelines for Choosing Openness Level

•High-variability areas: Payment methods, report formats, authentication providers → High openness
•Core algorithms: Critical business rules that rarely change → Lower openness
•Integration boundaries: External system connections → High openness (externals change independently)
•Internal utilities: Helpers with stable contracts → Can be closed
•UI components: Presentation that evolves with design → Moderate openness through composition

YAGNI Awareness

Don't create extension points speculatively. If you haven't identified a concrete need for extension, start closed. You can always introduce abstraction later when a genuine need arises. Premature extension points add complexity without value.

Open by Default — A Design Philosophy

While we've cautioned against premature extension points, there's a complementary principle: make your abstractions composition-friendly by default.

This doesn't mean engineering elaborate plugin systems for everything. Rather, it means structuring code so that introducing extension points later is straightforward:

Practices That Enable Future Openness

•Depend on interfaces over concrete classes — Even if only one implementation exists today
•Accept dependencies through constructors — Don't instantiate collaborators internally
•Prefer composition to inheritance — Composed objects are easier to substitute
•Keep methods focused — Small methods are easier to extract behind interfaces
•Minimize protected state — Extension through inheritance becomes fragile with shared mutable state

Example: Refactoring Toward Openness

Consider code that starts closed but can evolve to openness when needed:

EvolvingToOpenness.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
26
27
28
29
30
31
32
33
// Stage 1: Closed but well-structured
public class NotificationService {
    private final EmailSender emailSender;  // Interface, not concrete class
    
    public NotificationService(EmailSender emailSender) {  // Injected
        this.emailSender = emailSender;
    }
    
    public void notifyUser(User user, String message) {
        emailSender.send(user.getEmail(), message);
    }
}
 
// Stage 2: When SMS is needed, openness emerges naturally
public interface NotificationChannel {
    void notify(User user, String message);
}
 
public class NotificationService {
    private final List<NotificationChannel> channels;  // Now fully open!
    
    public NotificationService(List<NotificationChannel> channels) {
        this.channels = channels;
    }
    
    public void notifyUser(User user, String message) {
        for (NotificationChannel channel : channels) {
            channel.notify(user, message);
        }
    }
}
 
// The refactoring was simple because we followed good practices from the start

Future-Proof Structure

Well-structured code enables openness when you need it. By following basic principles—interfaces, injection, composition—you preserve the ability to introduce extension points without major rewrites.

Summary — The Meaning of 'Open'

We've explored the first half of the Open/Closed Principle in depth. Let's consolidate the key insights:

Key Takeaways

•'Open' means behavioral extensibility without source modification — New capabilities are added by creating new code, not changing existing code.
•Extension points are the mechanism of openness — Interfaces, composition slots, plugin systems, and configuration create places where new behavior can be introduced.
•Semantic extension matters more than mechanical extension — Just because you CAN subclass something doesn't mean you SHOULD. Design for intentional extension.
•Openness exists on a spectrum — From closed utilities to full plugin architectures. Choose the appropriate level for each component.
•Well-structured code enables future openness — Following principles like dependency injection and programming to interfaces preserves your ability to add extension points later.

Coming Next:

We've established what "open" means. But the Open/Closed Principle also demands that software be "closed for modification." This appears to contradict openness—how can something be simultaneously open and closed? The next page explores what "closed" means and why it's equally essential.

Page Complete

You now understand the technical meaning of 'open for extension.' Openness is about deliberate design of extension points that allow new behavior without modifying existing code. Next, we'll explore the equally important counterpart: what 'closed' means.

1 / 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

1 / 4

What 'Open' Means — Understanding Extension Points

The Promise of Extensibility

What You Will Learn

Defining 'Open' Precisely

In software design, "open for extension" has a precise technical meaning that goes beyond the casual interpretation. Let's establish a rigorous definition:

Open for Extension (Technical Definition):

A software entity is open for extension if its behavior can be extended to accommodate new requirements without modifying its source code.

This definition has several critical implications:

Behavioral extension, not code addition: Extension means adding new behaviors or capabilities, not simply appending lines of code to a file.
Source code preservation: The original source remains untouched. We don't edit existing functions, classes, or modules.
Mechanism independence: The definition doesn't prescribe how extension happens—it could be through inheritance, composition, plugins, configuration, or other mechanisms.

The Subtlety of 'Behavior'

Why This Precision Matters

Many developers have a fuzzy understanding of "open," leading to designs that appear extensible but fail in practice. Consider these common misconceptions:

Misconception	Reality
"Open means I can add new methods"	Adding methods often requires modifying the class—the opposite of OCP
"Open means the code is readable"	Readability is valuable but unrelated to extensibility
"Open means I can subclass anything"	Subclassing without designed extension points creates fragile hierarchies
"Open means public access to internals"	Exposing internals typically prevents safe extension

True openness is architectural, not mechanical. It requires deliberate design of extension points—places where new behavior can be injected without touching existing code.

Extension Points — The Heart of Openness

Extension points come in several forms, each appropriate for different situations:

Types of Extension Points

•Abstract Methods / Interfaces — Declare a contract that implementations must fulfill. New implementations = new behaviors without touching the contract.
•Composition Slots — Objects that accept collaborators implementing specific roles. Swapping collaborators changes behavior.
•Configuration Points — External data (config files, environment variables, feature flags) that alter behavior without code changes.
•Plugin/Hook Systems — Registries where new handlers can be registered at runtime or compile time.
•Template Methods — Abstract base classes that define a skeleton algorithm, with abstract methods as customization points.

Extension Points in Action: A Payment Processing Example

Consider a payment processing system that initially supports credit cards. A poorly designed system might look like this:

NonExtensiblePaymentProcessor.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
26
// ❌ BAD: Not open for extension
public class PaymentProcessor {
    public PaymentResult process(PaymentRequest request) {
        // Directly handles credit card logic
        if (request.getType().equals("CREDIT_CARD")) {
            CreditCardDetails card = (CreditCardDetails) request.getDetails();
            // Validate card number
            if (!validateLuhn(card.getNumber())) {
                return PaymentResult.failure("Invalid card number");
            }
            // Call payment gateway
            GatewayResponse response = creditCardGateway.charge(
                card.getNumber(),
                card.getExpiry(),
                card.getCvv(),
                request.getAmount()
            );
            return mapGatewayResponse(response);
        }
        // What happens when we need PayPal? We must modify this class.
        // What happens when we need Apple Pay? More modifications.
        // Every new payment method = changes to this file.
        
        return PaymentResult.failure("Unsupported payment type");
    }
}

This design has no extension points. Every new payment method requires modifying the PaymentProcessor class. Now consider an extensible design:

ExtensiblePaymentProcessor.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
26
27
28
// ✅ GOOD: Open for extension through abstraction
public interface PaymentHandler {
    boolean supports(PaymentRequest request);
    PaymentResult process(PaymentRequest request);
}
 
public class PaymentProcessor {
    private final List<PaymentHandler> handlers;  // Extension point!
    
    public PaymentProcessor(List<PaymentHandler> handlers) {
        this.handlers = handlers;
    }
    
    public PaymentResult process(PaymentRequest request) {
        // Find the appropriate handler - no knowledge of specific payment types
        for (PaymentHandler handler : handlers) {
            if (handler.supports(request)) {
                return handler.process(request);
            }
        }
        return PaymentResult.failure("No handler found for payment type");
    }
}
 
// New payment types = new classes, not modifications
public class CreditCardHandler implements PaymentHandler { /* ... */ }
public class PayPalHandler implements PaymentHandler { /* ... */ }
public class ApplePayHandler implements PaymentHandler { /* ... */ }  // Added later!

The Extension Point Pattern

Mechanical vs. Semantic Extension

A critical distinction often overlooked is the difference between mechanical extension and semantic extension. Understanding this distinction separates amateur designs from professional ones.

Mechanical Extension: The programming language allows you to subclass or implement an interface. The compiler accepts it.

Semantic Extension: The design intends for you to subclass or implement. The abstraction makes sense, the contract is clear, and extending produces predictable results.

Many designs enable mechanical extension while semantically resisting it. This leads to brittle hierarchies, violated invariants, and the infamous "Fragile Base Class Problem."

Mechanical-Only Extension

•Class is public, so you can subclass it
•No documentation on extension contract
•Implementation details leak through
•Protected members expose internal state
•Overriding methods breaks invariants
•Base class changes break subclasses

Semantic Extension

•Clear interfaces document extension contract
•Abstract methods define customization points
•Implementation details are hidden
•Extension doesn't require internal knowledge
•Contract specifies what must be preserved
•Base class changes don't break extensions

Example: The StringBuilder Trap

Consider Java's StringBuilder. It's a public, non-final class. Mechanically, you can extend it:

DangerousExtension.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ❌ Dangerous: Mechanical extension without semantic support
public class LoggingStringBuilder extends StringBuilder {
    
    @Override
    public StringBuilder append(String str) {
        System.out.println("Appending: " + str);
        return super.append(str);
    }
    
    // BUT... StringBuilder has 13+ append overloads!
    // We've only overridden one. The others bypass our logging.
    // This extension is brittle and incomplete.
    // Future JDK versions might add more overloads, breaking us further.
}

StringBuilder wasn't designed for extension. It has no documented extension contract. The correct approach uses composition:

SafeComposition.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
// ✅ Safe: Composition instead of fragile inheritance
public class LoggingStringBuilder {
    private final StringBuilder delegate = new StringBuilder();
    
    public LoggingStringBuilder append(String str) {
        System.out.println("Appending: " + str);
        delegate.append(str);
        return this;
    }
    
    public LoggingStringBuilder append(int i) {
        System.out.println("Appending int: " + i);
        delegate.append(i);
        return this;
    }
    
    // We explicitly choose which operations to expose
    // No hidden backdoors, no fragile base class problems
    
    @Override
    public String toString() {
        return delegate.toString();
    }
}

The Inheritance Trap

Designing for Openness

Creating genuinely open software requires deliberate design decisions. Here are the key principles for designing extension points:

1. Define Abstractions, Not Implementations

The foundation of openness is abstraction. Instead of encoding specific behaviors, define the shape of behaviors:

AbstractionForOpenness.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// Define the abstraction (what we need)
public interface ReportGenerator {
    String getFormat();
    byte[] generate(ReportData data);
}
 
// The system depends on the abstraction
public class ReportingService {
    private final Map<String, ReportGenerator> generators;
    
    public byte[] generateReport(String format, ReportData data) {
        ReportGenerator generator = generators.get(format);
        if (generator == null) {
            throw new UnsupportedFormatException(format);
        }
        return generator.generate(data);
    }
    
    // Extension point: register new generators without modifying this class
    public void registerGenerator(ReportGenerator generator) {
        generators.put(generator.getFormat(), generator);
    }
}

2. Separate Stable from Unstable Elements

Not all code changes at the same rate. Identify which parts are likely to change (unstable) and which should remain constant (stable). Design extension points at the boundaries:

Stable vs. Unstable Elements
Typically Stable	Typically Unstable
Core domain logic	Presentation/formatting
Data model structure	Validation rules
Workflow orchestration	Specific step implementations
Security framework	Authentication providers
Persistence abstraction	Database-specific queries

3. Use Dependency Injection

Extension points are only useful if new implementations can be provided. Dependency injection enables this by externalizing the choice of implementations:

DependencyInjectionOpenness.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Without DI: Extensions are impossible without source changes
public class OrderService {
    private final InventoryChecker checker = new DatabaseInventoryChecker(); // Hardcoded!
}
 
// With DI: Extensions are trivial
public class OrderService {
    private final InventoryChecker checker;  // Abstract dependency
    
    public OrderService(InventoryChecker checker) {
        this.checker = checker;  // Injected at construction
    }
}
 
// Now we can extend without modification:
OrderService standard = new OrderService(new DatabaseInventoryChecker());
OrderService realTime = new OrderService(new WarehouseApiInventoryChecker());
OrderService cached = new OrderService(new CachedInventoryChecker(underlyingChecker));

Injection = Extension

The Spectrum of Openness

Openness isn't binary—it exists on a spectrum. Understanding this spectrum helps you choose the appropriate level of extensibility for each component:

Levels of Openness
Level	Description	Extension Mechanism	When to Use
Closed	No extension possible	None—code must be modified	Simple utilities, final implementations
Configuration-Open	Behavior adjustable via config	Properties, feature flags	Toggle existing behaviors
Composition-Open	New collaborators accepted	Dependency injection	Most extensibility needs
Inheritance-Open	Subclassing explicitly supported	Abstract classes, template methods	Frameworks, scaffolding code
Plugin-Open	Runtime discovery/loading	Plugin registries, service loaders	Extensible platforms, ecosystems

Choosing the Right Level

More openness isn't always better. Every extension point adds complexity:

More abstractions to understand
More flexibility to abuse
More testing combinations
Higher cognitive load

The goal is appropriate openness—enough to accommodate likely changes, not so much that the system becomes a framework for everything.

Guidelines for Choosing Openness Level

•High-variability areas: Payment methods, report formats, authentication providers → High openness
•Core algorithms: Critical business rules that rarely change → Lower openness
•Integration boundaries: External system connections → High openness (externals change independently)
•Internal utilities: Helpers with stable contracts → Can be closed
•UI components: Presentation that evolves with design → Moderate openness through composition

YAGNI Awareness

Open by Default — A Design Philosophy

While we've cautioned against premature extension points, there's a complementary principle: make your abstractions composition-friendly by default.

This doesn't mean engineering elaborate plugin systems for everything. Rather, it means structuring code so that introducing extension points later is straightforward:

Practices That Enable Future Openness

•Depend on interfaces over concrete classes — Even if only one implementation exists today
•Accept dependencies through constructors — Don't instantiate collaborators internally
•Prefer composition to inheritance — Composed objects are easier to substitute
•Keep methods focused — Small methods are easier to extract behind interfaces
•Minimize protected state — Extension through inheritance becomes fragile with shared mutable state

Example: Refactoring Toward Openness

Consider code that starts closed but can evolve to openness when needed:

EvolvingToOpenness.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
26
27
28
29
30
31
32
33
// Stage 1: Closed but well-structured
public class NotificationService {
    private final EmailSender emailSender;  // Interface, not concrete class
    
    public NotificationService(EmailSender emailSender) {  // Injected
        this.emailSender = emailSender;
    }
    
    public void notifyUser(User user, String message) {
        emailSender.send(user.getEmail(), message);
    }
}
 
// Stage 2: When SMS is needed, openness emerges naturally
public interface NotificationChannel {
    void notify(User user, String message);
}
 
public class NotificationService {
    private final List<NotificationChannel> channels;  // Now fully open!
    
    public NotificationService(List<NotificationChannel> channels) {
        this.channels = channels;
    }
    
    public void notifyUser(User user, String message) {
        for (NotificationChannel channel : channels) {
            channel.notify(user, message);
        }
    }
}
 
// The refactoring was simple because we followed good practices from the start

Future-Proof Structure

Summary — The Meaning of 'Open'

We've explored the first half of the Open/Closed Principle in depth. Let's consolidate the key insights:

Key Takeaways

•'Open' means behavioral extensibility without source modification — New capabilities are added by creating new code, not changing existing code.
•Extension points are the mechanism of openness — Interfaces, composition slots, plugin systems, and configuration create places where new behavior can be introduced.
•Semantic extension matters more than mechanical extension — Just because you CAN subclass something doesn't mean you SHOULD. Design for intentional extension.
•Openness exists on a spectrum — From closed utilities to full plugin architectures. Choose the appropriate level for each component.
•Well-structured code enables future openness — Following principles like dependency injection and programming to interfaces preserves your ability to add extension points later.

Coming Next:

Page Complete

1 / 4