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

Open for Extension, Closed for Modification

LevelIntermediate

Duration60 mins

TopicOpen for Extension, Closed for Modification

4 / 4

How Abstraction Resolves It — The Elegant Solution

The Power of Abstraction

We've established the apparent paradox: software should be simultaneously open for extension and closed for modification. We've seen why these requirements seem contradictory. Now, we reveal the elegant solution: abstraction.

Abstraction isn't just a programming technique—it's the fundamental mechanism that makes the Open/Closed Principle achievable. Through abstraction, we create systems where:

Interfaces remain frozen (closed)
Implementations multiply freely (open)
Clients depend only on stable interfaces (protected from change)
New behaviors emerge without touching existing code (evolution without surgery)

This page explores how abstraction achieves this seemingly impossible feat, transforming the OCP paradox from confusion into clarity.

What You Will Learn

By the end of this page, you will understand the mechanics of abstraction-based extension, master the patterns that enable OCP-compliant designs, and see how interfaces, abstract classes, and polymorphism work together to resolve the open/closed paradox.

The Abstraction Mechanism

Abstraction resolves the open/closed paradox by introducing a layer of indirection between clients and implementations. This layer has two critical properties:

It's stable — The interface/abstract type doesn't change
It's polymorphic — Multiple implementations can satisfy it

This combination is the key. Let's examine the mechanism:

AbstractionMechanism.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
// THE ABSTRACTION (stable, closed)
public interface MessageSender {
    void send(Message message, Recipient recipient);
}
 
// THE CLIENT (depends only on abstraction, therefore stable)
public class NotificationService {
    private final MessageSender sender;  // Abstract dependency
    
    public NotificationService(MessageSender sender) {
        this.sender = sender;
    }
    
    public void notifyUser(User user, String content) {
        Message msg = new Message(content);
        sender.send(msg, user.asRecipient());  // Polymorphic call
    }
}
 
// IMPLEMENTATIONS (vary freely, open)
public class EmailSender implements MessageSender { /* ... */ }
public class SmsSender implements MessageSender { /* ... */ }
public class PushNotificationSender implements MessageSender { /* ... */ }
public class SlackSender implements MessageSender { /* ... */ }  // Added later!
 
// THE RESOLUTION:
// - MessageSender interface: CLOSED (never modified)
// - NotificationService: CLOSED (never modified for new senders)
// - System capability: OPEN (new senders = new capabilities)
// - Existing code: UNCHANGED

Why This Works

The abstraction acts as a contract boundary:

Above the boundary (clients): Depend only on the contract. Protected from implementation changes.
Below the boundary (implementations): Can vary infinitely as long as they satisfy the contract.
At the boundary (interface): Stable, rarely changes. The "closed" part.
Beyond the boundary (new implementations): Can be added freely. The "open" part.

The boundary separates what's closed (contract, clients) from what's open (implementations, future additions).

The Inversion

Without abstraction, flexibility requires change (modify to add capability). With abstraction, stability enables flexibility (stable interface allows infinite implementations). Abstraction inverts the relationship between stability and flexibility.

Interfaces as Extension Points

Interfaces are the primary mechanism for achieving OCP. They define what without specifying how, creating natural extension points:

Interface Properties for OCP

•Behavioral contract — Specifies what operations must be supported
•Implementation freedom — Says nothing about how operations are performed
•Multiple implementations — Any number of classes can implement it
•Client protection — Clients depend on interface, not implementation
•Evolution without modification — New implementations don't change the interface

Designing Effective Interfaces for OCP

Not all interfaces create effective extension points. Well-designed interfaces for OCP have these characteristics:

EffectiveInterfaces.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
34
35
36
37
// ✅ GOOD: Cohesive, focused interface
public interface PriceCalculator {
    Money calculatePrice(Order order);
}
 
// Enables: StandardPriceCalculator, DiscountedPriceCalculator, 
//          WholesalePriceCalculator, DynamicPricingCalculator...
 
// ❌ BAD: Interface too broad, mixed concerns
public interface OrderService {
    Money calculatePrice(Order order);
    void saveOrder(Order order);
    void sendConfirmation(Order order);
    List<Order> findByCustomer(Customer customer);
}
 
