Strategy Pattern & OCP - Learning Module

Loading content...

0/246

OCP Through Composition

Composing Extensible Systems

The Strategy Pattern achieves OCP by allowing behavioral variation through interchangeable algorithms. But OCP has another powerful manifestation: achieving extension through composition—assembling objects from smaller, focused pieces that can be combined in new ways without modifying existing components.

Composition-based OCP doesn't just swap behaviors; it layers, wraps, and combines behaviors. A logging decorator wraps a strategy to add logging without changing either the strategy or callers. A composite strategy combines multiple strategies into one. A chain of responsibility routes requests through a pipeline of handlers.

This page explores how composition patterns achieve OCP. You'll learn when composition offers advantages over pure strategy swapping, how to design composable components, and how to recognize composition opportunities in your own systems.

What You Will Learn

By the end of this page, you will understand the Decorator pattern as an OCP mechanism, master composite and chain patterns for extensibility, know when to use composition versus simple strategy swapping, and design systems that leverage composition for maximum flexibility.

The Decorator Pattern — Adding Behavior Without Modification

The Decorator pattern enables OCP by wrapping objects to add new behavior while preserving the original interface. Unlike Strategy (which replaces behavior), Decorator enhances behavior—adding responsibilities before, after, or around the core operation.

The Decorator Structure:

Component Interface — The contract both the original object and decorators implement
Concrete Component — The core object providing base functionality
Decorator Base — Abstract decorator implementing the interface and holding a wrapped component
Concrete Decorators — Specific decorators adding particular behaviors

Key Insight: Because decorators and components share the same interface, decorators can wrap other decorators. This creates composable layers of functionality.

decorator-ocp-example.ts
TypeScript
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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
// DECORATOR PATTERN for OCP
 
// The shared interface - both components and decorators implement this
interface DataProcessor {
    process(data: RawData): Promise<ProcessedData>;
    getName(): string;
}
 
// Concrete component - core processing logic
class JsonDataProcessor implements DataProcessor {
    async process(data: RawData): Promise<ProcessedData> {
        const parsed = JSON.parse(data.content);
        return {
            payload: parsed,
            format: 'json',
            processedAt: new Date()
        };
    }
    
    getName(): string {
        return 'JsonProcessor';
    }
}
 
// Abstract decorator base
abstract class DataProcessorDecorator implements DataProcessor {
    protected readonly wrapped: DataProcessor;
    
    constructor(wrapped: DataProcessor) {
        this.wrapped = wrapped;
    }
    
    // Default: delegate to wrapped processor
    async process(data: RawData): Promise<ProcessedData> {
        return this.wrapped.process(data);
    }
    
    getName(): string {
        return `${this.getDecoratorName()}(${this.wrapped.getName()})`;
    }
    
    protected abstract getDecoratorName(): string;
}
 
// Concrete decorators - each adds specific functionality
 
class ValidationDecorator extends DataProcessorDecorator {
    constructor(
        wrapped: DataProcessor,
        private readonly schema: ValidationSchema
    ) {
        super(wrapped);
    }
    
    async process(data: RawData): Promise<ProcessedData> {
        // PRE-processing: validate first
        const validation = await this.schema.validate(data);
        if (!validation.isValid) {
            throw new ValidationError(validation.errors);
        }
        
        // Delegate to wrapped processor
        return this.wrapped.process(data);
    }
    
    protected getDecoratorName(): string {
        return 'Validated';
    }
}
 
class LoggingDecorator extends DataProcessorDecorator {
    constructor(
        wrapped: DataProcessor,
        private readonly logger: Logger
    ) {
        super(wrapped);
    }
    
    async process(data: RawData): Promise<ProcessedData> {
        const startTime = Date.now();
        this.logger.info('Processing started', { 
            processor: this.getName(),
            dataSize: data.content.length 
        });
        
        try {
            // Delegate to wrapped processor
            const result = await this.wrapped.process(data);
            
            this.logger.info('Processing completed', {
                processor: this.getName(),
                durationMs: Date.now() - startTime,
                success: true
            });
            
            return result;
            
        } catch (error) {
            this.logger.error('Processing failed', {
                processor: this.getName(),
                durationMs: Date.now() - startTime,
                error: error.message
            });
            throw error;
        }
    }
    
