System Design (LLD)Applying Design Patterns

Applying Design Patterns in LLD

LevelIntermediate

Duration75 mins

TopicApplying Design Patterns

3 / 4

Pattern Combination

Beyond Single Patterns

The Gang of Four catalog describes 23 patterns. Real-world systems use dozens—often simultaneously, interacting in sophisticated ways. The pattern vocabulary is like musical notes; individual notes have meaning, but music emerges from their combination.

Pattern combination is the orchestration skill of software architecture.

A seasoned architect doesn't think 'I'll use Strategy here and Observer there.' They think 'This domain model naturally emerges from State managing workflow, Factory creating state objects, Observer notifying external consumers, and Command capturing operations for audit.' These patterns don't just coexist—they work together, each pattern's outputs becoming another's inputs.

This page teaches you to compose patterns into cohesive architectures. You'll learn which patterns combine naturally, how to identify seams where patterns meet, and how to avoid the complexity explosion that comes from undisciplined pattern stacking.

What You Will Learn

By the end of this page, you will understand the principles of pattern composition, recognize classic pattern combinations and their applications, learn to identify integration points where patterns meet, and develop the skill of designing multi-pattern architectures that remain coherent and maintainable.

The Principles of Pattern Composition

Pattern combination isn't arbitrary—it follows principles that determine whether patterns compose harmoniously or create confusion. Understanding these principles enables deliberate, effective pattern orchestration.

The Fundamental Principle: Orthogonality

Patterns combine most effectively when they address orthogonal concerns—independent dimensions of the problem that don't overlap. When patterns address the same concern, they conflict; when they address independent concerns, they compose cleanly.

Example of Orthogonal Combination:

Factory Method addresses: How objects are created
Strategy addresses: How behavior varies at runtime
Observer addresses: How state changes propagate

These concerns are independent. A system can use Factory to create Strategy objects, and those Strategies can be Observers—each pattern handles its own responsibility without confusion.

Core Principles of Pattern Composition

•Orthogonality Principle — Combine patterns that address independent concerns. Overlapping concerns create friction; independent concerns compose freely.
•Layering Principle — Patterns can form layers where one pattern operates on artifacts of another. Factories create Decorators; Commands invoke Strategies; States trigger Observers.
•Interface Segregation Principle — Patterns meet at interfaces. Well-defined interfaces enable patterns to interact without knowing each other's implementation details.
•Single Responsibility at Composition Level — Each pattern in a composition should have a clear, singular role. If a pattern's role is unclear, the composition is confused.
•Emergence Principle — The combined effect of patterns should be greater than their sum. If the combination adds complexity without commensurate benefit, it's over-engineered.

The Composition Test

For any pattern combination, ask: 'Can I explain each pattern's role in one sentence without mentioning the other patterns?' If yes, the combination is likely clean. If explaining one pattern requires explaining others, the concerns may be entangled.

Classic Pattern Combinations

Certain pattern combinations appear so frequently in well-designed systems that they've become recognized idioms. Learning these combinations accelerates your ability to compose patterns effectively.

Why Classic Combinations Matter:

These combinations aren't arbitrary—they reflect natural affinities between patterns. Where one pattern creates a need, another pattern often fills it. Recognizing these affinities enables rapid composition in new domains.

The Combination:

Factory creates Strategy instances; clients work with Strategies without knowing concrete types.

Why They Combine:

Strategy decouples algorithm selection from usage
Factory decouples object creation from usage
Together: complete decoupling of both creation and behavior

Common Scenarios:

Payment processing (Factory creates PaymentStrategy based on payment method)
Compression/encryption (Factory selects algorithm Strategy based on configuration)
Parser selection (Factory creates Parser Strategy based on file type)

Factory + Strategy Example
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
// The Strategy interface
interface CompressionStrategy {
    compress(data: Buffer): Buffer;
    decompress(data: Buffer): Buffer;
}
 
// Concrete Strategies
class GzipCompression implements CompressionStrategy {
    compress(data: Buffer): Buffer { /* ... */ }
    decompress(data: Buffer): Buffer { /* ... */ }
}
 