// This interface couples calculation, persistence, notification, query
// Hard to implement one concern without others
// Changes to any concern affect the entire interface
 
// ✅ GOOD: Behavior-focused interface
public interface Authenticator {
    AuthenticationResult authenticate(Credentials credentials);
}
 
// Enables: PasswordAuthenticator, OAuthAuthenticator, 
//          BiometricAuthenticator, SsoAuthenticator, MfaAuthenticator...
 
// ❌ BAD: Data-focused interface (getter/setter collection)
public interface UserData {
    String getUsername();
    void setUsername(String username);
    String getEmail();
    void setEmail(String email);
    // This is a data structure, not an abstraction
    // No polymorphic variation is possible
}

Interface Design Principle

Design interfaces around behaviors, not data. Ask 'What does this do?' not 'What data does this have?' Behavioral interfaces enable polymorphic variation; data interfaces just describe structure.

Abstract Classes for Shared Structure

While interfaces define pure contracts, abstract classes provide a hybrid approach: partial implementation with extension points. This is particularly powerful when extensions share common structure but vary in specific behaviors.

AbstractClassesForOCP.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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// Abstract class with Template Method pattern
public abstract class ReportGenerator {
    
    // CLOSED: Common workflow, never modified
    public final byte[] generateReport(ReportData data) {
        String content = buildContent(data);      // Varies
        String formatted = applyFormatting(content);  // Common
        byte[] output = renderOutput(formatted);  // Varies
        logGeneration(data);                      // Common
        return output;
    }
    
    // CLOSED: Common infrastructure
    private String applyFormatting(String content) {
        // Standard formatting applied to all reports
        return FormattingEngine.format(content);
    }
    
    private void logGeneration(ReportData data) {
        logger.info("Report generated: type={}, rows={}", 
            getReportType(), data.getRowCount());
    }
    
    // OPEN: Extension points for subclasses
    protected abstract String buildContent(ReportData data);
    protected abstract byte[] renderOutput(String formatted);
    protected abstract String getReportType();
}
 
// Extensions via subclassing - base class unchanged
public class PdfReportGenerator extends ReportGenerator {
    @Override protected String buildContent(ReportData data) {
        return new PdfContentBuilder().build(data);
    }
    
    @Override protected byte[] renderOutput(String formatted) {
        return PdfEngine.render(formatted);
    }
    
    @Override protected String getReportType() { return "PDF"; }
}
 
public class ExcelReportGenerator extends ReportGenerator {
    @Override protected String buildContent(ReportData data) {
        return new SpreadsheetBuilder().build(data);
    }
    
    @Override protected byte[] renderOutput(String formatted) {
        return ExcelEngine.createWorkbook(formatted);
    }
    
    @Override protected String getReportType() { return "Excel"; }
}
 
// Adding HTML reports: create new class, base class unchanged
public class HtmlReportGenerator extends ReportGenerator { /* ... */ }

When to Use Abstract Classes vs. Interfaces

Abstract Class vs. Interface for OCP
Use Abstract Class When	Use Interface When
Implementations share significant common code	Implementations vary completely
You want to enforce a workflow (Template Method)	You want maximum flexibility
There's meaningful default behavior	There are no sensible defaults
Extension is primarily through specialization	Extension is through substitution
Single inheritance is acceptable	Multiple roles are needed

Abstract Class Pitfall

Abstract classes create tighter coupling than interfaces. If the abstract class changes, all subclasses are affected. Use them for genuine 'is-a' relationships where shared structure is stable, not just to avoid code duplication.

Polymorphism as the Runtime Mechanism

Abstraction creates the structure for OCP. Polymorphism makes it work at runtime. Through polymorphism, client code can work with any implementation without knowing which specific implementation it's using:

PolymorphismForOCP.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
public interface Validator<T> {
    ValidationResult validate(T input);
}
 
// The validating service knows nothing about specific validators
public class ValidationService {
    private final List<Validator<?>> validators;
    