    protected getDecoratorName(): string {
        return 'Logged';
    }
}
 
class CachingDecorator extends DataProcessorDecorator {
    constructor(
        wrapped: DataProcessor,
        private readonly cache: Cache,
        private readonly ttlMs: number = 3600000
    ) {
        super(wrapped);
    }
    
    async process(data: RawData): Promise<ProcessedData> {
        const cacheKey = this.generateCacheKey(data);
        
        // Check cache first
        const cached = await this.cache.get<ProcessedData>(cacheKey);
        if (cached) {
            return { ...cached, fromCache: true };
        }
        
        // Process and cache result
        const result = await this.wrapped.process(data);
        await this.cache.set(cacheKey, result, this.ttlMs);
        
        return { ...result, fromCache: false };
    }
    
    private generateCacheKey(data: RawData): string {
        return `processor:${crypto.createHash('md5')
            .update(data.content)
            .digest('hex')}`;
    }
    
    protected getDecoratorName(): string {
        return 'Cached';
    }
}
 
class RetryDecorator extends DataProcessorDecorator {
    constructor(
        wrapped: DataProcessor,
        private readonly maxRetries: number = 3,
        private readonly backoffMs: number = 1000
    ) {
        super(wrapped);
    }
    
    async process(data: RawData): Promise<ProcessedData> {
        let lastError: Error;
        
        for (let attempt = 1; attempt <= this.maxRetries; attempt++) {
            try {
                return await this.wrapped.process(data);
            } catch (error) {
                lastError = error;
                
                if (attempt < this.maxRetries) {
                    await this.sleep(this.backoffMs * attempt);
                }
            }
        }
        
        throw lastError!;
    }
    
    private sleep(ms: number): Promise<void> {
        return new Promise(resolve => setTimeout(resolve, ms));
    }
    
    protected getDecoratorName(): string {
        return `Retry(${this.maxRetries})`;
    }
}
 
// COMPOSING DECORATORS - layered functionality
function createProductionProcessor(
    logger: Logger,
    cache: Cache,
    schema: ValidationSchema
): DataProcessor {
    // Start with core processor
    let processor: DataProcessor = new JsonDataProcessor();
    
    // Layer on decorators (order matters!)
    processor = new ValidationDecorator(processor, schema);  // Validate first
    processor = new RetryDecorator(processor, 3);            // Retry on failure
    processor = new CachingDecorator(processor, cache);      // Cache results
    processor = new LoggingDecorator(processor, logger);     // Log everything
    
    // Result: Logged(Cached(Retry(Validated(JsonProcessor))))
    console.log(processor.getName());
    
    return processor;
}
 
// ADDING NEW BEHAVIOR - OCP demonstration
// To add metrics collection, we create a new decorator (no modifications)
 
class MetricsDecorator extends DataProcessorDecorator {
    constructor(
        wrapped: DataProcessor,
        private readonly metrics: MetricsCollector
    ) {
        super(wrapped);
    }
    
    async process(data: RawData): Promise<ProcessedData> {
        const tags = { processor: this.wrapped.getName() };
        
        this.metrics.increment('processor.invocations', tags);
        const timer = this.metrics.startTimer('processor.duration', tags);
        
        try {
            const result = await this.wrapped.process(data);
            this.metrics.increment('processor.success', tags);
            return result;
        } catch (error) {
            this.metrics.increment('processor.failure', tags);
            throw error;
        } finally {
            timer.stop();
        }
    }
    
    protected getDecoratorName(): string {
        return 'Metered';
    }
}
 
// Added to pipeline without modifying existing decorators
function createMonitoredProcessor(...): DataProcessor {
    let processor = createProductionProcessor(...);
    processor = new MetricsDecorator(processor, metrics);  // New capability
    return processor;
}

Decorator Order Matters

