Achieving OCP - Learning Module

Loading content...

0/246

Abstract Classes for Variation

Beyond Pure Contracts

Interfaces define contracts, but they don't share implementation. Every class implementing NotificationChannel must write its own validation logic, error handling, and retry mechanisms. When these aspects are identical across implementations, we face a dilemma: duplicate the code, or find another way.

Abstract classes solve this. They occupy the middle ground between pure interfaces (all contract, no implementation) and concrete classes (all implementation, no variation). Abstract classes provide a template with shared behavior and well-defined extension points where subclasses inject their specific logic.

This page explores how abstract classes achieve OCP differently from interfaces—not through pure substitutability, but through controlled template extension.

What You Will Learn

By the end of this page, you will understand when abstract classes are preferable to interfaces for OCP, how the Template Method pattern creates extension points, and how to design abstract classes that guide extension while preventing misuse.

The Case for Shared Implementation

Consider a data export system that supports multiple formats: CSV, JSON, XML, and Excel. Each exporter follows the same high-level workflow:

Validate the data
Transform data into format-specific representation
Write to output stream
Clean up resources

With a pure interface approach, each implementation must duplicate the validation, streaming infrastructure, and resource cleanup. Only step 2 truly varies.

Pure Interface Approach

•Each exporter duplicates validation logic
•Streaming and buffering code repeated
•Resource cleanup in every implementation
•Bug fixes must be applied to all exporters
•New implementations might miss important steps
•Inconsistent behavior across exporters likely

Abstract Class Approach

•Validation logic centralized in base class
•Streaming infrastructure inherited
•Resource cleanup guaranteed by template
•Bug fixes in one place propagate everywhere
•New implementations only override what varies
•Consistent behavior enforced by base class

DRY meets OCP:

Abstract classes allow you to keep code DRY (Don't Repeat Yourself) while maintaining OCP compliance. The shared implementation in the base class is closed for modification—it works the same for all exporters. The abstract methods create extension points where new exporters provide format-specific logic.

This is not a replacement for interfaces; it's a complement. Abstract classes and interfaces solve different problems, and sophisticated systems often use both together.

Interface + Abstract Class

A common pattern: define a pure interface for the contract, then provide an abstract base class implementing that interface with shared functionality. Clients program to the interface; implementations extend the abstract class. Best of both worlds.

Template Method: The Core OCP Pattern

The Template Method pattern is the primary mechanism by which abstract classes achieve OCP. It defines a skeleton algorithm in the base class, with certain steps delegated to abstract (or hook) methods that subclasses override.

Structure:

Template method — The public method defining the overall algorithm. Usually final (or equivalent) to prevent subclasses from changing the structure. This is the closed part.
Abstract methods — The customization points that subclasses must implement. This is the open part.
Hook methods — Optional customization points with default (often empty) implementations that subclasses may override.

DataExporter.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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
// Abstract base class defining the export template
public abstract class DataExporter {
    
    // TEMPLATE METHOD - defines the invariant algorithm structure
    // Marked final to prevent subclasses from breaking the workflow
    public final void export(List<Record> data, OutputStream output) {
        validateData(data);              // Shared implementation
        
        initializeExport(output);        // Hook - optional customization
        
        String formattedData = formatData(data);  // ABSTRACT - must vary
        
        writeToStream(formattedData, output);  // Shared implementation
        
        finalizeExport(output);          // Hook - optional customization
    }
    
    // Shared implementation - consistent across all exporters
    private void validateData(List<Record> data) {
        if (data == null || data.isEmpty()) {
            throw new IllegalArgumentException("Cannot export empty data");
        }
        
        for (Record record : data) {
            if (!record.isValid()) {
                throw new InvalidRecordException("Invalid record: " + record.getId());
            }
        }
    }
    
    // Shared implementation - buffered writing with proper handling
    private void writeToStream(String data, OutputStream output) {
        try (BufferedWriter writer = new BufferedWriter(
                new OutputStreamWriter(output, StandardCharsets.UTF_8))) {
            writer.write(data);
            writer.flush();
        } catch (IOException e) {
            throw new ExportException("Failed to write export data", e);
        }
    }
    
    // ABSTRACT METHOD - subclasses MUST provide format-specific logic
    protected abstract String formatData(List<Record> data);
    
    // HOOK METHODS - subclasses MAY override for customization
    protected void initializeExport(OutputStream output) {
        // Default: no initialization needed
    }
    
    protected void finalizeExport(OutputStream output) {
        // Default: no finalization needed
    }
}
 
// Concrete implementation - ONLY implements what varies
public class CsvExporter extends DataExporter {
    
    private final String delimiter;
    
    public CsvExporter(String delimiter) {
        this.delimiter = delimiter;
    }
    
    @Override
    protected String formatData(List<Record> data) {
        StringBuilder csv = new StringBuilder();
        
        // Header row
        csv.append(String.join(delimiter, data.get(0).getFieldNames()));
        csv.append("\n");
        
        // Data rows
        for (Record record : data) {
            csv.append(String.join(delimiter, record.getValues()));
            csv.append("\n");
        }
        
        return csv.toString();
    }
}
 
// Another concrete implementation - adds new format WITHOUT modifying base
public class JsonExporter extends DataExporter {
    
    private final ObjectMapper mapper = new ObjectMapper();
    private final boolean prettyPrint;
    
    public JsonExporter(boolean prettyPrint) {
        this.prettyPrint = prettyPrint;
    }
    
    @Override
    protected String formatData(List<Record> data) {
        try {
            if (prettyPrint) {
                return mapper.writerWithDefaultPrettyPrinter()
                    .writeValueAsString(data);
            }
            return mapper.writeValueAsString(data);
        } catch (JsonProcessingException e) {
            throw new ExportException("JSON formatting failed", e);
        }
    }
}
 
// Excel exporter uses hooks for format-specific setup/teardown
public class ExcelExporter extends DataExporter {
    
    private Workbook workbook;
    private Sheet sheet;
    
    @Override
    protected void initializeExport(OutputStream output) {
        // Hook: Excel needs workbook initialization
        workbook = new XSSFWorkbook();
        sheet = workbook.createSheet("Export");
    }
    
    @Override
    protected String formatData(List<Record> data) {
        int rowNum = 0;
        
        // Header
        Row headerRow = sheet.createRow(rowNum++);
        List<String> headers = data.get(0).getFieldNames();
        for (int i = 0; i < headers.size(); i++) {
            headerRow.createCell(i).setCellValue(headers.get(i));
        }
        
        // Data
        for (Record record : data) {
            Row row = sheet.createRow(rowNum++);
            List<String> values = record.getValues();
            for (int i = 0; i < values.size(); i++) {
                row.createCell(i).setCellValue(values.get(i));
            }
        }
        
        return ""; // Excel writes directly to workbook
    }
    
    @Override
    protected void finalizeExport(OutputStream output) {
        // Hook: Write workbook to output
        try {
            workbook.write(output);
            workbook.close();
        } catch (IOException e) {
            throw new ExportException("Excel write failed", e);
        }
    }
}

Analyzing the OCP achievement:

The algorithm structure is closed — The export() template method's sequence (validate → initialize → format → write → finalize) never changes. Adding XML or Parquet exporters doesn't alter this flow.
Format-specific behavior is open — Each new exporter only provides formatData() and optionally overrides hooks. No existing code is modified.
Consistency is enforced — All exporters validate data identically and handle streams consistently. A new developer can't accidentally skip validation.
Variation is constrained — Subclasses can only customize predetermined points. They can't, for example, change the order of operations or bypass validation.

Abstract Methods vs Hook Methods

Understanding the distinction between abstract methods and hooks is essential for designing effective abstract classes.

Abstract Methods (mandatory customization):

Subclasses must override them (compiler enforces this)
Represent essential variation that every implementation provides differently
The base class cannot function without subclass implementation

Hook Methods (optional customization):

Subclasses may override them
Have default implementations (often empty) that make sense for most cases
Allow specialized behavior without burdening simpler implementations

Abstract Methods vs Hook Methods
Characteristic	Abstract Method	Hook Method
Override requirement	Mandatory	Optional
Default implementation	None (abstract)	Provided (may be empty)
Use case	Core variation that differs across all implementations	Edge case customization needed by some implementations
Compiler enforcement	Yes - won't compile without override	No - uses default silently
Design signal	'You must tell me how to do this'	'You may customize this if needed'

Design guidance:

Start with abstract methods for what clearly must vary. Add hooks when you discover that some—but not all—implementations need to customize additional steps.

A common mistake is making too many methods abstract, burdening subclasses with boilerplate overrides that all look the same. If most implementations would provide the same logic, it should be a hook with that logic as the default, not an abstract method.

DocumentProcessor.java
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
public abstract class DocumentProcessor {
    
    public final ProcessingResult process(Document document) {
        // Hook: Pre-processing (most documents don't need this)
        Document prepared = prepareDocument(document);
        
        // Abstract: Core processing MUST be implemented
        ProcessedContent content = processContent(prepared);
        
        // Hook: Post-processing (some documents need validation)
        ProcessedContent validated = validateResult(content);
        
        // Hook: Metrics (most don't need custom metrics)
        recordMetrics(document, validated);
        
        return new ProcessingResult(validated);
    }
    
    // HOOK: Default is passthrough - override if pre-processing needed
    protected Document prepareDocument(Document document) {
        return document;
    }
    
    // ABSTRACT: Every processor type does this differently
    protected abstract ProcessedContent processContent(Document document);
    
    // HOOK: Default validation - override for stricter rules
    protected ProcessedContent validateResult(ProcessedContent content) {
        if (content == null || content.isEmpty()) {
            throw new ProcessingException("Processing produced no content");
        }
        return content;
    }
    
    // HOOK: Default metrics - override for custom tracking
    protected void recordMetrics(Document input, ProcessedContent output) {
        Metrics.record("documents_processed", 1);
    }
}
 
// Simple implementation: only overrides the abstract method
public class PlainTextProcessor extends DocumentProcessor {
    
    @Override
    protected ProcessedContent processContent(Document document) {
        return new ProcessedContent(document.getText());
    }
    // Uses default hooks - no pre-processing, standard validation, basic metrics
}
 
// Complex implementation: customizes multiple hooks
public class LegalDocumentProcessor extends DocumentProcessor {
    
    @Override
    protected Document prepareDocument(Document document) {
        // Legal docs need redaction before processing
        return RedactionService.redactSensitiveInfo(document);
    }
    
    @Override
    protected ProcessedContent processContent(Document document) {
        return LegalParser.extractClauses(document);
    }
    
    @Override
    protected ProcessedContent validateResult(ProcessedContent content) {
        ProcessedContent base = super.validateResult(content);
        
        // Additional legal-specific validation
        if (!LegalValidator.hasRequiredClauses(base)) {
            throw new LegalProcessingException("Missing required clauses");
        }
        return base;
    }
    
    @Override
    protected void recordMetrics(Document input, ProcessedContent output) {
        super.recordMetrics(input, output);
        Metrics.record("legal_documents_processed", 1);
        Metrics.record("clauses_extracted", output.getClauseCount());
    }
}

Hook Design Principle

Hooks should have sensible defaults. If you find yourself writing 'throw new UnsupportedOperationException()' as a default, it should probably be abstract. If most implementations provide identical logic, that logic should be the hook's default.

Designing for Safe Extension

Abstract classes create an inheritance relationship—arguably the tightest form of coupling in OOP. This power demands careful design to prevent subclasses from breaking the base class's guarantees.

The fragile base class problem:

Without discipline, subclasses can violate assumptions the base class relies on:

Override methods called by the template, breaking invariants
Forget to call super.method() when expected
Introduce state that conflicts with base class state
Change behavior in ways that surprise code using the base type

Principles for Safe Abstract Class Design

•Make template methods final — Prevent subclasses from altering the algorithm structure. The sequence of operations is the base class's responsibility.
•Minimize protected surface area — Only expose what subclasses genuinely need. Private methods and fields can be changed without affecting subclasses.
•Document extension contracts — Clearly state what overriding methods must/must not do, whether super should be called, and what invariants must be preserved.
•Prefer composition for optional features — If a behavior might not apply to all subclasses, consider passing it as a collaborator rather than adding hooks.
•Test subclass behavior explicitly — Base class tests should verify that subclasses can't break invariants through their extensions.

SafeAbstractClass.java
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
public abstract class BaseCacheManager {
    
    // PRIVATE state - subclasses cannot directly manipulate cache internals
    private final ConcurrentMap<String, CacheEntry> cache = new ConcurrentHashMap<>();
    private final AtomicLong hitCount = new AtomicLong();
    private final AtomicLong missCount = new AtomicLong();
    
    // FINAL template method - subclasses cannot change get/set flow
    public final Optional<Object> get(String key) {
        CacheEntry entry = cache.get(key);
        
        if (entry != null && !isExpired(entry)) {
            hitCount.incrementAndGet();
            onCacheHit(key, entry);  // Hook for subclass monitoring
            return Optional.of(entry.getValue());
        }
        
        missCount.incrementAndGet();
        
        // Abstract: subclasses control how to load missing values
        Optional<Object> loaded = loadValue(key);
        
        loaded.ifPresent(value -> {
            Duration ttl = determineTtl(key, value);  // Abstract: subclass sets TTL
            cache.put(key, new CacheEntry(value, Instant.now(), ttl));
        });
        
        onCacheMiss(key, loaded.isPresent());  // Hook for monitoring
        
        return loaded;
    }
    
    /**
     * Subclasses MUST implement: define how to load values not in cache.
     * 
     * Contract:
     * - Return Optional.empty() if value cannot be loaded
     * - Throw exception only for unrecoverable errors
     * - Result will be cached according to determineTtl()
     */
    protected abstract Optional<Object> loadValue(String key);
    
    /**
     * Subclasses MUST implement: define how long cached values remain valid.
     * 
     * Contract:
     * - Return Duration.ZERO for no caching
     * - Value and key available for dynamic TTL decisions
     */
    protected abstract Duration determineTtl(String key, Object value);
    
    // HOOKs - default implementations, override for custom monitoring
    protected void onCacheHit(String key, CacheEntry entry) {
        // Default: no-op
    }
    
    protected void onCacheMiss(String key, boolean loaded) {
        // Default: no-op
    }
    
    // PRIVATE - expiration logic is NOT extensible
    private boolean isExpired(CacheEntry entry) {
        if (entry.getTtl().isZero()) {
            return false;  // Zero TTL means never expire
        }
        return entry.getCreatedAt().plus(entry.getTtl()).isBefore(Instant.now());
    }
    
    // PUBLIC utility methods - read-only access to metrics
    public final long getHitCount() { return hitCount.get(); }
    public final long getMissCount() { return missCount.get(); }
}

Safety guarantees in this design:

Cache data structure is private — subclasses can't corrupt cache state
Core get() method is final — the hit/miss/load pattern is invariant
Expiration logic is private — subclasses can't bypass TTL enforcement
Abstract methods have documented contracts — expectations are explicit
Hooks are truly optional — forgetting to override them doesn't break caching

This is defensive design: assume subclass authors will make mistakes (or attempt shortcuts) and structure the base class to prevent violations of its core guarantees.

When Abstract Classes Beat Interfaces

Both abstract classes and interfaces enable OCP, but they excel in different scenarios. Choose based on what you're trying to achieve.

Abstract Classes vs Interfaces for OCP
Factor	Abstract Class	Interface
Implementation sharing	✅ Excellent - shared code in base class	❌ Limited - default methods only (and can't share state)
Multiple inheritance	❌ Single inheritance only	✅ Multiple interface implementation
Enforcing algorithm structure	✅ Template methods prevent structural changes	❌ Cannot enforce how implementations work internally
Controlled extension points	✅ Abstract + hooks define exactly where variation occurs	❌ All methods are extension points
State management	✅ Can define and protect base state	❌ Interfaces cannot have instance state
Pure substitutability	⚠️ Tied to inheritance hierarchy	✅ Any implementing class substitutable
Evolution flexibility	⚠️ Adding abstract methods breaks subclasses	⚠️ Adding methods breaks implementations (without defaults)

Use abstract classes when:

There's significant shared implementation — If multiple implementations share substantial code, abstract classes prevent duplication.
The algorithm structure must be invariant — When you need to guarantee a sequence of operations that subclasses can customize but not rearrange.
You need to manage shared state — Base class state that should be consistent across all implementations.
You want to constrain variation — Limiting where customization can occur prevents misuse and ensures correctness.

Use interfaces when:

Pure contracts without implementation — When you only care what behavior exists, not how.
Multiple inheritance is needed — Classes that fit multiple roles should implement multiple interfaces.
Maximum flexibility for implementers — When you want any class (regardless of existing hierarchy) to participate.
Decoupling is paramount — Interfaces create looser coupling than inheritance.

The Hybrid Approach

Often the best design combines both: an interface defines the public contract, and an abstract class provides a convenient base implementation. Clients depend on the interface; concrete classes extend the abstract class. This maximizes flexibility while minimizing code duplication.

Real-World Abstract Class Patterns

Abstract classes for OCP appear throughout well-designed frameworks and libraries. Understanding these patterns helps you recognize when to apply similar techniques.

HttpServlet (Java Servlets) is a classic Template Method example. It handles HTTP protocol mechanics while leaving request handling to subclasses.

The service() method dispatches to doGet(), doPost(), etc. based on HTTP method. Subclasses override specific handlers without touching request parsing, header management, or response stream handling.

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
public abstract class HttpServlet {
    
    // Template method handling HTTP dispatch
    protected void service(HttpServletRequest req, HttpServletResponse resp) {
        String method = req.getMethod();
        
        if ("GET".equals(method)) {
            doGet(req, resp);
        } else if ("POST".equals(method)) {
            doPost(req, resp);
        } else if ("PUT".equals(method)) {
            doPut(req, resp);
        }
        // ... other methods
    }
    
    // Hook methods with default "not supported" behavior
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
        resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
    }
    
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) {
        resp.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
    }
}
 