    public ValidationResult validateAll(Object input) {
        List<ValidationResult> results = new ArrayList<>();
        
        for (Validator<?> validator : validators) {
            // Polymorphic dispatch: each validator executes its own logic
            @SuppressWarnings("unchecked")
            Validator<Object> typedValidator = (Validator<Object>) validator;
            results.add(typedValidator.validate(input));
        }
        
        return ValidationResult.combine(results);
    }
}
 
// Polymorphism in action: same call, different behaviors
Validator<User> emailValidator = new EmailFormatValidator();
Validator<User> ageValidator = new MinimumAgeValidator(18);
Validator<User> duplicateValidator = new DuplicateUserValidator(userRepo);
Validator<User> customValidator = new CompanyPolicyValidator();  // Added later!
 
// The ValidationService handles all of these identically
// No switch statements, no type checking, no modification needed

The Polymorphism/OCP Connection

Polymorphism is essential for OCP because it allows:

Uniform treatment — Client code treats all implementations identically
Late binding — Specific behavior determined at runtime
Substitutability — Any implementation works in place of the abstraction
Extensibility — New implementations work with existing client code

Without polymorphism, abstraction would be merely documentation. Polymorphism makes it executable.

Polymorphism Eliminates Modification

•No type checks needed — The type system ensures correct dispatch
•No switch statements on type — Each implementation handles its own case
•No casting required — Work through the abstract type
•No conditional logic for variants — Polymorphic dispatch replaces conditionals

The Complete OCP Pattern

Let's synthesize everything into a complete OCP-compliant design pattern. This pattern has four components:

Abstraction — The interface or abstract class defining the contract
Implementations — Concrete classes satisfying the contract
Client — Code that uses the abstraction, not implementations
Composition Root — Where specific implementations are chosen and wired

CompleteOCPPattern.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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
// ================================
// COMPONENT 1: ABSTRACTION (Closed)
// ================================
public interface ShippingCalculator {
    Money calculateShipping(Order order);
    boolean supports(ShippingMethod method);
}
 
// ================================
// COMPONENT 2: IMPLEMENTATIONS (Open)
// ================================
public class StandardShipping implements ShippingCalculator {
    @Override
    public Money calculateShipping(Order order) {
        return order.getWeight().multiply(RATE_PER_KG);
    }
    
    @Override
    public boolean supports(ShippingMethod method) {
        return method == ShippingMethod.STANDARD;
    }
}
 
public class ExpressShipping implements ShippingCalculator {
    @Override
    public Money calculateShipping(Order order) {
        Money base = order.getWeight().multiply(EXPRESS_RATE);
        return base.add(EXPRESS_SURCHARGE);
    }
    
    @Override
    public boolean supports(ShippingMethod method) {
        return method == ShippingMethod.EXPRESS;
    }
}
 
// Added later without modifying anything:
public class DroneDelivery implements ShippingCalculator {
    @Override
    public Money calculateShipping(Order order) {
        return FLAT_DRONE_FEE.add(distanceCharge(order.getDestination()));
    }
    
    @Override
    public boolean supports(ShippingMethod method) {
        return method == ShippingMethod.DRONE;
    }
}
 
// ================================
// COMPONENT 3: CLIENT (Closed)
// ================================
public class OrderPricingService {
    private final List<ShippingCalculator> shippingCalculators;
    
    public OrderPricingService(List<ShippingCalculator> shippingCalculators) {
        this.shippingCalculators = shippingCalculators;
    }
    
    public OrderTotal calculateTotal(Order order) {
        Money subtotal = order.getItemsTotal();
        Money shipping = findCalculator(order.getShippingMethod())
            .calculateShipping(order);
        Money tax = taxService.calculateTax(subtotal);
        
        return new OrderTotal(subtotal, shipping, tax);
    }
    
    private ShippingCalculator findCalculator(ShippingMethod method) {
        return shippingCalculators.stream()
            .filter(calc -> calc.supports(method))
            .findFirst()
            .orElseThrow(() -> new UnsupportedShippingException(method));
    }
}
 