class LZ4Compression implements CompressionStrategy {
    compress(data: Buffer): Buffer { /* ... */ }
    decompress(data: Buffer): Buffer { /* ... */ }
}
 
// Factory that creates Strategies
class CompressionFactory {
    createStrategy(format: string): CompressionStrategy {
        switch (format) {
            case 'gzip': return new GzipCompression();
            case 'lz4': return new LZ4Compression();
            default: throw new Error(`Unknown format: ${format}`);
        }
    }
}
 
// Client uses Factory to get Strategy, works with interface
class FileArchiver {
    constructor(
        private factory: CompressionFactory,
        private format: string
    ) {}
 
    archive(files: Buffer[]): Buffer {
        const strategy = this.factory.createStrategy(this.format);
        return files.reduce((acc, file) => 
            Buffer.concat([acc, strategy.compress(file)]), 
            Buffer.alloc(0)
        );
    }
}

Identifying Integration Seams

When patterns combine, they meet at seams—points of integration where one pattern's output becomes another's input, or where patterns share common elements. Identifying seams is crucial for clean composition.

Types of Pattern Seams:

Common Seam Types

•Creation Seams — Where one pattern creates instances used by another. Factory creating Decorator chains, Builder assembling Composite structures, Prototype cloning Strategy instances.
•Delegation Seams — Where one pattern delegates to another. Context delegating to State, Invoker delegating to Command, Composite delegating to children.
•Notification Seams — Where one pattern triggers another. State transitions triggering Observer notifications, Command execution triggering Memento creation.
•Transformation Seams — Where one pattern transforms artifacts of another. Visitor transforming Composite elements, Decorator wrapping Strategy outputs.
•Structural Seams — Where patterns share structural elements. Adapter making incompatible classes work with existing patterns, Proxy standing in for pattern participants.

Designing Clean Seams:

The quality of pattern seams determines the maintainability of the composition.

Clean Seam Characteristics:

Well-defined interfaces at the seam
Minimum knowledge across the seam (patterns don't know each other's internals)
Clear data flow direction
Single responsibility at each side of the seam

Problematic Seam Indicators:

Bi-directional dependencies across the seam
Leaking implementation details across patterns
Unclear responsibility for seam behavior
Pattern A needing to know pattern B's internal state

The Seam Contract

Every seam should have an explicit or implicit 'contract': what one pattern provides, what another expects. Document these contracts for complex compositions. When seam contracts are clear, patterns can evolve independently.

Multi-Pattern Architecture Design

Complex systems require multiple patterns working in concert. Designing these multi-pattern architectures requires a systematic approach that ensures coherence.

The Architecture Design Process:

Multi-Pattern Architecture Design Steps

•Decompose the Problem — Identify independent sub-problems. Each sub-problem may have its own pattern solution.
•Pattern Selection Per Sub-Problem — Select patterns for each sub-problem independently, using the selection criteria from Page 2.
•Identify Seams — Determine where the sub-problems interact. These interaction points become pattern seams.
•Design Seam Contracts — Define the interfaces at each seam. What data flows? What operations are exposed?
•Validate Orthogonality — Confirm that patterns address different concerns. If concerns overlap, reconsider decomposition.
•Stress Test the Design — Consider change scenarios. How does the composition handle new requirements?
•Simplicity Check — Ask: Could any pattern be removed without loss of required functionality?

Case Study: E-Commerce Order System

Let's design a multi-pattern architecture for a realistic order management system:

Requirements:

Orders progress through states: Created → Paid → Fulfilled → Delivered
Different payment methods with different processing logic
Price modifications based on promotions, loyalty, coupons
Notifications to customers and internal systems on order events
Audit trail of all operations

Multi-Pattern Architecture Analysis

Design Analysis