The order of decorators affects behavior. LoggingDecorator on the outside logs total time including cache lookups. If logging wraps the raw processor, it only logs actual processing. Think carefully about what you want each decorator to observe.

Strategy vs Decorator — Choosing the Right Tool

Both Strategy and Decorator achieve OCP, but they serve different purposes. Understanding when to use each is crucial for effective design.

Strategy: Behavioral Substitution

Purpose: Choose ONE algorithm from alternatives
Structure: Context holds A strategy, can swap it
Extension: Add new algorithm implementations
Example: Different payment methods (use PayPal OR credit card)

Decorator: Behavioral Layering

Purpose: Add capabilities to existing behavior
Structure: Decorators wrap and enhance
Extension: Add new decorators for new capabilities
Example: Add logging, caching, metrics to ANY processor

Use Strategy When

•Behaviors are mutually exclusive
•One algorithm replaces another entirely
•You need runtime algorithm selection
•Algorithms differ fundamentally in approach
•The 'WHAT' changes (e.g., sorting method)

Use Decorator When

•Behaviors can be combined/stacked
•Adding orthogonal concerns (logging, auth)
•You want selective, optional features
•Features apply to multiple core behaviors
•The 'HOW' gets enhanced (add logging to anything)

Combining Strategy and Decorator:

Strategies and decorators work beautifully together. Decorators can wrap ANY strategy, applying cross-cutting concerns uniformly:

strategy-decorator-combination.ts
TypeScript
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
// COMBINING STRATEGY AND DECORATOR
 
interface NotificationStrategy {
    send(notification: Notification): Promise<SendResult>;
}
 
// Concrete strategies (behavioral alternatives)
class EmailStrategy implements NotificationStrategy { ... }
class SmsStrategy implements NotificationStrategy { ... }
class PushStrategy implements NotificationStrategy { ... }
 
// Decorators (apply to ANY strategy)
class RateLimitedDecorator implements NotificationStrategy {
    constructor(
        private readonly wrapped: NotificationStrategy,
        private readonly rateLimiter: RateLimiter
    ) {}
    
    async send(notification: Notification): Promise<SendResult> {
        await this.rateLimiter.acquire(notification.recipientId);
        return this.wrapped.send(notification);
    }
}
 
class AuditedDecorator implements NotificationStrategy {
    constructor(
        private readonly wrapped: NotificationStrategy,
        private readonly auditLog: AuditLog
    ) {}
    
    async send(notification: Notification): Promise<SendResult> {
        const result = await this.wrapped.send(notification);
        
        await this.auditLog.record({
            action: 'notification_sent',
            recipientId: notification.recipientId,
            channel: this.wrapped.constructor.name,
            success: result.success
        });
        
        return result;
    }
}
 
// Factory creates decorated strategies
class NotificationStrategyFactory {
    constructor(
        private readonly rateLimiter: RateLimiter,
        private readonly auditLog: AuditLog
    ) {}
    
    createStrategy(channel: string): NotificationStrategy {
        // Select core strategy
        let strategy: NotificationStrategy;
        switch (channel) {
            case 'email': strategy = new EmailStrategy(); break;
            case 'sms': strategy = new SmsStrategy(); break;
            case 'push': strategy = new PushStrategy(); break;
            default: throw new Error(`Unknown channel: ${channel}`);
        }
        
        // Apply universal decorators to ALL strategies
        strategy = new RateLimitedDecorator(strategy, this.rateLimiter);
        strategy = new AuditedDecorator(strategy, this.auditLog);
        
        return strategy;
    }
}
 
// Result: Every channel gets rate limiting and auditing
// Adding a new channel (Slack) doesn't require changing decorators
// Adding a new decorator (encryption) doesn't require changing strategies

Composite Strategy Pattern

The Composite pattern enables treating a group of strategies as a single strategy. This is powerful for scenarios where operations should apply to multiple targets, or results from multiple sources should be combined.

Composite Use Cases:

Fan-out — Send notification via email AND SMS AND push
Aggregation — Combine results from multiple search engines
Fallback Chains — Try strategy A, if it fails try B, then C
Voting — Multiple classifiers vote on a decision