// ================================
// COMPONENT 4: COMPOSITION ROOT
// ================================
@Configuration
public class ShippingConfiguration {
    
    @Bean
    public List<ShippingCalculator> shippingCalculators() {
        return List.of(
            new StandardShipping(),
            new ExpressShipping(),
            new DroneDelivery()  // Just add to list for new methods
        );
    }
    
    @Bean
    public OrderPricingService orderPricingService(
            List<ShippingCalculator> calculators) {
        return new OrderPricingService(calculators);
    }
}

The Four Components

Abstraction + Implementations + Client + Composition Root = Complete OCP. The abstraction is closed. Implementations are open. The client is closed (depends on abstraction). Only the composition root changes when adding implementations—and that's configuration, not core logic.

Common OCP Design Patterns

Several classic design patterns are specifically designed to achieve OCP compliance:

Design Patterns for OCP
Pattern	OCP Mechanism	Use Case
Strategy	Inject different algorithms	Varying behaviors (sorting, pricing, validation)
Template Method	Override specific steps	Varying parts of fixed workflow
Decorator	Wrap to add behavior	Extending without modifying
Factory Method	Subclass determines instances	Varying object creation
Observer	Register new listeners	Reacting to events
Chain of Responsibility	Add handlers to chain	Processing pipelines
Visitor	Add operations to structures	Extending operations on fixed structures

Strategy Pattern Example

StrategyForOCP.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
// Strategy interface (closed)
public interface CompressionStrategy {
    byte[] compress(byte[] data);
    byte[] decompress(byte[] compressed);
    String getAlgorithmName();
}
 
// Context using strategy (closed)
public class FileArchiver {
    private final CompressionStrategy strategy;
    
    public FileArchiver(CompressionStrategy strategy) {
        this.strategy = strategy;
    }
    
    public void archiveFile(Path source, Path destination) {
        byte[] data = Files.readAllBytes(source);
        byte[] compressed = strategy.compress(data);  // Polymorphic
        Files.write(destination, compressed);
    }
}
 
// Strategies (open - add new ones freely)
public class ZipStrategy implements CompressionStrategy { /* ... */ }
public class GzipStrategy implements CompressionStrategy { /* ... */ }
public class Bzip2Strategy implements CompressionStrategy { /* ... */ }
public class ZstdStrategy implements CompressionStrategy { /* Added later! */ }

Decorator Pattern Example

DecoratorForOCP.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
34
35
36
37
38
39
40
41
42
43
44
// Base interface (closed)
public interface DataStream {
    byte[] read();
    void write(byte[] data);
}
 
// Core implementation (closed)
public class FileDataStream implements DataStream {
    public byte[] read() { /* read from file */ }
    public void write(byte[] data) { /* write to file */ }
}
 
// Decorators extend without modifying (open)
public class EncryptedDataStream implements DataStream {
    private final DataStream wrapped;
    private final Cipher cipher;
    
    public byte[] read() {
        return cipher.decrypt(wrapped.read());
    }
    
    public void write(byte[] data) {
        wrapped.write(cipher.encrypt(data));
    }
}
 
public class CompressedDataStream implements DataStream {
    private final DataStream wrapped;
    
    public byte[] read() {
        return decompress(wrapped.read());
    }
    
    public void write(byte[] data) {
        wrapped.write(compress(data));
    }
}
 
// Combine without modifying any existing class:
DataStream stream = new CompressedDataStream(
    new EncryptedDataStream(
        new FileDataStream("data.bin")
    )
);

The Resolution Complete

We've now seen how abstraction resolves the open/closed paradox. Let's summarize the complete picture:

Key Takeaways

•Abstraction creates a contract boundary — Separating what's stable (interface) from what varies (implementations).
•Interfaces define extension points — Behavioral contracts that any number of implementations can satisfy.
•Abstract classes share structure — Template methods define fixed workflows with varying steps.
•Polymorphism enables runtime flexibility — Same code, different behaviors based on which implementation is used.
•The four-component pattern — Abstraction + Implementations + Client + Composition Root = OCP compliance.
•Design patterns formalize OCP — Strategy, Decorator, Factory, and others codify OCP-compliant structures.