PROBLEM DECOMPOSITION:
=====================
1. Order Lifecycle → STATE pattern (state-dependent behavior, transitions)
2. Payment Processing → STRATEGY pattern (interchangeable payment methods)
3. Price Modification → DECORATOR pattern (stackable price adjustments)
4. Event Notification → OBSERVER pattern (decouple order from listeners)
5. Audit Trail → COMMAND pattern (operations as objects for logging)
6. Object Creation → FACTORY pattern (create strategies, decorators)
 
SEAM IDENTIFICATION:
===================
Seam A: State transitions trigger Observer notifications
        [State] --notifies--> [Observer]
        Contract: State provides (orderId, oldState, newState)
 
Seam B: Order uses Factory to create PaymentStrategy
        [Order] --requests--> [Factory] --creates--> [Strategy]
        Contract: Factory takes paymentMethod, returns PaymentStrategy
 
Seam C: PricingService uses Decorator chain
        [Factory] --creates--> [Decorator chain] --used by--> [Order]
        Contract: Decorators implement PriceCalculator interface
 
Seam D: State operations wrapped in Commands for audit
        [Command] --wraps--> [State transition]
        Contract: Command captures operation details for logging
 
PATTERN ORCHESTRATION:
=====================
OrderService (coordinates the patterns)
├── OrderFactory (creates Order with initial State)
├── PaymentStrategyFactory (creates payment processors)
├── PriceDecoratorFactory (builds price modification chain)
├── OrderStateObservable (manages Observer subscriptions)
└── CommandInvoker (executes and logs Commands)
 
Order
├── Has current State (State pattern)
├── Uses PaymentStrategy (Strategy pattern)
├── Uses PriceCalculator (Decorator chain)
└── Notifies OrderStateObservable on transitions
 
CHANGE SCENARIO VALIDATION:
==========================
Q: Add new payment method (e.g., crypto)?
A: Add new Strategy, register in Factory. No other patterns affected.
 
Q: Add new price modifier (e.g., flash sale)?
A: Add new Decorator, include in chain. Other decorators unchanged.
 
Q: Add new notification channel (e.g., SMS)?
A: Add new Observer. Order unchanged.
 
Q: Add new order state (e.g., OnHold)?
A: Add new State class, update transitions. Commands/Observers work automatically.

Pattern Combination Anti-Patterns

Pattern combinations can go wrong in characteristic ways. Recognizing these anti-patterns helps avoid over-complicated or dysfunctional architectures.

Common Combination Mistakes:

Combination Anti-Patterns

•Pattern Spaghetti: So many patterns that no one can trace the flow. Every method call goes through three indirections.
•Pattern Redundancy: Multiple patterns solving the same problem. Factory AND Builder AND Prototype for the same object creation.
•Pattern Coupling: Patterns that should be independent share implementation details. Strategy knows about Observer internals.
•Forced Fitting: Combining patterns that don't naturally compose. Trying to make Singleton play with Prototype.
•Leaky Seams: Pattern internals leak across boundaries. Client code manipulates Decorator chain internals.

Healthy Composition Signs

•Clear Flow: The path from input to output is traceable even with multiple patterns. Indirection is intentional, not incidental.
•Single Purpose per Pattern: Each pattern has a clear, distinct role. No two patterns doing similar things.
•Interface Isolation: Patterns interact through defined interfaces. No pattern knows another's implementation.
•Natural Fit: Patterns complement each other. Outputs of one naturally feed inputs of another.
•Clean Seams: Integration points are clearly defined. Changes in one pattern don't ripple through others.

The Complexity Budget

Every project has a 'complexity budget'—the total amount of complexity the team can effectively manage. Pattern combinations consume this budget. Before adding another pattern to a composition, ask: Is the benefit worth the complexity cost? What simpler alternative was considered?

Testing Pattern Combinations

Multi-pattern architectures require thoughtful testing strategies. The good news: well-composed patterns are inherently testable because concerns are separated.

Testing Strategy for Pattern Combinations:

Multi-Level Testing Approach