composite-strategy.ts
TypeScript
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
// COMPOSITE STRATEGY PATTERN
 
interface ShippingRateStrategy {
    calculateRate(package: Package): Promise<ShippingRate>;
    getCarrierName(): string;
}
 
class FedExRateStrategy implements ShippingRateStrategy {
    constructor(private readonly fedexApi: FedExApi) {}
    
    async calculateRate(pkg: Package): Promise<ShippingRate> {
        const quote = await this.fedexApi.getRates(pkg);
        return ShippingRate.from(quote);
    }
    
    getCarrierName(): string { return 'FedEx'; }
}
 
class UPSRateStrategy implements ShippingRateStrategy {
    constructor(private readonly upsApi: UPSApi) {}
    
    async calculateRate(pkg: Package): Promise<ShippingRate> {
        const quote = await this.upsApi.fetchRates(pkg);
        return ShippingRate.from(quote);
    }
    
    getCarrierName(): string { return 'UPS'; }
}
 
class USPSRateStrategy implements ShippingRateStrategy {
    constructor(private readonly uspsApi: USPSApi) {}
    
    async calculateRate(pkg: Package): Promise<ShippingRate> {
        const quote = await this.uspsApi.calculatePostage(pkg);
        return ShippingRate.from(quote);
    }
    
    getCarrierName(): string { return 'USPS'; }
}
 
// COMPOSITE 1: Aggregate all carrier rates
class AllCarriersRateStrategy implements ShippingRateStrategy {
    constructor(private readonly strategies: ShippingRateStrategy[]) {}
    
    async calculateRate(pkg: Package): Promise<ShippingRate> {
        // Query all carriers in parallel
        const rates = await Promise.all(
            this.strategies.map(s => 
                s.calculateRate(pkg)
                    .then(rate => ({ carrier: s.getCarrierName(), rate }))
                    .catch(err => ({ carrier: s.getCarrierName(), error: err }))
            )
        );
        
        // Return composite result with all options
        const successful = rates.filter(r => r.rate);
        return ShippingRate.composite({
            options: successful.map(r => ({ 
                carrier: r.carrier, 
                rate: r.rate! 
            })),
            cheapest: successful.reduce((min, r) => 
                r.rate!.amount < min.rate!.amount ? r : min
            )
        });
    }
    
    getCarrierName(): string { return 'All Carriers'; }
}
 
// COMPOSITE 2: Best rate with fallback
class CheapestRateStrategy implements ShippingRateStrategy {
    constructor(private readonly strategies: ShippingRateStrategy[]) {}
    
    async calculateRate(pkg: Package): Promise<ShippingRate> {
        const results = await Promise.allSettled(
            this.strategies.map(s => s.calculateRate(pkg))
        );
        
        const successful = results
            .filter((r): r is PromiseFulfilledResult<ShippingRate> => 
                r.status === 'fulfilled'
            )
            .map(r => r.value);
        
        if (successful.length === 0) {
            throw new NoRatesAvailableError('All carriers failed');
        }
        
        // Return cheapest
        return successful.reduce((min, rate) => 
            rate.amount < min.amount ? rate : min
        );
    }
    
    getCarrierName(): string { return 'Best Rate'; }
}
 
// COMPOSITE 3: Fallback chain (try carriers in order until success)
class FallbackRateStrategy implements ShippingRateStrategy {
    constructor(private readonly strategies: ShippingRateStrategy[]) {}
    
    async calculateRate(pkg: Package): Promise<ShippingRate> {
        for (const strategy of this.strategies) {
            try {
                return await strategy.calculateRate(pkg);
            } catch (error) {
                console.warn(`${strategy.getCarrierName()} failed, trying next`);
                continue;
            }
        }
        throw new NoRatesAvailableError('All carriers failed');
    }
    
    getCarrierName(): string { return 'Fallback Chain'; }
}
 
// USAGE: Composites are strategies themselves
// OCP: Adding DHL requires only new DhlRateStrategy + adding to composite
 