The Paradox Resolved

The open/closed paradox dissolves because abstraction creates two distinct zones:

Zone	Characteristic	OCP Role
Interface/Abstract Type	Stable, rarely changes	CLOSED
Implementations	Vary freely, grow over time	OPEN
Client Code	Depends on interface, immune to implementation changes	CLOSED
System Capabilities	Expand with new implementations	OPEN

There's no paradox because "open" and "closed" apply to different parts of the system. Abstraction is what separates these parts and makes them independently evolvable.

Module Complete

You've now mastered the dual nature of the Open/Closed Principle. You understand what 'open' means (extensibility through abstraction), what 'closed' means (stability of existing code), why they seem contradictory (different aspects of the same system), and how abstraction resolves the paradox (separating interface from implementation). This understanding is fundamental to designing systems that embrace change safely.

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

4 / 4

How Abstraction Resolves It — The Elegant Solution

The Power of Abstraction

Abstraction isn't just a programming technique—it's the fundamental mechanism that makes the Open/Closed Principle achievable. Through abstraction, we create systems where:

Interfaces remain frozen (closed)
Implementations multiply freely (open)
Clients depend only on stable interfaces (protected from change)
New behaviors emerge without touching existing code (evolution without surgery)

This page explores how abstraction achieves this seemingly impossible feat, transforming the OCP paradox from confusion into clarity.

What You Will Learn

The Abstraction Mechanism

Abstraction resolves the open/closed paradox by introducing a layer of indirection between clients and implementations. This layer has two critical properties:

It's stable — The interface/abstract type doesn't change
It's polymorphic — Multiple implementations can satisfy it

This combination is the key. Let's examine the mechanism:

AbstractionMechanism.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
// THE ABSTRACTION (stable, closed)
public interface MessageSender {
    void send(Message message, Recipient recipient);
}
 
// THE CLIENT (depends only on abstraction, therefore stable)
public class NotificationService {
    private final MessageSender sender;  // Abstract dependency
    
    public NotificationService(MessageSender sender) {
        this.sender = sender;
    }
    
    public void notifyUser(User user, String content) {
        Message msg = new Message(content);
        sender.send(msg, user.asRecipient());  // Polymorphic call
    }
}
 
// IMPLEMENTATIONS (vary freely, open)
public class EmailSender implements MessageSender { /* ... */ }
public class SmsSender implements MessageSender { /* ... */ }
public class PushNotificationSender implements MessageSender { /* ... */ }
public class SlackSender implements MessageSender { /* ... */ }  // Added later!
 
// THE RESOLUTION:
// - MessageSender interface: CLOSED (never modified)
// - NotificationService: CLOSED (never modified for new senders)
// - System capability: OPEN (new senders = new capabilities)
// - Existing code: UNCHANGED

Why This Works

The abstraction acts as a contract boundary:

Above the boundary (clients): Depend only on the contract. Protected from implementation changes.
Below the boundary (implementations): Can vary infinitely as long as they satisfy the contract.
At the boundary (interface): Stable, rarely changes. The "closed" part.
Beyond the boundary (new implementations): Can be added freely. The "open" part.

The boundary separates what's closed (contract, clients) from what's open (implementations, future additions).

The Inversion

Interfaces as Extension Points

Interfaces are the primary mechanism for achieving OCP. They define what without specifying how, creating natural extension points:

Interface Properties for OCP

•Behavioral contract — Specifies what operations must be supported
•Implementation freedom — Says nothing about how operations are performed
•Multiple implementations — Any number of classes can implement it
•Client protection — Clients depend on interface, not implementation
•Evolution without modification — New implementations don't change the interface

Designing Effective Interfaces for OCP

Not all interfaces create effective extension points. Well-designed interfaces for OCP have these characteristics:

EffectiveInterfaces.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
34
35
36
37
// ✅ GOOD: Cohesive, focused interface
public interface PriceCalculator {
    Money calculatePrice(Order order);
}
 
// Enables: StandardPriceCalculator, DiscountedPriceCalculator, 
//          WholesalePriceCalculator, DynamicPricingCalculator...
 