•Unit Test Each Pattern Participant — Test concrete Strategies in isolation. Test each State independently. Test individual Decorators. Each pattern participant should have unit tests.
•Test Pattern Mechanics — Test that the pattern works as expected: Strategy swapping changes behavior, State transitions are correct, Decorators stack properly.
•Test Seam Contracts — Test that the seam contracts are honored. When State transitions, does Observer receive correct notification? When Factory creates, is the product correct?
•Integration Test Compositions — Test the patterns working together. Complete scenarios that exercise multiple patterns. These are system-level tests.
•Scenario-Based Tests — Test user-visible behaviors that span patterns. 'When customer applies coupon to cart, the discount appears' may involve Factory, Strategy, and Observer.

Testing Pattern Combinations
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
// Level 1: Unit test pattern participant
describe('GzipCompression (Strategy participant)', () => {
    it('should compress and decompress symmetrically', () => {
        const strategy = new GzipCompression();
        const original = Buffer.from('test data');
        const compressed = strategy.compress(original);
        const decompressed = strategy.decompress(compressed);
        expect(decompressed).toEqual(original);
    });
});
 
// Level 2: Test pattern mechanics
describe('CompressionFactory (Factory pattern)', () => {
    it('should return GzipCompression for gzip format', () => {
        const factory = new CompressionFactory();
        const strategy = factory.createStrategy('gzip');
        expect(strategy).toBeInstanceOf(GzipCompression);
    });
    
    it('should throw for unknown format', () => {
        const factory = new CompressionFactory();
        expect(() => factory.createStrategy('unknown'))
            .toThrow('Unknown format');
    });
});
 
// Level 3: Test seam contract
describe('Factory + Strategy seam', () => {
    it('should create strategy that implements interface correctly', () => {
        const factory = new CompressionFactory();
        // Factory creates strategy
        const strategy = factory.createStrategy('gzip');
        // Contract: strategy must implement compress/decompress
        expect(typeof strategy.compress).toBe('function');
        expect(typeof strategy.decompress).toBe('function');
        // Contract: methods must be callable with Buffer
        expect(() => strategy.compress(Buffer.from('test'))).not.toThrow();
    });
});
 
// Level 4: Integration test composition
describe('FileArchiver (Factory + Strategy composition)', () => {
    it('should archive multiple files using selected strategy', () => {
        const archiver = new FileArchiver(new CompressionFactory(), 'gzip');
        const files = [Buffer.from('file1'), Buffer.from('file2')];
        const archive = archiver.archive(files);
        // Integration test: Factory, Strategy, and Archiver work together
        expect(archive.length).toBeGreaterThan(0);
    });
});
 
// Level 5: Scenario-based test
describe('User archives project with selected compression', () => {
    it('should produce smaller archive with compression', () => {
        const archiver = new FileArchiver(new CompressionFactory(), 'gzip');
        const largeFile = Buffer.alloc(10000, 'a');
        const archive = archiver.archive([largeFile]);
        expect(archive.length).toBeLessThan(largeFile.length);
    });
});

Evolving Pattern Compositions

Real systems evolve. Requirements change. What started as a simple Factory + Strategy might need Observer for event handling. A State machine might need Command for audit. The ability to evolve pattern compositions is a key skill.

Incremental Pattern Addition:

Patterns should be addable without rewriting the system. This is possible when:

Seams are clean — New patterns can attach at existing seams
Interfaces are general — Existing interfaces can accommodate new patterns
Coupling is low — Adding a pattern doesn't require modifying other patterns

Evolution Strategies:

Adding Patterns to Existing Compositions

•Decorator Addition — The easiest evolution. Wrap existing components with Decorators for cross-cutting concerns without modifying core logic.
•Observer Injection — Add notification capability by introducing Observable interfaces and Observer registration. Core logic emits events; new functionality subscribes.
•Strategy Extraction — When behavior varies, extract the varying part into a Strategy. Existing code becomes the default strategy.
•Factory Introduction — When object creation becomes complex, introduce a Factory. Direct construction calls become factory invocations.
•Command Wrapping — Wrap operations in Commands for undo, audit, or queuing. The operation itself doesn't change; it's just invoked through Commands.

Evolutionary Architecture