const allCarriers = new AllCarriersRateStrategy([
    new FedExRateStrategy(fedexApi),
    new UPSRateStrategy(upsApi),
    new USPSRateStrategy(uspsApi)
]);
 
// Consumer code doesn't know it's using a composite
// It just sees a ShippingRateStrategy
const shippingService = new ShippingService(allCarriers);
const rates = await shippingService.getRatesForPackage(pkg);

Composites Are Transparent

The key to Composite pattern is that consumers can't distinguish between a single strategy and a composite. ShippingService receives a ShippingRateStrategy—whether that queries one carrier or ten is invisible. This enables powerful composition without consumer complexity.

Chain of Responsibility — Sequential Extension

The Chain of Responsibility pattern achieves OCP by creating a pipeline where handlers can be added or removed without modifying existing handlers or the client. Each handler decides whether to process a request or pass it to the next handler.

Classic Chain vs Middleware Chain:

Classic Chain: Handler either handles the request OR passes it on
Middleware Chain: Handler can process, modify, and still pass on (pre/post processing)

Both patterns achieve OCP—new handlers are added without modifying existing ones.

chain-of-responsibility.ts
TypeScript
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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
// CHAIN OF RESPONSIBILITY for OCP
 
// Handler interface
interface RequestHandler {
    setNext(handler: RequestHandler): RequestHandler;
    handle(request: Request): Promise<Response | null>;
}
 
// Abstract base handler with chain logic
abstract class BaseHandler implements RequestHandler {
    private nextHandler: RequestHandler | null = null;
    
    setNext(handler: RequestHandler): RequestHandler {
        this.nextHandler = handler;
        return handler;  // Enables fluent chaining
    }
    
    async handle(request: Request): Promise<Response | null> {
        // Try to handle in this handler
        const result = await this.process(request);
        
        if (result) {
            return result;  // Handled - don't pass on
        }
        
        // Pass to next handler if exists
        if (this.nextHandler) {
            return this.nextHandler.handle(request);
        }
        
        return null;  // No handler handled it
    }
    
    // Subclasses implement specific handling logic
    protected abstract process(request: Request): Promise<Response | null>;
}
 
// Concrete handlers
 
class AuthenticationHandler extends BaseHandler {
    constructor(private readonly authService: AuthService) {
        super();
    }
    
    protected async process(request: Request): Promise<Response | null> {
        // Authentication applies to all requests - modify request, then pass on
        const authHeader = request.headers.authorization;
        
        if (!authHeader) {
            return Response.unauthorized('Missing authorization header');
        }
        
        try {
            const user = await this.authService.validateToken(authHeader);
            request.user = user;  // Attach user to request
            return null;  // Pass to next handler
        } catch (error) {
            return Response.unauthorized('Invalid token');
        }
    }
}
 
class RateLimitHandler extends BaseHandler {
    constructor(private readonly rateLimiter: RateLimiter) {
        super();
    }
    
    protected async process(request: Request): Promise<Response | null> {
        const key = request.user?.id ?? request.ip;
        const allowed = await this.rateLimiter.checkLimit(key);
        
        if (!allowed) {
            return Response.tooManyRequests('Rate limit exceeded');
        }
        
        return null;  // Pass to next handler
    }
}
 
class CacheHandler extends BaseHandler {
    constructor(private readonly cache: Cache) {
        super();
    }
    
    protected async process(request: Request): Promise<Response | null> {
        if (request.method !== 'GET') {
            return null;  // Only cache GETs
        }
        
        const cached = await this.cache.get(request.url);
        
        if (cached) {
            return Response.ok(cached, { 'X-Cache': 'HIT' });
        }
        
        return null;  // Cache miss - pass to next handler
    }
}
 
class RoutingHandler extends BaseHandler {
    constructor(private readonly router: Router) {
        super();
    }
    
    protected async process(request: Request): Promise<Response | null> {
        const handler = this.router.match(request.method, request.url);
        
        if (handler) {
            return handler(request);
        }
        
        return Response.notFound('No route matched');
    }
}
 