// Your servlet only overrides what it handles
public class UserServlet extends HttpServlet {
    
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
        // Get user by ID
    }
    
    @Override  
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) {
        // Create new user
    }
    // PUT, DELETE etc use default "not allowed" behavior
}

Summary: Abstract Classes as OCP Enablers

We've explored how abstract classes achieve the Open/Closed Principle through a different mechanism than interfaces: shared implementation with controlled extension points.

Key Takeaways

•Abstract classes enable DRY + OCP — Shared implementation in base class + extension via abstract/hook methods.
•Template Method is the core pattern — Define invariant algorithm structure; delegate variable steps to subclasses.
•Abstract methods = mandatory variation — Subclasses must implement. Hook methods = optional customization — Subclasses may override.
•Design defensively — Use final template methods, private state, and documented contracts to prevent subclass misuse.
•Choose based on needs — Abstract classes for shared implementation and algorithm enforcement; interfaces for pure contracts and flexibility.
•Combine both approaches — Interface for contract + abstract class for base implementation is often optimal.

What's next:

We've seen extension through interfaces and abstract classes within a single codebase. The next page explores Plugin Architectures—how to achieve OCP across system boundaries, enabling completely independent code to extend your system without any integration during development.

Page Complete

You now understand how abstract classes complement interfaces in achieving OCP. Template methods, abstract methods, and hooks create structured extension points that share implementation while remaining open to new variations.