The best pattern compositions are designed to evolve. They have clear extension points, follow the Open-Closed Principle, and use interfaces that can accommodate future patterns. When you design a composition, ask: 'Where might we need to add patterns later?' and ensure those seams are clean.

Summary: Pattern Combination

Pattern combination is where single patterns become architectural vocabulary. Let's consolidate the key insights:

Key Takeaways

•Orthogonality enables composition — Patterns that address independent concerns combine cleanly; overlapping concerns create friction.
•Classic combinations are reusable idioms — Factory+Strategy, Composite+Visitor, State+Observer are proven pairings with natural affinities.
•Seams are the integration points — Well-defined seam contracts enable patterns to interact without knowing each other's internals.
•Multi-pattern architecture requires systematic design — Decompose, select per sub-problem, identify seams, define contracts, validate orthogonality.
•Combination anti-patterns lead to complexity explosion — Watch for pattern spaghetti, redundancy, coupling, and leaky seams.
•Testing follows the composition structure — Unit test participants, test pattern mechanics, test seam contracts, integration test compositions.

What's next:

With pattern matching, selection, and combination skills, there's one critical skill remaining: knowing when to stop. The next page addresses avoiding over-engineering—the discipline of restraint that prevents pattern enthusiasm from producing unmaintainable complexity.

Page Complete

You now understand how patterns compose into architectures, from classic combinations to multi-pattern system design. In the final page of this module, we'll develop the critical skill of knowing when patterns become over-engineering.

3 / 4

Loading learning content...

System Design (LLD)Applying Design Patterns

Applying Design Patterns in LLD

LevelIntermediate

Duration75 mins

TopicApplying Design Patterns

3 / 4

Pattern Combination

Beyond Single Patterns

Pattern combination is the orchestration skill of software architecture.

What You Will Learn

The Principles of Pattern Composition

The Fundamental Principle: Orthogonality

Example of Orthogonal Combination:

Factory Method addresses: How objects are created
Strategy addresses: How behavior varies at runtime
Observer addresses: How state changes propagate

These concerns are independent. A system can use Factory to create Strategy objects, and those Strategies can be Observers—each pattern handles its own responsibility without confusion.

Core Principles of Pattern Composition

•Orthogonality Principle — Combine patterns that address independent concerns. Overlapping concerns create friction; independent concerns compose freely.
•Layering Principle — Patterns can form layers where one pattern operates on artifacts of another. Factories create Decorators; Commands invoke Strategies; States trigger Observers.
•Interface Segregation Principle — Patterns meet at interfaces. Well-defined interfaces enable patterns to interact without knowing each other's implementation details.
•Single Responsibility at Composition Level — Each pattern in a composition should have a clear, singular role. If a pattern's role is unclear, the composition is confused.
•Emergence Principle — The combined effect of patterns should be greater than their sum. If the combination adds complexity without commensurate benefit, it's over-engineered.

The Composition Test

Classic Pattern Combinations

Certain pattern combinations appear so frequently in well-designed systems that they've become recognized idioms. Learning these combinations accelerates your ability to compose patterns effectively.

Why Classic Combinations Matter:

The Combination:

Factory creates Strategy instances; clients work with Strategies without knowing concrete types.

Why They Combine:

Strategy decouples algorithm selection from usage
Factory decouples object creation from usage
Together: complete decoupling of both creation and behavior

Common Scenarios:

Payment processing (Factory creates PaymentStrategy based on payment method)
Compression/encryption (Factory selects algorithm Strategy based on configuration)
Parser selection (Factory creates Parser Strategy based on file type)

Factory + Strategy Example
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
// The Strategy interface
interface CompressionStrategy {
    compress(data: Buffer): Buffer;
    decompress(data: Buffer): Buffer;
}
 
// Concrete Strategies
class GzipCompression implements CompressionStrategy {
    compress(data: Buffer): Buffer { /* ... */ }
    decompress(data: Buffer): Buffer { /* ... */ }
}
 