// BUILDING THE CHAIN
class PipelineBuilder {
    private handlers: RequestHandler[] = [];
    
    use(handler: RequestHandler): this {
        this.handlers.push(handler);
        return this;
    }
    
    build(): RequestHandler {
        if (this.handlers.length === 0) {
            throw new Error('Pipeline must have at least one handler');
        }
        
        // Chain handlers together
        for (let i = 0; i < this.handlers.length - 1; i++) {
            this.handlers[i].setNext(this.handlers[i + 1]);
        }
        
        return this.handlers[0];  // Return head of chain
    }
}
 
// USAGE: Building extensible request pipeline
const pipeline = new PipelineBuilder()
    .use(new AuthenticationHandler(authService))
    .use(new RateLimitHandler(rateLimiter))
    .use(new CacheHandler(cache))
    .use(new RoutingHandler(router))
    .build();
 
// Process requests through pipeline
app.on('request', async (request) => {
    const response = await pipeline.handle(request);
    return response ?? Response.internalError('Unhandled request');
});
 
// OCP: Adding input validation requires only new handler
class ValidationHandler extends BaseHandler {
    constructor(private readonly validator: RequestValidator) {
        super();
    }
    
    protected async process(request: Request): Promise<Response | null> {
        const validation = await this.validator.validate(request);
        
        if (!validation.isValid) {
            return Response.badRequest(validation.errors);
        }
        
        return null;  // Valid - pass to next handler
    }
}
 
// Add to pipeline without modifying existing handlers
const extendedPipeline = new PipelineBuilder()
    .use(new AuthenticationHandler(authService))
    .use(new RateLimitHandler(rateLimiter))
    .use(new ValidationHandler(validator))     // NEW!
    .use(new CacheHandler(cache))
    .use(new RoutingHandler(router))
    .build();

Middleware Is Chain of Responsibility

If you've used Express.js middleware, Koa, or similar frameworks, you've used Chain of Responsibility. Each middleware can terminate the chain (send response) or pass to next. This is why adding middleware never requires modifying existing middleware—pure OCP.

Composition for Cross-Cutting Concerns

Cross-cutting concerns—logging, security, transactions, caching—affect many parts of a system but shouldn't be embedded in business logic. Composition patterns apply these concerns uniformly without modifying business code.

Why Cross-Cutting Concerns Need Composition:

Separation of Concerns — Business logic shouldn't know about logging infrastructure
Consistency — Same logging format everywhere, enforced structurally
Flexibility — Change logging behavior system-wide by changing one decorator
Testing — Test business logic without logging, caching, etc.

cross-cutting-composition.ts
TypeScript
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
// COMPOSITION for Cross-Cutting Concerns
 
// Generic decorator that applies to any interface with async methods
function withLogging<T extends object>(
    target: T,
    logger: Logger,
    options: LoggingOptions = {}
): T {
    return new Proxy(target, {
        get(obj, prop) {
            const value = obj[prop as keyof T];
            
            if (typeof value !== 'function') {
                return value;
            }
            
            // Wrap method with logging
            return async function(...args: unknown[]) {
                const methodName = String(prop);
                const startTime = Date.now();
                
                if (options.logArgs) {
                    logger.debug(`${methodName} called`, { args });
                } else {
                    logger.debug(`${methodName} called`);
                }
                
                try {
                    const result = await value.apply(obj, args);
                    
                    logger.debug(`${methodName} completed`, {
                        durationMs: Date.now() - startTime
                    });
                    
                    return result;
                    
                } catch (error) {
                    logger.error(`${methodName} failed`, {
                        durationMs: Date.now() - startTime,
                        error: error.message
                    });
                    throw error;
                }
            };
        }
    });
}
 
// Transaction decorator
function withTransaction<T extends object>(
    target: T,
    transactionManager: TransactionManager
): T {
    return new Proxy(target, {
        get(obj, prop) {
            const value = obj[prop as keyof T];
            
            if (typeof value !== 'function') {
                return value;
            }
            
            return async function(...args: unknown[]) {
                return transactionManager.runInTransaction(async () => {
                    return value.apply(obj, args);
                });
            };
        }
    });
}
 