// ❌ BAD: Interface too broad, mixed concerns
public interface OrderService {
    Money calculatePrice(Order order);
    void saveOrder(Order order);
    void sendConfirmation(Order order);
    List<Order> findByCustomer(Customer customer);
}
 
// This interface couples calculation, persistence, notification, query
// Hard to implement one concern without others
// Changes to any concern affect the entire interface
 
// ✅ GOOD: Behavior-focused interface
public interface Authenticator {
    AuthenticationResult authenticate(Credentials credentials);
}
 
// Enables: PasswordAuthenticator, OAuthAuthenticator, 
//          BiometricAuthenticator, SsoAuthenticator, MfaAuthenticator...
 
// ❌ BAD: Data-focused interface (getter/setter collection)
public interface UserData {
    String getUsername();
    void setUsername(String username);
    String getEmail();
    void setEmail(String email);
    // This is a data structure, not an abstraction
    // No polymorphic variation is possible
}

Interface Design Principle

Design interfaces around behaviors, not data. Ask 'What does this do?' not 'What data does this have?' Behavioral interfaces enable polymorphic variation; data interfaces just describe structure.

Abstract Classes for Shared Structure

AbstractClassesForOCP.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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// Abstract class with Template Method pattern
public abstract class ReportGenerator {
    
    // CLOSED: Common workflow, never modified
    public final byte[] generateReport(ReportData data) {
        String content = buildContent(data);      // Varies
        String formatted = applyFormatting(content);  // Common
        byte[] output = renderOutput(formatted);  // Varies
        logGeneration(data);                      // Common
        return output;
    }
    
    // CLOSED: Common infrastructure
    private String applyFormatting(String content) {
        // Standard formatting applied to all reports
        return FormattingEngine.format(content);
    }
    
    private void logGeneration(ReportData data) {
        logger.info("Report generated: type={}, rows={}", 
            getReportType(), data.getRowCount());
    }
    
    // OPEN: Extension points for subclasses
    protected abstract String buildContent(ReportData data);
    protected abstract byte[] renderOutput(String formatted);
    protected abstract String getReportType();
}
 
// Extensions via subclassing - base class unchanged
public class PdfReportGenerator extends ReportGenerator {
    @Override protected String buildContent(ReportData data) {
        return new PdfContentBuilder().build(data);
    }
    
    @Override protected byte[] renderOutput(String formatted) {
        return PdfEngine.render(formatted);
    }
    
    @Override protected String getReportType() { return "PDF"; }
}
 
public class ExcelReportGenerator extends ReportGenerator {
    @Override protected String buildContent(ReportData data) {
        return new SpreadsheetBuilder().build(data);
    }
    
    @Override protected byte[] renderOutput(String formatted) {
        return ExcelEngine.createWorkbook(formatted);
    }
    
    @Override protected String getReportType() { return "Excel"; }
}
 
// Adding HTML reports: create new class, base class unchanged
public class HtmlReportGenerator extends ReportGenerator { /* ... */ }

When to Use Abstract Classes vs. Interfaces

Abstract Class vs. Interface for OCP
Use Abstract Class When	Use Interface When
Implementations share significant common code	Implementations vary completely
You want to enforce a workflow (Template Method)	You want maximum flexibility
There's meaningful default behavior	There are no sensible defaults
Extension is primarily through specialization	Extension is through substitution
Single inheritance is acceptable	Multiple roles are needed

Abstract Class Pitfall

Polymorphism as the Runtime Mechanism

PolymorphismForOCP.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
public interface Validator<T> {
    ValidationResult validate(T input);
}
 
// The validating service knows nothing about specific validators
public class ValidationService {
    private final List<Validator<?>> validators;
    
    public ValidationResult validateAll(Object input) {
        List<ValidationResult> results = new ArrayList<>();
        
        for (Validator<?> validator : validators) {
            // Polymorphic dispatch: each validator executes its own logic
            @SuppressWarnings("unchecked")
            Validator<Object> typedValidator = (Validator<Object>) validator;
            results.add(typedValidator.validate(input));
        }
        
        return ValidationResult.combine(results);
    }
}
 