class LZ4Compression implements CompressionStrategy {
    compress(data: Buffer): Buffer { /* ... */ }
    decompress(data: Buffer): Buffer { /* ... */ }
}
 
// Factory that creates Strategies
class CompressionFactory {
    createStrategy(format: string): CompressionStrategy {
        switch (format) {
            case 'gzip': return new GzipCompression();
            case 'lz4': return new LZ4Compression();
            default: throw new Error(`Unknown format: ${format}`);
        }
    }
}
 
// Client uses Factory to get Strategy, works with interface
class FileArchiver {
    constructor(
        private factory: CompressionFactory,
        private format: string
    ) {}
 
    archive(files: Buffer[]): Buffer {
        const strategy = this.factory.createStrategy(this.format);
        return files.reduce((acc, file) => 
            Buffer.concat([acc, strategy.compress(file)]), 
            Buffer.alloc(0)
        );
    }
}

Identifying Integration Seams

Types of Pattern Seams:

Common Seam Types

•Creation Seams — Where one pattern creates instances used by another. Factory creating Decorator chains, Builder assembling Composite structures, Prototype cloning Strategy instances.
•Delegation Seams — Where one pattern delegates to another. Context delegating to State, Invoker delegating to Command, Composite delegating to children.
•Notification Seams — Where one pattern triggers another. State transitions triggering Observer notifications, Command execution triggering Memento creation.
•Transformation Seams — Where one pattern transforms artifacts of another. Visitor transforming Composite elements, Decorator wrapping Strategy outputs.
•Structural Seams — Where patterns share structural elements. Adapter making incompatible classes work with existing patterns, Proxy standing in for pattern participants.

Designing Clean Seams:

The quality of pattern seams determines the maintainability of the composition.

Clean Seam Characteristics:

Well-defined interfaces at the seam
Minimum knowledge across the seam (patterns don't know each other's internals)
Clear data flow direction
Single responsibility at each side of the seam

Problematic Seam Indicators:

Bi-directional dependencies across the seam
Leaking implementation details across patterns
Unclear responsibility for seam behavior
Pattern A needing to know pattern B's internal state

The Seam Contract

Multi-Pattern Architecture Design

Complex systems require multiple patterns working in concert. Designing these multi-pattern architectures requires a systematic approach that ensures coherence.

The Architecture Design Process:

Multi-Pattern Architecture Design Steps

•Decompose the Problem — Identify independent sub-problems. Each sub-problem may have its own pattern solution.
•Pattern Selection Per Sub-Problem — Select patterns for each sub-problem independently, using the selection criteria from Page 2.
•Identify Seams — Determine where the sub-problems interact. These interaction points become pattern seams.
•Design Seam Contracts — Define the interfaces at each seam. What data flows? What operations are exposed?
•Validate Orthogonality — Confirm that patterns address different concerns. If concerns overlap, reconsider decomposition.
•Stress Test the Design — Consider change scenarios. How does the composition handle new requirements?
•Simplicity Check — Ask: Could any pattern be removed without loss of required functionality?

Case Study: E-Commerce Order System

Let's design a multi-pattern architecture for a realistic order management system:

Requirements:

Orders progress through states: Created → Paid → Fulfilled → Delivered
Different payment methods with different processing logic
Price modifications based on promotions, loyalty, coupons
Notifications to customers and internal systems on order events
Audit trail of all operations

Multi-Pattern Architecture Analysis

Design Analysis

PROBLEM DECOMPOSITION:
=====================
1. Order Lifecycle → STATE pattern (state-dependent behavior, transitions)
2. Payment Processing → STRATEGY pattern (interchangeable payment methods)
3. Price Modification → DECORATOR pattern (stackable price adjustments)
4. Event Notification → OBSERVER pattern (decouple order from listeners)
5. Audit Trail → COMMAND pattern (operations as objects for logging)
6. Object Creation → FACTORY pattern (create strategies, decorators)
 
SEAM IDENTIFICATION:
===================
Seam A: State transitions trigger Observer notifications
        [State] --notifies--> [Observer]
        Contract: State provides (orderId, oldState, newState)
 