// Circuit breaker decorator
function withCircuitBreaker<T extends object>(
    target: T,
    breaker: CircuitBreaker
): T {
    return new Proxy(target, {
        get(obj, prop) {
            const value = obj[prop as keyof T];
            
            if (typeof value !== 'function') {
                return value;
            }
            
            return async function(...args: unknown[]) {
                return breaker.execute(() => value.apply(obj, args));
            };
        }
    });
}
 
// USAGE: Apply cross-cutting concerns to any service
 
class OrderService {
    async createOrder(items: Item[], customer: Customer): Promise<Order> {
        // Pure business logic - no logging, no transactions
        const order = new Order(items, customer);
        order.calculateTotals();
        await this.orderRepository.save(order);
        await this.inventoryService.reserve(items);
        return order;
    }
    
    async cancelOrder(orderId: string): Promise<void> {
        const order = await this.orderRepository.findById(orderId);
        order.cancel();
        await this.orderRepository.save(order);
        await this.inventoryService.release(order.items);
    }
}
 
// Compose with cross-cutting concerns
function createOrderService(
    repository: OrderRepository,
    inventory: InventoryService,
    logger: Logger,
    txManager: TransactionManager
): OrderService {
    let service: OrderService = new OrderService(repository, inventory);
    
    // Layer on cross-cutting concerns
    service = withLogging(service, logger, { logArgs: false });
    service = withTransaction(service, txManager);
    
    return service;
}
 
// OCP BENEFIT: 
// - OrderService has NO knowledge of logging or transactions
// - Adding a new cross-cutting concern (e.g., timing) modifies nothing
// - Different environments can use different decorators
 
function createTestOrderService(): OrderService {
    // In tests: no logging, no transactions, mock dependencies
    return new OrderService(mockRepository, mockInventory);
}
 
function createDevelopmentOrderService(): OrderService {
    let service = new OrderService(devRepository, devInventory);
    service = withLogging(service, consoleLogger, { logArgs: true });
    // No transactions in dev - faster iteration
    return service;
}
 
function createProductionOrderService(): OrderService {
    let service = new OrderService(prodRepository, prodInventory);
    service = withLogging(service, structuredLogger);
    service = withTransaction(service, pgTransactionManager);
    service = withCircuitBreaker(service, externalServiceBreaker);
    return service;
}

Proxy-Based Decoration

JavaScript Proxies enable decorating entire objects without defining wrapper classes for each method. This technique applies cross-cutting concerns with minimal boilerplate. Similar approaches exist in other languages (dynamic proxies in Java, getattr in Python).

Designing for Composability

Composition-based OCP requires upfront design decisions that enable composition. Not all code is naturally composable—it must be designed that way.

Principles for Composable Design:

Composability Principles

•Uniform Interfaces — Decorators must implement the same interface as what they wrap. Design interfaces that work for both raw components and decorated versions.
•Immutable Inputs — Components should not modify their inputs. Immutable data flows through composition without unexpected side effects.
•Single Responsibility — Each component should do one thing well. Composability comes from combining focused pieces, not wrapping monoliths.
•Context Propagation — Design data structures that can carry additional context as they flow through layers. Use optional fields for decorator-specific data.
•Explicit Dependencies — Components should declare what they need. Hidden dependencies break composition because decorators can't provide them.

composability-design.ts
TypeScript
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
// DESIGNING FOR COMPOSABILITY
 
// ❌ POOR: Hard to compose
class ReportGenerator {
    // Hidden dependencies, mixed concerns
    generate(data: ReportData): Report {
        // Logging embedded
        console.log('Generating report...');
        
        // Validation embedded
        if (!this.validateData(data)) {
            throw new Error('Invalid data');
        }
        
        // Core logic mixed with concerns
        const report = this.buildReport(data);
        
        // Formatting embedded
        return this.formatAsHtml(report);
    }
}
 