// Polymorphism in action: same call, different behaviors
Validator<User> emailValidator = new EmailFormatValidator();
Validator<User> ageValidator = new MinimumAgeValidator(18);
Validator<User> duplicateValidator = new DuplicateUserValidator(userRepo);
Validator<User> customValidator = new CompanyPolicyValidator();  // Added later!
 
// The ValidationService handles all of these identically
// No switch statements, no type checking, no modification needed

The Polymorphism/OCP Connection

Polymorphism is essential for OCP because it allows:

Uniform treatment — Client code treats all implementations identically
Late binding — Specific behavior determined at runtime
Substitutability — Any implementation works in place of the abstraction
Extensibility — New implementations work with existing client code

Without polymorphism, abstraction would be merely documentation. Polymorphism makes it executable.

Polymorphism Eliminates Modification

•No type checks needed — The type system ensures correct dispatch
•No switch statements on type — Each implementation handles its own case
•No casting required — Work through the abstract type
•No conditional logic for variants — Polymorphic dispatch replaces conditionals

The Complete OCP Pattern

Let's synthesize everything into a complete OCP-compliant design pattern. This pattern has four components:

Abstraction — The interface or abstract class defining the contract
Implementations — Concrete classes satisfying the contract
Client — Code that uses the abstraction, not implementations
Composition Root — Where specific implementations are chosen and wired

CompleteOCPPattern.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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
// ================================
// COMPONENT 1: ABSTRACTION (Closed)
// ================================
public interface ShippingCalculator {
    Money calculateShipping(Order order);
    boolean supports(ShippingMethod method);
}
 
// ================================
// COMPONENT 2: IMPLEMENTATIONS (Open)
// ================================
public class StandardShipping implements ShippingCalculator {
    @Override
    public Money calculateShipping(Order order) {
        return order.getWeight().multiply(RATE_PER_KG);
    }
    
    @Override
    public boolean supports(ShippingMethod method) {
        return method == ShippingMethod.STANDARD;
    }
}
 
public class ExpressShipping implements ShippingCalculator {
    @Override
    public Money calculateShipping(Order order) {
        Money base = order.getWeight().multiply(EXPRESS_RATE);
        return base.add(EXPRESS_SURCHARGE);
    }
    
    @Override
    public boolean supports(ShippingMethod method) {
        return method == ShippingMethod.EXPRESS;
    }
}
 
// Added later without modifying anything:
public class DroneDelivery implements ShippingCalculator {
    @Override
    public Money calculateShipping(Order order) {
        return FLAT_DRONE_FEE.add(distanceCharge(order.getDestination()));
    }
    
    @Override
    public boolean supports(ShippingMethod method) {
        return method == ShippingMethod.DRONE;
    }
}
 
// ================================
// COMPONENT 3: CLIENT (Closed)
// ================================
public class OrderPricingService {
    private final List<ShippingCalculator> shippingCalculators;
    
    public OrderPricingService(List<ShippingCalculator> shippingCalculators) {
        this.shippingCalculators = shippingCalculators;
    }
    
    public OrderTotal calculateTotal(Order order) {
        Money subtotal = order.getItemsTotal();
        Money shipping = findCalculator(order.getShippingMethod())
            .calculateShipping(order);
        Money tax = taxService.calculateTax(subtotal);
        
        return new OrderTotal(subtotal, shipping, tax);
    }
    
    private ShippingCalculator findCalculator(ShippingMethod method) {
        return shippingCalculators.stream()
            .filter(calc -> calc.supports(method))
            .findFirst()
            .orElseThrow(() -> new UnsupportedShippingException(method));
    }
}
 
// ================================
// COMPONENT 4: COMPOSITION ROOT
// ================================
@Configuration
public class ShippingConfiguration {
    
    @Bean
    public List<ShippingCalculator> shippingCalculators() {
        return List.of(
            new StandardShipping(),
            new ExpressShipping(),
            new DroneDelivery()  // Just add to list for new methods
        );
    }
    