Seam B: Order uses Factory to create PaymentStrategy
        [Order] --requests--> [Factory] --creates--> [Strategy]
        Contract: Factory takes paymentMethod, returns PaymentStrategy
 
Seam C: PricingService uses Decorator chain
        [Factory] --creates--> [Decorator chain] --used by--> [Order]
        Contract: Decorators implement PriceCalculator interface
 
Seam D: State operations wrapped in Commands for audit
        [Command] --wraps--> [State transition]
        Contract: Command captures operation details for logging
 
PATTERN ORCHESTRATION:
=====================
OrderService (coordinates the patterns)
├── OrderFactory (creates Order with initial State)
├── PaymentStrategyFactory (creates payment processors)
├── PriceDecoratorFactory (builds price modification chain)
├── OrderStateObservable (manages Observer subscriptions)
└── CommandInvoker (executes and logs Commands)
 
Order
├── Has current State (State pattern)
├── Uses PaymentStrategy (Strategy pattern)
├── Uses PriceCalculator (Decorator chain)
└── Notifies OrderStateObservable on transitions
 
CHANGE SCENARIO VALIDATION:
==========================
Q: Add new payment method (e.g., crypto)?
A: Add new Strategy, register in Factory. No other patterns affected.
 
Q: Add new price modifier (e.g., flash sale)?
A: Add new Decorator, include in chain. Other decorators unchanged.
 
Q: Add new notification channel (e.g., SMS)?
A: Add new Observer. Order unchanged.
 
Q: Add new order state (e.g., OnHold)?
A: Add new State class, update transitions. Commands/Observers work automatically.

Pattern Combination Anti-Patterns

Pattern combinations can go wrong in characteristic ways. Recognizing these anti-patterns helps avoid over-complicated or dysfunctional architectures.

Common Combination Mistakes:

Combination Anti-Patterns

•Pattern Spaghetti: So many patterns that no one can trace the flow. Every method call goes through three indirections.
•Pattern Redundancy: Multiple patterns solving the same problem. Factory AND Builder AND Prototype for the same object creation.
•Pattern Coupling: Patterns that should be independent share implementation details. Strategy knows about Observer internals.
•Forced Fitting: Combining patterns that don't naturally compose. Trying to make Singleton play with Prototype.
•Leaky Seams: Pattern internals leak across boundaries. Client code manipulates Decorator chain internals.

Healthy Composition Signs

•Clear Flow: The path from input to output is traceable even with multiple patterns. Indirection is intentional, not incidental.
•Single Purpose per Pattern: Each pattern has a clear, distinct role. No two patterns doing similar things.
•Interface Isolation: Patterns interact through defined interfaces. No pattern knows another's implementation.
•Natural Fit: Patterns complement each other. Outputs of one naturally feed inputs of another.
•Clean Seams: Integration points are clearly defined. Changes in one pattern don't ripple through others.

The Complexity Budget

Testing Pattern Combinations

Multi-pattern architectures require thoughtful testing strategies. The good news: well-composed patterns are inherently testable because concerns are separated.

Testing Strategy for Pattern Combinations:

Multi-Level Testing Approach

•Unit Test Each Pattern Participant — Test concrete Strategies in isolation. Test each State independently. Test individual Decorators. Each pattern participant should have unit tests.
•Test Pattern Mechanics — Test that the pattern works as expected: Strategy swapping changes behavior, State transitions are correct, Decorators stack properly.
•Test Seam Contracts — Test that the seam contracts are honored. When State transitions, does Observer receive correct notification? When Factory creates, is the product correct?
•Integration Test Compositions — Test the patterns working together. Complete scenarios that exercise multiple patterns. These are system-level tests.
•Scenario-Based Tests — Test user-visible behaviors that span patterns. 'When customer applies coupon to cart, the discount appears' may involve Factory, Strategy, and Observer.