// ✓ GOOD: Designed for composition
interface ReportStrategy {
    generate(data: ReportData, context: ReportContext): Promise<Report>;
}
 
interface ReportContext {
    // Extensible context for decorator-added data
    readonly requestId: string;
    readonly metadata?: Map<string, unknown>;
}
 
// Core generator - does ONE thing
class CoreReportGenerator implements ReportStrategy {
    async generate(data: ReportData, context: ReportContext): Promise<Report> {
        // Pure report generation - no logging, no validation, no formatting
        return new Report({
            sections: this.buildSections(data),
            generatedAt: new Date(),
            requestId: context.requestId
        });
    }
}
 
// Validation via composition
class ValidatedReportGenerator implements ReportStrategy {
    constructor(
        private readonly wrapped: ReportStrategy,
        private readonly validator: DataValidator
    ) {}
    
    async generate(data: ReportData, context: ReportContext): Promise<Report> {
        const validation = this.validator.validate(data);
        if (!validation.isValid) {
            throw new ValidationError(validation.errors);
        }
        return this.wrapped.generate(data, context);
    }
}
 
// Formatting via composition
class FormattedReportGenerator implements ReportStrategy {
    constructor(
        private readonly wrapped: ReportStrategy,
        private readonly formatter: ReportFormatter
    ) {}
    
    async generate(data: ReportData, context: ReportContext): Promise<Report> {
        const report = await this.wrapped.generate(data, context);
        return this.formatter.format(report);
    }
}
 
// Composable assembly
function createReportGenerator(
    formatter: ReportFormatter,
    validator: DataValidator,
    logger: Logger
): ReportStrategy {
    let generator: ReportStrategy = new CoreReportGenerator();
    generator = new ValidatedReportGenerator(generator, validator);
    generator = new FormattedReportGenerator(generator, formatter);
    generator = withLogging(generator, logger);
    return generator;
}
 
// ❌ POOR: Non-propagating context
interface BadRequest {
    data: Data;
    // No room for decorator-added info
}
 
// ✓ GOOD: Extensible context
interface GoodRequest {
    readonly data: Data;
    readonly headers: Record<string, string>;
    readonly metadata: Map<string, unknown>;  // Decorators can add to this
}
 
// Decorators can enrich context
class EnrichingDecorator implements RequestHandler {
    async handle(request: GoodRequest): Promise<Response> {
        // Add enrichment data without modifying original
        const enrichedRequest = {
            ...request,
            metadata: new Map([
                ...request.metadata,
                ['enrichedAt', Date.now()],
                ['geoLocation', await this.lookupGeo(request)]
            ])
        };
        
        return this.wrapped.handle(enrichedRequest);
    }
}

Summary: Composing Extensible Systems

Composition patterns provide a powerful approach to OCP distinct from simple strategy swapping. By layering, wrapping, and combining behaviors, we create systems that grow through aggregation rather than modification.

Let's consolidate the key insights:

Key Takeaways

•Decorator adds behavior — Unlike Strategy which swaps behavior, Decorator layers enhancements (logging, caching, retries) onto existing functionality.
•Strategy and Decorator combine — Decorators can wrap any strategy, applying cross-cutting concerns uniformly across all behavioral variants.
•Composite treats groups as individuals — Multiple strategies behind one interface enable fan-out, aggregation, and fallback patterns.
•Chain of Responsibility enables pipelines — Handlers can be added or removed without modifying other handlers or clients.
•Cross-cutting concerns use composition — Logging, transactions, metrics belong in decorators, not business logic.
•Design for composability — Uniform interfaces, immutable data, single responsibility, and extensible context enable composition.

Module Complete:

You've now mastered how the Strategy Pattern achieves OCP through behavioral variation, injection, pure extension, and composition. These techniques form the foundation for building systems that are truly open for extension and closed for modification.

Module Complete

You have comprehensive knowledge of how Strategy Pattern enables the Open/Closed Principle. From basic strategy injection to sophisticated composition patterns, you can now design systems that evolve through extension rather than modification. Apply these patterns to build software that grows gracefully.