    @Bean
    public OrderPricingService orderPricingService(
            List<ShippingCalculator> calculators) {
        return new OrderPricingService(calculators);
    }
}

The Four Components

Common OCP Design Patterns

Several classic design patterns are specifically designed to achieve OCP compliance:

Design Patterns for OCP
Pattern	OCP Mechanism	Use Case
Strategy	Inject different algorithms	Varying behaviors (sorting, pricing, validation)
Template Method	Override specific steps	Varying parts of fixed workflow
Decorator	Wrap to add behavior	Extending without modifying
Factory Method	Subclass determines instances	Varying object creation
Observer	Register new listeners	Reacting to events
Chain of Responsibility	Add handlers to chain	Processing pipelines
Visitor	Add operations to structures	Extending operations on fixed structures

Strategy Pattern Example

StrategyForOCP.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
// Strategy interface (closed)
public interface CompressionStrategy {
    byte[] compress(byte[] data);
    byte[] decompress(byte[] compressed);
    String getAlgorithmName();
}
 
// Context using strategy (closed)
public class FileArchiver {
    private final CompressionStrategy strategy;
    
    public FileArchiver(CompressionStrategy strategy) {
        this.strategy = strategy;
    }
    
    public void archiveFile(Path source, Path destination) {
        byte[] data = Files.readAllBytes(source);
        byte[] compressed = strategy.compress(data);  // Polymorphic
        Files.write(destination, compressed);
    }
}
 
// Strategies (open - add new ones freely)
public class ZipStrategy implements CompressionStrategy { /* ... */ }
public class GzipStrategy implements CompressionStrategy { /* ... */ }
public class Bzip2Strategy implements CompressionStrategy { /* ... */ }
public class ZstdStrategy implements CompressionStrategy { /* Added later! */ }

Decorator Pattern Example

DecoratorForOCP.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
34
35
36
37
38
39
40
41
42
43
44
// Base interface (closed)
public interface DataStream {
    byte[] read();
    void write(byte[] data);
}
 
// Core implementation (closed)
public class FileDataStream implements DataStream {
    public byte[] read() { /* read from file */ }
    public void write(byte[] data) { /* write to file */ }
}
 
// Decorators extend without modifying (open)
public class EncryptedDataStream implements DataStream {
    private final DataStream wrapped;
    private final Cipher cipher;
    
    public byte[] read() {
        return cipher.decrypt(wrapped.read());
    }
    
    public void write(byte[] data) {
        wrapped.write(cipher.encrypt(data));
    }
}
 
public class CompressedDataStream implements DataStream {
    private final DataStream wrapped;
    
    public byte[] read() {
        return decompress(wrapped.read());
    }
    
    public void write(byte[] data) {
        wrapped.write(compress(data));
    }
}
 
// Combine without modifying any existing class:
DataStream stream = new CompressedDataStream(
    new EncryptedDataStream(
        new FileDataStream("data.bin")
    )
);

The Resolution Complete

We've now seen how abstraction resolves the open/closed paradox. Let's summarize the complete picture:

Key Takeaways

•Abstraction creates a contract boundary — Separating what's stable (interface) from what varies (implementations).
•Interfaces define extension points — Behavioral contracts that any number of implementations can satisfy.
•Abstract classes share structure — Template methods define fixed workflows with varying steps.
•Polymorphism enables runtime flexibility — Same code, different behaviors based on which implementation is used.
•The four-component pattern — Abstraction + Implementations + Client + Composition Root = OCP compliance.
•Design patterns formalize OCP — Strategy, Decorator, Factory, and others codify OCP-compliant structures.

The Paradox Resolved

The open/closed paradox dissolves because abstraction creates two distinct zones:

Zone	Characteristic	OCP Role
Interface/Abstract Type	Stable, rarely changes	CLOSED
Implementations	Vary freely, grow over time	OPEN
Client Code	Depends on interface, immune to implementation changes	CLOSED
System Capabilities	Expand with new implementations	OPEN

There's no paradox because "open" and "closed" apply to different parts of the system. Abstraction is what separates these parts and makes them independently evolvable.

Module Complete

4 / 4