Testing Pattern Combinations
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
// Level 1: Unit test pattern participant
describe('GzipCompression (Strategy participant)', () => {
    it('should compress and decompress symmetrically', () => {
        const strategy = new GzipCompression();
        const original = Buffer.from('test data');
        const compressed = strategy.compress(original);
        const decompressed = strategy.decompress(compressed);
        expect(decompressed).toEqual(original);
    });
});
 
// Level 2: Test pattern mechanics
describe('CompressionFactory (Factory pattern)', () => {
    it('should return GzipCompression for gzip format', () => {
        const factory = new CompressionFactory();
        const strategy = factory.createStrategy('gzip');
        expect(strategy).toBeInstanceOf(GzipCompression);
    });
    
    it('should throw for unknown format', () => {
        const factory = new CompressionFactory();
        expect(() => factory.createStrategy('unknown'))
            .toThrow('Unknown format');
    });
});
 
// Level 3: Test seam contract
describe('Factory + Strategy seam', () => {
    it('should create strategy that implements interface correctly', () => {
        const factory = new CompressionFactory();
        // Factory creates strategy
        const strategy = factory.createStrategy('gzip');
        // Contract: strategy must implement compress/decompress
        expect(typeof strategy.compress).toBe('function');
        expect(typeof strategy.decompress).toBe('function');
        // Contract: methods must be callable with Buffer
        expect(() => strategy.compress(Buffer.from('test'))).not.toThrow();
    });
});
 
// Level 4: Integration test composition
describe('FileArchiver (Factory + Strategy composition)', () => {
    it('should archive multiple files using selected strategy', () => {
        const archiver = new FileArchiver(new CompressionFactory(), 'gzip');
        const files = [Buffer.from('file1'), Buffer.from('file2')];
        const archive = archiver.archive(files);
        // Integration test: Factory, Strategy, and Archiver work together
        expect(archive.length).toBeGreaterThan(0);
    });
});
 
// Level 5: Scenario-based test
describe('User archives project with selected compression', () => {
    it('should produce smaller archive with compression', () => {
        const archiver = new FileArchiver(new CompressionFactory(), 'gzip');
        const largeFile = Buffer.alloc(10000, 'a');
        const archive = archiver.archive([largeFile]);
        expect(archive.length).toBeLessThan(largeFile.length);
    });
});

Evolving Pattern Compositions

Incremental Pattern Addition:

Patterns should be addable without rewriting the system. This is possible when:

Seams are clean — New patterns can attach at existing seams
Interfaces are general — Existing interfaces can accommodate new patterns
Coupling is low — Adding a pattern doesn't require modifying other patterns

Evolution Strategies:

Adding Patterns to Existing Compositions

•Decorator Addition — The easiest evolution. Wrap existing components with Decorators for cross-cutting concerns without modifying core logic.
•Observer Injection — Add notification capability by introducing Observable interfaces and Observer registration. Core logic emits events; new functionality subscribes.
•Strategy Extraction — When behavior varies, extract the varying part into a Strategy. Existing code becomes the default strategy.
•Factory Introduction — When object creation becomes complex, introduce a Factory. Direct construction calls become factory invocations.
•Command Wrapping — Wrap operations in Commands for undo, audit, or queuing. The operation itself doesn't change; it's just invoked through Commands.

Evolutionary Architecture

Summary: Pattern Combination

Pattern combination is where single patterns become architectural vocabulary. Let's consolidate the key insights:

Key Takeaways

•Orthogonality enables composition — Patterns that address independent concerns combine cleanly; overlapping concerns create friction.
•Classic combinations are reusable idioms — Factory+Strategy, Composite+Visitor, State+Observer are proven pairings with natural affinities.
•Seams are the integration points — Well-defined seam contracts enable patterns to interact without knowing each other's internals.
•Multi-pattern architecture requires systematic design — Decompose, select per sub-problem, identify seams, define contracts, validate orthogonality.
•Combination anti-patterns lead to complexity explosion — Watch for pattern spaghetti, redundancy, coupling, and leaky seams.
•Testing follows the composition structure — Unit test participants, test pattern mechanics, test seam contracts, integration test compositions.

What's next:

Page Complete

3 / 4