System Design (LLD)Choosing the Right Behavioral Pattern

Choosing the Right Behavioral Pattern

LevelAdvanced

Duration75 mins

TopicChoosing the Right Behavioral Pattern

3 / 4

Combining Behavioral Patterns

Beyond Single-Pattern Solutions

The Gang of Four catalog presents patterns as discrete, independent solutions. Yet in production systems, patterns rarely operate in isolation. Real architectures orchestrate multiple patterns, each addressing a specific facet of the design challenge.

Consider a sophisticated order processing system:

Command encapsulates operations for undo/redo
Chain of Responsibility routes orders through validators
Observer notifies interested parties of status changes
State manages order lifecycle transitions
Memento enables checkpoint/rollback

These patterns don't compete—they collaborate. Understanding how patterns combine is what separates textbook knowledge from architectural mastery.

What You Will Master

By the end of this page, you will understand how to identify synergistic pattern combinations, avoid conflicts between patterns, and design cohesive multi-pattern architectures. You'll see how patterns reinforce each other's strengths and compensate for each other's weaknesses.

Pattern Combination Principles

Before exploring specific combinations, let's establish principles that guide effective pattern integration.

The Complementarity Principle:

Patterns combine well when they address orthogonal concerns—different aspects of the same problem that don't overlap. For example:

Command addresses what to do (operation reification)
Chain of Responsibility addresses who should do it (handler selection)
Observer addresses who should know it happened (notification)

These concerns are orthogonal: solving one doesn't solve the others, yet they naturally compose.

Pattern Combination Guidelines

•Orthogonality — Combine patterns that address different concerns. Overlapping patterns create redundancy and confusion.
•Minimal Coupling — Patterns should interact through clean interfaces. One pattern's internals shouldn't depend on another's implementation details.
•Single Responsibility per Pattern — Each pattern should handle one aspect. Resist making a pattern do 'double duty' across responsibilities.
•Layered Integration — Structure combinations so patterns operate at clear layers. Higher-level patterns can orchestrate lower-level ones.
•Favor Composition — When patterns need to work together, prefer composing pattern participants over merging pattern structures.

The Over-Patterning Trap

Just because patterns can combine doesn't mean they should. Each pattern adds conceptual overhead. Before adding another pattern, ask: 'Is this complexity justified by a real requirement, or am I pattern-matching for its own sake?' The simplest design that meets requirements is the best design.

Natural Pattern Affinities

Certain behavioral patterns have natural affinities—they complement each other so well that they're frequently found together in mature architectures. Understanding these affinities accelerates design decisions.

High-Affinity Pattern Combinations
Combination	Synergy	Combined Benefit
Command + Memento	Command operations can use Memento for undo state	Full undo/redo with encapsulation preserved
Command + Chain of Responsibility	Chain routes commands to appropriate handlers	Decoupled command dispatch with flexible routing
Observer + Mediator	Mediator coordinates; Observer notifies specific events	Controlled communication with targeted notifications
State + Strategy	State uses strategies for state-specific algorithms	Clean state management with algorithm flexibility
Iterator + Visitor	Iterator handles traversal; Visitor handles operations	Separation of traversal and processing logic
Command + Observer	Commands execute; Observers react to command completion	Action execution with reactive notification
State + Memento	Memento captures state object snapshots for rollback	State machine with checkpoint capability
Chain of Responsibility + Command	Chain handlers wrap command execution with preprocessing	Pipeline processing with command semantics
Template Method + Strategy	Template defines structure; Strategy varies key steps	Fixed algorithm skeleton with pluggable components

Recognizing Affinity Signals:

When analyzing a design problem, look for signals that multiple patterns are needed:

Signal	Likely Combination
"We need to undo this"	Command + Memento
"Multiple systems need to know"	Command/State + Observer
"Route request dynamically, then execute"	Chain of Responsibility + Command
"Traverse and transform"	Iterator + Visitor
"State affects algorithm choice"	State + Strategy
"Centralize coordination, but notify specifically"	Mediator + Observer
"Fixed workflow, variable implementations"	Template Method + Strategy

Deep Dive: Command + Memento

The Command + Memento combination is perhaps the most iconic pattern pairing for implementing undo/redo functionality. Let's explore how these patterns synergize.

The Individual Roles:

Command: Encapsulates an operation as an object, enabling parameterization, queuing, and logging
Memento: Captures an object's internal state for later restoration without exposing structure

The Synergy:

Command alone can support undo if each command implements an unexecute() method. However, this approach has limitations:

Command must know exactly how to reverse its effects
Complex commands may not have simple inverses
State before command execution may be needed

Memento complements Command by capturing state snapshots before command execution. To undo, simply restore the memento rather than computing the inverse operation.

command-memento-integration.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
// Memento captures editor state
interface EditorMemento {
  content: string;
  cursorPosition: number;
  selectionRange: [number, number] | null;
}
 
class Editor {
  private content: string = '';
  private cursorPosition: number = 0;
  private selectionRange: [number, number] | null = null;
 
  // Create memento (save state)
  createMemento(): EditorMemento {
    return {
      content: this.content,
      cursorPosition: this.cursorPosition,
      selectionRange: this.selectionRange ? [...this.selectionRange] : null,
    };
  }
 
  // Restore from memento
  restoreMemento(memento: EditorMemento): void {
    this.content = memento.content;
    this.cursorPosition = memento.cursorPosition;
    this.selectionRange = memento.selectionRange;
  }
 
  // Normal editing operations
  insertText(text: string): void { /* ... */ }
  deleteSelection(): void { /* ... */ }
}
 
// Command with memento-based undo
interface Command {
  execute(): void;
  undo(): void;
}
 
class InsertTextCommand implements Command {
  private memento: EditorMemento | null = null;
 
  constructor(
    private editor: Editor,
    private text: string
  ) {}
 
  execute(): void {
    // Capture state BEFORE execution
    this.memento = this.editor.createMemento();
    this.editor.insertText(this.text);
  }
 
  undo(): void {
    if (this.memento) {
      // Restore state instead of computing inverse
      this.editor.restoreMemento(this.memento);
    }
  }
}
 
// Command history manages undo/redo stack
class CommandHistory {
  private undoStack: Command[] = [];
  private redoStack: Command[] = [];
 
  executeCommand(command: Command): void {
    command.execute();
    this.undoStack.push(command);
    this.redoStack = []; // Clear redo on new command
  }
 
  undo(): void {
    const command = this.undoStack.pop();
    if (command) {
      command.undo();
      this.redoStack.push(command);
    }
  }
 
  redo(): void {
    const command = this.redoStack.pop();
    if (command) {
      command.execute();
      this.undoStack.push(command);
    }
  }
}

Benefits of Combination

•No need to compute operation inverses
•Works with complex, non-reversible operations
•State restoration is always exact
•Supports arbitrary command sequences
•Editor encapsulation fully preserved

Trade-offs to Consider

•Memory usage grows with history depth
•Large states may be expensive to snapshot
•Consider incremental mementos for efficiency
•May need memento compression strategies
•Redo requires command re-execution

Deep Dive: Observer + Mediator

Observer + Mediator work together in systems with complex inter-component coordination that also requires targeted event notification. This combination is common in UI frameworks and event-driven architectures.

The Individual Roles:

Mediator: Centralizes control logic, replacing many-to-many relationships with hub-and-spoke
Observer: Provides one-to-many notification for state changes

The Synergy:

Mediator handles coordination logic—when component A changes, what should components B, C, and D do? Observer handles notification mechanics—how do interested parties learn of events?

Without Observer, Mediator must hardcode all notification targets. Without Mediator, Observer handling complex dependencies leads to spaghetti subscription logic. Together, they provide flexible coordination with extensible notification.

observer-mediator-integration.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
// Event types for type-safe notifications
interface DialogEvent {
  type: 'input-changed' | 'button-clicked' | 'validation-complete';
  source: string;
  data?: unknown;
}
 
// Observer interface for dialog events
interface DialogObserver {
  onDialogEvent(event: DialogEvent): void;
}
 
// Mediator coordinates dialog components
class DialogMediator {
  private components: Map<string, DialogComponent> = new Map();
  private observers: Set<DialogObserver> = new Set();
 
  // Observer pattern: subscription management
  subscribe(observer: DialogObserver): void {
    this.observers.add(observer);
  }
 
  unsubscribe(observer: DialogObserver): void {
    this.observers.delete(observer);
  }
 
  private notify(event: DialogEvent): void {
    this.observers.forEach(observer => observer.onDialogEvent(event));
  }
 
  // Mediator pattern: component registration
  registerComponent(id: string, component: DialogComponent): void {
    this.components.set(id, component);
    component.setMediator(this);
  }
 
  // Mediator pattern: coordination logic
  handleComponentChange(source: string, event: string, data?: unknown): void {
    // Centralized coordination logic
    if (source === 'username' && event === 'input-changed') {
      const password = this.components.get('password');
      const submit = this.components.get('submit');
      
      // Enable password if username is valid
      if (data && (data as string).length >= 3) {
        password?.enable();
      } else {
        password?.disable();
        submit?.disable();
      }
    }
 
    if (source === 'password' && event === 'input-changed') {
      const submit = this.components.get('submit');
      const username = this.components.get('username');
      
      // Enable submit if both fields are valid
      if (data && (data as string).length >= 8 && 
          username?.getValue()?.length >= 3) {
        submit?.enable();
      } else {
        submit?.disable();
      }
    }
 
    // Observer pattern: notify external observers
    this.notify({ type: event as DialogEvent['type'], source, data });
  }
}
 
// Dialog components communicate via mediator
abstract class DialogComponent {
  protected mediator: DialogMediator | null = null;
 
  setMediator(mediator: DialogMediator): void {
    this.mediator = mediator;
  }
 
  protected notifyMediator(event: string, data?: unknown): void {
    this.mediator?.handleComponentChange(this.getId(), event, data);
  }
 
  abstract getId(): string;
  abstract enable(): void;
  abstract disable(): void;
  abstract getValue(): string;
}
 
// External system observes dialog events
class AuditLogger implements DialogObserver {
  onDialogEvent(event: DialogEvent): void {
    console.log(`[Audit] ${event.source}: ${event.type}`);
  }
}
 
class AnalyticsTracker implements DialogObserver {
  onDialogEvent(event: DialogEvent): void {
    if (event.type === 'button-clicked') {
      // Track button click in analytics
      analytics.track('dialog_interaction', event);
    }
  }
}

When to Use This Combination

Use Observer + Mediator when:

Internal component coordination is complex (Mediator)
External systems need to react to events (Observer)
You want coordination logic centralized but notification extensible
Components shouldn't know about external observers

Deep Dive: State + Strategy

State + Strategy combine when an object's state determines which algorithm to use. This powerful combination separates state management from algorithm selection.

The Individual Roles:

State: Allows an object to change behavior when internal state changes
Strategy: Allows algorithms to be selected at runtime

The Synergy:

In State pattern, each state class typically contains the behavior for that state. But what if the behavior itself has variations? State + Strategy allows each state to delegate behavioral variations to strategies, keeping state classes focused on state-specific logic while strategies handle algorithm variations.

state-strategy-integration.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
// Strategy for pricing calculation
interface PricingStrategy {
  calculatePrice(basePrice: number, quantity: number): number;
}
 
class RegularPricing implements PricingStrategy {
  calculatePrice(basePrice: number, quantity: number): number {
    return basePrice * quantity;
  }
}
 
class BulkDiscountPricing implements PricingStrategy {
  calculatePrice(basePrice: number, quantity: number): number {
    const discount = quantity >= 100 ? 0.2 : quantity >= 50 ? 0.1 : 0;
    return basePrice * quantity * (1 - discount);
  }
}
 
class LoyaltyPricing implements PricingStrategy {
  constructor(private loyaltyDiscount: number) {}
  
  calculatePrice(basePrice: number, quantity: number): number {
    return basePrice * quantity * (1 - this.loyaltyDiscount);
  }
}
 
// State for customer account
interface CustomerState {
  getName(): string;
  getPricingStrategy(): PricingStrategy;
  getShippingRate(): number;
  canAccessPremiumProducts(): boolean;
  handlePurchase(amount: number, context: CustomerAccount): void;
}
 
class GuestState implements CustomerState {
  getName() { return 'Guest'; }
  getPricingStrategy() { return new RegularPricing(); }
  getShippingRate() { return 9.99; }
  canAccessPremiumProducts() { return false; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    // Guests get prompted to register after purchase
    console.log('Consider registering for benefits!');
  }
}
 
class StandardState implements CustomerState {
  getName() { return 'Standard'; }
  getPricingStrategy() { return new RegularPricing(); }
  getShippingRate() { return 5.99; }
  canAccessPremiumProducts() { return true; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    context.addLoyaltyPoints(Math.floor(amount));
    if (context.getTotalSpent() >= 1000) {
      context.setState(new GoldState());
    }
  }
}
 
class GoldState implements CustomerState {
  getName() { return 'Gold'; }
  getPricingStrategy() { return new LoyaltyPricing(0.05); }
  getShippingRate() { return 0; } // Free shipping!
  canAccessPremiumProducts() { return true; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    context.addLoyaltyPoints(Math.floor(amount * 1.5)); // Bonus points
    if (context.getTotalSpent() >= 5000) {
      context.setState(new PlatinumState());
    }
  }
}
 
class PlatinumState implements CustomerState {
  getName() { return 'Platinum'; }
  getPricingStrategy() { return new LoyaltyPricing(0.15); }
  getShippingRate() { return 0; }
  canAccessPremiumProducts() { return true; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    context.addLoyaltyPoints(Math.floor(amount * 2)); // Double points
    // Platinum is top tier
  }
}
 
// Context uses State, which uses Strategy
class CustomerAccount {
  private state: CustomerState = new GuestState();
  private totalSpent: number = 0;
  private loyaltyPoints: number = 0;
 
  setState(state: CustomerState): void {
    console.log(`State changed from ${this.state.getName()} to ${state.getName()}`);
    this.state = state;
  }
 
  getTotalSpent(): number { return this.totalSpent; }
  addLoyaltyPoints(points: number): void { this.loyaltyPoints += points; }
 
  // Pricing uses strategy from current state
  calculatePrice(basePrice: number, quantity: number): number {
    const strategy = this.state.getPricingStrategy();
    return strategy.calculatePrice(basePrice, quantity);
  }
 
  getShippingRate(): number {
    return this.state.getShippingRate();
  }
 
  makePurchase(basePrice: number, quantity: number): void {
    const price = this.calculatePrice(basePrice, quantity);
    const shipping = this.state.getShippingRate();
    const total = price + shipping;
    
    this.totalSpent += total;
    this.state.handlePurchase(total, this);
    
    console.log(`Order: $${total} (Member: ${this.state.getName()})`);
  }
}

The Layered Benefit:

This combination creates a layered architecture:

Context Layer (CustomerAccount): Manages overall object behavior
State Layer (CustomerState): Determines state-specific configurations
Strategy Layer (PricingStrategy): Provides algorithm variations

Each layer has a single responsibility:

Context doesn't know about states or strategies
States don't implement algorithms; they select strategies
Strategies don't know about state or context

This separation makes each layer independently testable and modifiable.

Deep Dive: Iterator + Visitor

Iterator + Visitor form a powerful combination for processing object structures. Iterator handles how to traverse; Visitor handles what to do at each element.

The Individual Roles:

Iterator: Provides sequential access to elements without exposing structure
Visitor: Separates operations from the objects they operate on

The Synergy:

Without Iterator, Visitor must embed traversal logic or receive elements one-by-one from elsewhere. Without Visitor, Iterator clients must use type checking to handle heterogeneous elements. Together, they provide clean separation of traversal and operation dispatch.

iterator-visitor-integration.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
// Element hierarchy for file system
interface FileSystemElement {
  accept(visitor: FileSystemVisitor): void;
  getName(): string;
}
 
class File implements FileSystemElement {
  constructor(
    private name: string,
    private size: number,
    private extension: string
  ) {}
 
  getName() { return this.name; }
  getSize() { return this.size; }
  getExtension() { return this.extension; }
 
  accept(visitor: FileSystemVisitor): void {
    visitor.visitFile(this);
  }
}
 
class Directory implements FileSystemElement {
  private children: FileSystemElement[] = [];
 
  constructor(private name: string) {}
 
  getName() { return this.name; }
  getChildren() { return this.children; }
  
  add(element: FileSystemElement): void {
    this.children.push(element);
  }
 
  accept(visitor: FileSystemVisitor): void {
    visitor.visitDirectory(this);
  }
}
 
// Visitor defines operations
interface FileSystemVisitor {
  visitFile(file: File): void;
  visitDirectory(directory: Directory): void;
}
 
// Concrete visitors implement specific operations
class SizeCalculator implements FileSystemVisitor {
  private totalSize = 0;
 
  visitFile(file: File): void {
    this.totalSize += file.getSize();
  }
 
  visitDirectory(directory: Directory): void {
    // Directory itself has no size; children contribute
  }
 
  getTotal() { return this.totalSize; }
}
 
class FileCounter implements FileSystemVisitor {
  private counts = new Map<string, number>();
 
  visitFile(file: File): void {
    const ext = file.getExtension();
    this.counts.set(ext, (this.counts.get(ext) || 0) + 1);
  }
 
  visitDirectory(directory: Directory): void {
    // Directories not counted
  }
 
  getCounts() { return this.counts; }
}
 
class SearchVisitor implements FileSystemVisitor {
  private results: File[] = [];
 
  constructor(private pattern: RegExp) {}
 
  visitFile(file: File): void {
    if (this.pattern.test(file.getName())) {
      this.results.push(file);
    }
  }
 
  visitDirectory(directory: Directory): void {
    // Optionally match directories too
  }
 
  getResults() { return this.results; }
}
 
// Iterator handles traversal
interface FileSystemIterator {
  hasNext(): boolean;
  next(): FileSystemElement;
}
 
class DepthFirstIterator implements FileSystemIterator {
  private stack: FileSystemElement[] = [];
 
  constructor(root: FileSystemElement) {
    this.stack.push(root);
  }
 
  hasNext(): boolean {
    return this.stack.length > 0;
  }
 
  next(): FileSystemElement {
    const element = this.stack.pop()!;
    
    if (element instanceof Directory) {
      // Push children in reverse for correct order
      const children = element.getChildren();
      for (let i = children.length - 1; i >= 0; i--) {
        this.stack.push(children[i]);
      }
    }
    
    return element;
  }
}
 
class BreadthFirstIterator implements FileSystemIterator {
  private queue: FileSystemElement[] = [];
 
  constructor(root: FileSystemElement) {
    this.queue.push(root);
  }
 
  hasNext(): boolean {
    return this.queue.length > 0;
  }
 
  next(): FileSystemElement {
    const element = this.queue.shift()!;
    
    if (element instanceof Directory) {
      element.getChildren().forEach(child => this.queue.push(child));
    }
    
    return element;
  }
}
 
// Traversal + operation combined cleanly
function processFileSystem(
  iterator: FileSystemIterator,
  visitor: FileSystemVisitor
): void {
  while (iterator.hasNext()) {
    const element = iterator.next();
    element.accept(visitor);
  }
}
 
// Usage: Any iterator + any visitor
const root = new Directory('root');
// ... populate file system ...
 
const sizeCalc = new SizeCalculator();
processFileSystem(new DepthFirstIterator(root), sizeCalc);
console.log('Total size:', sizeCalc.getTotal());
 
const counter = new FileCounter();
processFileSystem(new BreadthFirstIterator(root), counter);
console.log('File counts:', counter.getCounts());

Composition Flexibility

Notice how any Iterator can combine with any Visitor. DepthFirstIterator + SizeCalculator, BreadthFirstIterator + SearchVisitor—all combinations work. This is the power of orthogonal pattern combination: M iterators × N visitors = M×N behaviors with only M+N implementations.

Deep Dive: Chain of Responsibility + Command

Chain of Responsibility + Command create sophisticated request processing pipelines. Chain routes requests; Command encapsulates them for flexible handling.

The Individual Roles:

Chain of Responsibility: Passes requests along a chain of handlers
Command: Encapsulates requests as objects

The Synergy:

Commands become the what that flows through the chain. Handlers become the processors that can examine, modify, execute, or pass commands. This enables:

Request preprocessing (validation, logging)
Conditional execution
Post-processing (notifications, cleanup)
Request transformation

chain-command-integration.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
// Command represents the request
interface Command {
  readonly type: string;
  execute(): Promise<CommandResult>;
  getMetadata(): CommandMetadata;
}
 
interface CommandMetadata {
  userId: string;
  timestamp: Date;
  priority: 'low' | 'normal' | 'high';
}
 
interface CommandResult {
  success: boolean;
  data?: unknown;
  error?: Error;
}
 
// Handler in the chain
interface CommandHandler {
  setNext(handler: CommandHandler): CommandHandler;
  handle(command: Command): Promise<CommandResult>;
}
 
abstract class BaseHandler implements CommandHandler {
  private nextHandler: CommandHandler | null = null;
 
  setNext(handler: CommandHandler): CommandHandler {
    this.nextHandler = handler;
    return handler;
  }
 
  async handle(command: Command): Promise<CommandResult> {
    const result = await this.process(command);
    
    // If we handled it or no next handler, return result
    if (result !== null || !this.nextHandler) {
      return result ?? { success: false, error: new Error('Unhandled command') };
    }
    
    // Pass to next handler
    return this.nextHandler.handle(command);
  }
 
  protected abstract process(command: Command): Promise<CommandResult | null>;
}
 
// Authentication handler - validates user permissions
class AuthenticationHandler extends BaseHandler {
  private authorizedUsers = new Set(['admin', 'user1', 'user2']);
 
  protected async process(command: Command): Promise<CommandResult | null> {
    const { userId } = command.getMetadata();
    
    if (!this.authorizedUsers.has(userId)) {
      return { 
        success: false, 
        error: new Error(`Unauthorized: ${userId}`) 
      };
    }
    
    console.log(`[Auth] User ${userId} authorized`);
    return null; // Pass to next handler
  }
}
 
// Validation handler - validates command structure
class ValidationHandler extends BaseHandler {
  protected async process(command: Command): Promise<CommandResult | null> {
    // Validate command-specific requirements
    if (!command.type) {
      return { 
        success: false, 
        error: new Error('Invalid command: missing type') 
      };
    }
    
    console.log(`[Validation] Command ${command.type} validated`);
    return null; // Pass to next handler
  }
}
 
// Logging handler - logs all commands
class LoggingHandler extends BaseHandler {
  protected async process(command: Command): Promise<CommandResult | null> {
    const meta = command.getMetadata();
    console.log(`[Log] ${meta.timestamp.toISOString()} - User: ${meta.userId} - Command: ${command.type}`);
    return null; // Always pass to next handler
  }
}
 
// Rate limiting handler - prevents abuse
class RateLimitHandler extends BaseHandler {
  private requestCounts = new Map<string, number>();
  private readonly limit = 100;
 
  protected async process(command: Command): Promise<CommandResult | null> {
    const { userId } = command.getMetadata();
    const count = (this.requestCounts.get(userId) || 0) + 1;
    
    if (count > this.limit) {
      return { 
        success: false, 
        error: new Error('Rate limit exceeded') 
      };
    }
    
    this.requestCounts.set(userId, count);
    return null; // Pass to next handler
  }
}
 
// Executor handler - actually runs the command
class ExecutorHandler extends BaseHandler {
  protected async process(command: Command): Promise<CommandResult | null> {
    try {
      console.log(`[Executor] Executing ${command.type}...`);
      const result = await command.execute();
      console.log(`[Executor] ${command.type} completed`);
      return result;
    } catch (error) {
      return { success: false, error: error as Error };
    }
  }
}
 
// Build the pipeline
function createCommandPipeline(): CommandHandler {
  const auth = new AuthenticationHandler();
  const validation = new ValidationHandler();
  const logging = new LoggingHandler();
  const rateLimit = new RateLimitHandler();
  const executor = new ExecutorHandler();
 
  // Chain: Auth → Validation → Logging → RateLimit → Execute
  auth
    .setNext(validation)
    .setNext(logging)
    .setNext(rateLimit)
    .setNext(executor);
 
  return auth;
}
 
// Usage
const pipeline = createCommandPipeline();
const result = await pipeline.handle(someCommand);

Pipeline Benefits:

Concern	Handler	Responsibility
Security	AuthenticationHandler	Verify user permissions
Correctness	ValidationHandler	Validate command structure
Observability	LoggingHandler	Audit trail
Protection	RateLimitHandler	Prevent abuse
Execution	ExecutorHandler	Run the command

Each cross-cutting concern has a dedicated handler. Adding a new concern (caching, metrics, transformation) requires only adding a new handler to the chain.

Anti-Patterns in Pattern Combination

Not all pattern combinations are beneficial. Some combinations create conflicts, redundancy, or unnecessary complexity. Recognizing anti-patterns in combination is as important as knowing good combinations.

Pattern Combination Anti-Patterns

•Redundant Coupling — Using both Mediator AND Observer for the same communication. Choose one: Mediator for complex coordination, Observer for simple notification. Using both creates confusion about where communication logic lives.
•State Strategy Confusion — Using State AND Strategy on the same dimension. If the 'state' is just choosing an algorithm, use Strategy alone. If the 'strategy' involves state transitions, use State alone. Don't use both unless they're truly orthogonal.
•Command Everything — Wrapping every method call in a Command object 'for flexibility.' Command is for operations that need to be parameterized, queued, logged, or undone. Simple method calls don't need Command overhead.
•Visitor Over-Application — Using Visitor to add operations to simple class hierarchies. If you can just add a method to the base class, do that. Visitor is only needed when modification is truly prohibited.
•Chain of One — Creating a Chain of Responsibility with a single handler 'for future extensibility.' Just use the handler directly. Add the chain when you actually have multiple handlers.
•Pattern Ladder — Stacking patterns where one would suffice: Mediator holding Observers that notify Commands that execute via Strategies. Each pattern should address a distinct need. If the complexity isn't warranted, simplify.

The Combination Litmus Test

Before combining patterns, ask: 'What distinct requirement does each pattern address?' If you can't articulate a unique need for each pattern, the combination is likely over-engineering. Patterns should solve problems, not demonstrate knowledge.

Summary: Mastering Pattern Combinations

We've explored how behavioral patterns work together in real architectures. Pattern combination is where design pattern knowledge transforms into architectural skill. Here are the essential insights:

Key Takeaways

•Patterns combine when orthogonal — Each pattern should address a distinct concern. Overlapping concerns signal redundancy.
•High-affinity pairs exist — Command+Memento, Observer+Mediator, State+Strategy, Iterator+Visitor are proven combinations.
•Layers create clean architectures — Context uses State uses Strategy, or Pipeline uses Command. Layer patterns for single responsibility.
•Composition beats merging — Keep patterns as distinct components that collaborate, not merged super-patterns.
•Avoid combination anti-patterns — Redundant patterns, premature abstraction, and pattern ladders add complexity without value.
•Test the combination — If removing a pattern would still meet requirements, the pattern wasn't needed.

What's Next:

With a solid understanding of pattern selection and combination, the final page applies these skills to real-world examples. You'll see how production systems use behavioral patterns to solve complex design challenges.

Page Complete

You now understand how behavioral patterns synergize in multi-pattern architectures. This knowledge enables you to design cohesive systems where patterns reinforce each other's strengths. The next page brings these concepts to life with real-world examples.

3 / 4

Loading learning content...

System Design (LLD)Choosing the Right Behavioral Pattern

Choosing the Right Behavioral Pattern

LevelAdvanced

Duration75 mins

TopicChoosing the Right Behavioral Pattern

3 / 4

Combining Behavioral Patterns

Beyond Single-Pattern Solutions

Consider a sophisticated order processing system:

Command encapsulates operations for undo/redo
Chain of Responsibility routes orders through validators
Observer notifies interested parties of status changes
State manages order lifecycle transitions
Memento enables checkpoint/rollback

These patterns don't compete—they collaborate. Understanding how patterns combine is what separates textbook knowledge from architectural mastery.

What You Will Master

Pattern Combination Principles

Before exploring specific combinations, let's establish principles that guide effective pattern integration.

The Complementarity Principle:

Patterns combine well when they address orthogonal concerns—different aspects of the same problem that don't overlap. For example:

Command addresses what to do (operation reification)
Chain of Responsibility addresses who should do it (handler selection)
Observer addresses who should know it happened (notification)

These concerns are orthogonal: solving one doesn't solve the others, yet they naturally compose.

Pattern Combination Guidelines

•Orthogonality — Combine patterns that address different concerns. Overlapping patterns create redundancy and confusion.
•Minimal Coupling — Patterns should interact through clean interfaces. One pattern's internals shouldn't depend on another's implementation details.
•Single Responsibility per Pattern — Each pattern should handle one aspect. Resist making a pattern do 'double duty' across responsibilities.
•Layered Integration — Structure combinations so patterns operate at clear layers. Higher-level patterns can orchestrate lower-level ones.
•Favor Composition — When patterns need to work together, prefer composing pattern participants over merging pattern structures.

The Over-Patterning Trap

Natural Pattern Affinities

High-Affinity Pattern Combinations
Combination	Synergy	Combined Benefit
Command + Memento	Command operations can use Memento for undo state	Full undo/redo with encapsulation preserved
Command + Chain of Responsibility	Chain routes commands to appropriate handlers	Decoupled command dispatch with flexible routing
Observer + Mediator	Mediator coordinates; Observer notifies specific events	Controlled communication with targeted notifications
State + Strategy	State uses strategies for state-specific algorithms	Clean state management with algorithm flexibility
Iterator + Visitor	Iterator handles traversal; Visitor handles operations	Separation of traversal and processing logic
Command + Observer	Commands execute; Observers react to command completion	Action execution with reactive notification
State + Memento	Memento captures state object snapshots for rollback	State machine with checkpoint capability
Chain of Responsibility + Command	Chain handlers wrap command execution with preprocessing	Pipeline processing with command semantics
Template Method + Strategy	Template defines structure; Strategy varies key steps	Fixed algorithm skeleton with pluggable components

Recognizing Affinity Signals:

When analyzing a design problem, look for signals that multiple patterns are needed:

Signal	Likely Combination
"We need to undo this"	Command + Memento
"Multiple systems need to know"	Command/State + Observer
"Route request dynamically, then execute"	Chain of Responsibility + Command
"Traverse and transform"	Iterator + Visitor
"State affects algorithm choice"	State + Strategy
"Centralize coordination, but notify specifically"	Mediator + Observer
"Fixed workflow, variable implementations"	Template Method + Strategy

Deep Dive: Command + Memento

The Command + Memento combination is perhaps the most iconic pattern pairing for implementing undo/redo functionality. Let's explore how these patterns synergize.

The Individual Roles:

Command: Encapsulates an operation as an object, enabling parameterization, queuing, and logging
Memento: Captures an object's internal state for later restoration without exposing structure

The Synergy:

Command alone can support undo if each command implements an unexecute() method. However, this approach has limitations:

Command must know exactly how to reverse its effects
Complex commands may not have simple inverses
State before command execution may be needed

Memento complements Command by capturing state snapshots before command execution. To undo, simply restore the memento rather than computing the inverse operation.

command-memento-integration.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
// Memento captures editor state
interface EditorMemento {
  content: string;
  cursorPosition: number;
  selectionRange: [number, number] | null;
}
 
class Editor {
  private content: string = '';
  private cursorPosition: number = 0;
  private selectionRange: [number, number] | null = null;
 
  // Create memento (save state)
  createMemento(): EditorMemento {
    return {
      content: this.content,
      cursorPosition: this.cursorPosition,
      selectionRange: this.selectionRange ? [...this.selectionRange] : null,
    };
  }
 
  // Restore from memento
  restoreMemento(memento: EditorMemento): void {
    this.content = memento.content;
    this.cursorPosition = memento.cursorPosition;
    this.selectionRange = memento.selectionRange;
  }
 
  // Normal editing operations
  insertText(text: string): void { /* ... */ }
  deleteSelection(): void { /* ... */ }
}
 
// Command with memento-based undo
interface Command {
  execute(): void;
  undo(): void;
}
 
class InsertTextCommand implements Command {
  private memento: EditorMemento | null = null;
 
  constructor(
    private editor: Editor,
    private text: string
  ) {}
 
  execute(): void {
    // Capture state BEFORE execution
    this.memento = this.editor.createMemento();
    this.editor.insertText(this.text);
  }
 
  undo(): void {
    if (this.memento) {
      // Restore state instead of computing inverse
      this.editor.restoreMemento(this.memento);
    }
  }
}
 
// Command history manages undo/redo stack
class CommandHistory {
  private undoStack: Command[] = [];
  private redoStack: Command[] = [];
 
  executeCommand(command: Command): void {
    command.execute();
    this.undoStack.push(command);
    this.redoStack = []; // Clear redo on new command
  }
 
  undo(): void {
    const command = this.undoStack.pop();
    if (command) {
      command.undo();
      this.redoStack.push(command);
    }
  }
 
  redo(): void {
    const command = this.redoStack.pop();
    if (command) {
      command.execute();
      this.undoStack.push(command);
    }
  }
}

Benefits of Combination

•No need to compute operation inverses
•Works with complex, non-reversible operations
•State restoration is always exact
•Supports arbitrary command sequences
•Editor encapsulation fully preserved

Trade-offs to Consider

•Memory usage grows with history depth
•Large states may be expensive to snapshot
•Consider incremental mementos for efficiency
•May need memento compression strategies
•Redo requires command re-execution

Deep Dive: Observer + Mediator

The Individual Roles:

Mediator: Centralizes control logic, replacing many-to-many relationships with hub-and-spoke
Observer: Provides one-to-many notification for state changes

The Synergy:

Mediator handles coordination logic—when component A changes, what should components B, C, and D do? Observer handles notification mechanics—how do interested parties learn of events?

observer-mediator-integration.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
// Event types for type-safe notifications
interface DialogEvent {
  type: 'input-changed' | 'button-clicked' | 'validation-complete';
  source: string;
  data?: unknown;
}
 
// Observer interface for dialog events
interface DialogObserver {
  onDialogEvent(event: DialogEvent): void;
}
 
// Mediator coordinates dialog components
class DialogMediator {
  private components: Map<string, DialogComponent> = new Map();
  private observers: Set<DialogObserver> = new Set();
 
  // Observer pattern: subscription management
  subscribe(observer: DialogObserver): void {
    this.observers.add(observer);
  }
 
  unsubscribe(observer: DialogObserver): void {
    this.observers.delete(observer);
  }
 
  private notify(event: DialogEvent): void {
    this.observers.forEach(observer => observer.onDialogEvent(event));
  }
 
  // Mediator pattern: component registration
  registerComponent(id: string, component: DialogComponent): void {
    this.components.set(id, component);
    component.setMediator(this);
  }
 
  // Mediator pattern: coordination logic
  handleComponentChange(source: string, event: string, data?: unknown): void {
    // Centralized coordination logic
    if (source === 'username' && event === 'input-changed') {
      const password = this.components.get('password');
      const submit = this.components.get('submit');
      
      // Enable password if username is valid
      if (data && (data as string).length >= 3) {
        password?.enable();
      } else {
        password?.disable();
        submit?.disable();
      }
    }
 
    if (source === 'password' && event === 'input-changed') {
      const submit = this.components.get('submit');
      const username = this.components.get('username');
      
      // Enable submit if both fields are valid
      if (data && (data as string).length >= 8 && 
          username?.getValue()?.length >= 3) {
        submit?.enable();
      } else {
        submit?.disable();
      }
    }
 
    // Observer pattern: notify external observers
    this.notify({ type: event as DialogEvent['type'], source, data });
  }
}
 
// Dialog components communicate via mediator
abstract class DialogComponent {
  protected mediator: DialogMediator | null = null;
 
  setMediator(mediator: DialogMediator): void {
    this.mediator = mediator;
  }
 
  protected notifyMediator(event: string, data?: unknown): void {
    this.mediator?.handleComponentChange(this.getId(), event, data);
  }
 
  abstract getId(): string;
  abstract enable(): void;
  abstract disable(): void;
  abstract getValue(): string;
}
 
// External system observes dialog events
class AuditLogger implements DialogObserver {
  onDialogEvent(event: DialogEvent): void {
    console.log(`[Audit] ${event.source}: ${event.type}`);
  }
}
 
class AnalyticsTracker implements DialogObserver {
  onDialogEvent(event: DialogEvent): void {
    if (event.type === 'button-clicked') {
      // Track button click in analytics
      analytics.track('dialog_interaction', event);
    }
  }
}

When to Use This Combination

Use Observer + Mediator when:

Internal component coordination is complex (Mediator)
External systems need to react to events (Observer)
You want coordination logic centralized but notification extensible
Components shouldn't know about external observers

Deep Dive: State + Strategy

State + Strategy combine when an object's state determines which algorithm to use. This powerful combination separates state management from algorithm selection.

The Individual Roles:

State: Allows an object to change behavior when internal state changes
Strategy: Allows algorithms to be selected at runtime

The Synergy:

state-strategy-integration.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
// Strategy for pricing calculation
interface PricingStrategy {
  calculatePrice(basePrice: number, quantity: number): number;
}
 
class RegularPricing implements PricingStrategy {
  calculatePrice(basePrice: number, quantity: number): number {
    return basePrice * quantity;
  }
}
 
class BulkDiscountPricing implements PricingStrategy {
  calculatePrice(basePrice: number, quantity: number): number {
    const discount = quantity >= 100 ? 0.2 : quantity >= 50 ? 0.1 : 0;
    return basePrice * quantity * (1 - discount);
  }
}
 
class LoyaltyPricing implements PricingStrategy {
  constructor(private loyaltyDiscount: number) {}
  
  calculatePrice(basePrice: number, quantity: number): number {
    return basePrice * quantity * (1 - this.loyaltyDiscount);
  }
}
 
// State for customer account
interface CustomerState {
  getName(): string;
  getPricingStrategy(): PricingStrategy;
  getShippingRate(): number;
  canAccessPremiumProducts(): boolean;
  handlePurchase(amount: number, context: CustomerAccount): void;
}
 
class GuestState implements CustomerState {
  getName() { return 'Guest'; }
  getPricingStrategy() { return new RegularPricing(); }
  getShippingRate() { return 9.99; }
  canAccessPremiumProducts() { return false; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    // Guests get prompted to register after purchase
    console.log('Consider registering for benefits!');
  }
}
 
class StandardState implements CustomerState {
  getName() { return 'Standard'; }
  getPricingStrategy() { return new RegularPricing(); }
  getShippingRate() { return 5.99; }
  canAccessPremiumProducts() { return true; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    context.addLoyaltyPoints(Math.floor(amount));
    if (context.getTotalSpent() >= 1000) {
      context.setState(new GoldState());
    }
  }
}
 
class GoldState implements CustomerState {
  getName() { return 'Gold'; }
  getPricingStrategy() { return new LoyaltyPricing(0.05); }
  getShippingRate() { return 0; } // Free shipping!
  canAccessPremiumProducts() { return true; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    context.addLoyaltyPoints(Math.floor(amount * 1.5)); // Bonus points
    if (context.getTotalSpent() >= 5000) {
      context.setState(new PlatinumState());
    }
  }
}
 
class PlatinumState implements CustomerState {
  getName() { return 'Platinum'; }
  getPricingStrategy() { return new LoyaltyPricing(0.15); }
  getShippingRate() { return 0; }
  canAccessPremiumProducts() { return true; }
  
  handlePurchase(amount: number, context: CustomerAccount): void {
    context.addLoyaltyPoints(Math.floor(amount * 2)); // Double points
    // Platinum is top tier
  }
}
 
// Context uses State, which uses Strategy
class CustomerAccount {
  private state: CustomerState = new GuestState();
  private totalSpent: number = 0;
  private loyaltyPoints: number = 0;
 
  setState(state: CustomerState): void {
    console.log(`State changed from ${this.state.getName()} to ${state.getName()}`);
    this.state = state;
  }
 
  getTotalSpent(): number { return this.totalSpent; }
  addLoyaltyPoints(points: number): void { this.loyaltyPoints += points; }
 
  // Pricing uses strategy from current state
  calculatePrice(basePrice: number, quantity: number): number {
    const strategy = this.state.getPricingStrategy();
    return strategy.calculatePrice(basePrice, quantity);
  }
 
  getShippingRate(): number {
    return this.state.getShippingRate();
  }
 
  makePurchase(basePrice: number, quantity: number): void {
    const price = this.calculatePrice(basePrice, quantity);
    const shipping = this.state.getShippingRate();
    const total = price + shipping;
    
    this.totalSpent += total;
    this.state.handlePurchase(total, this);
    
    console.log(`Order: $${total} (Member: ${this.state.getName()})`);
  }
}

The Layered Benefit:

This combination creates a layered architecture:

Context Layer (CustomerAccount): Manages overall object behavior
State Layer (CustomerState): Determines state-specific configurations
Strategy Layer (PricingStrategy): Provides algorithm variations

Each layer has a single responsibility:

Context doesn't know about states or strategies
States don't implement algorithms; they select strategies
Strategies don't know about state or context

This separation makes each layer independently testable and modifiable.

Deep Dive: Iterator + Visitor

Iterator + Visitor form a powerful combination for processing object structures. Iterator handles how to traverse; Visitor handles what to do at each element.

The Individual Roles:

Iterator: Provides sequential access to elements without exposing structure
Visitor: Separates operations from the objects they operate on

The Synergy:

iterator-visitor-integration.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
// Element hierarchy for file system
interface FileSystemElement {
  accept(visitor: FileSystemVisitor): void;
  getName(): string;
}
 
class File implements FileSystemElement {
  constructor(
    private name: string,
    private size: number,
    private extension: string
  ) {}
 
  getName() { return this.name; }
  getSize() { return this.size; }
  getExtension() { return this.extension; }
 
  accept(visitor: FileSystemVisitor): void {
    visitor.visitFile(this);
  }
}
 
class Directory implements FileSystemElement {
  private children: FileSystemElement[] = [];
 
  constructor(private name: string) {}
 
  getName() { return this.name; }
  getChildren() { return this.children; }
  
  add(element: FileSystemElement): void {
    this.children.push(element);
  }
 
  accept(visitor: FileSystemVisitor): void {
    visitor.visitDirectory(this);
  }
}
 
// Visitor defines operations
interface FileSystemVisitor {
  visitFile(file: File): void;
  visitDirectory(directory: Directory): void;
}
 
// Concrete visitors implement specific operations
class SizeCalculator implements FileSystemVisitor {
  private totalSize = 0;
 
  visitFile(file: File): void {
    this.totalSize += file.getSize();
  }
 
  visitDirectory(directory: Directory): void {
    // Directory itself has no size; children contribute
  }
 
  getTotal() { return this.totalSize; }
}
 
class FileCounter implements FileSystemVisitor {
  private counts = new Map<string, number>();
 
  visitFile(file: File): void {
    const ext = file.getExtension();
    this.counts.set(ext, (this.counts.get(ext) || 0) + 1);
  }
 
  visitDirectory(directory: Directory): void {
    // Directories not counted
  }
 
  getCounts() { return this.counts; }
}
 
class SearchVisitor implements FileSystemVisitor {
  private results: File[] = [];
 
  constructor(private pattern: RegExp) {}
 
  visitFile(file: File): void {
    if (this.pattern.test(file.getName())) {
      this.results.push(file);
    }
  }
 
  visitDirectory(directory: Directory): void {
    // Optionally match directories too
  }
 
  getResults() { return this.results; }
}
 
// Iterator handles traversal
interface FileSystemIterator {
  hasNext(): boolean;
  next(): FileSystemElement;
}
 
class DepthFirstIterator implements FileSystemIterator {
  private stack: FileSystemElement[] = [];
 
  constructor(root: FileSystemElement) {
    this.stack.push(root);
  }
 
  hasNext(): boolean {
    return this.stack.length > 0;
  }
 
  next(): FileSystemElement {
    const element = this.stack.pop()!;
    
    if (element instanceof Directory) {
      // Push children in reverse for correct order
      const children = element.getChildren();
      for (let i = children.length - 1; i >= 0; i--) {
        this.stack.push(children[i]);
      }
    }
    
    return element;
  }
}
 
class BreadthFirstIterator implements FileSystemIterator {
  private queue: FileSystemElement[] = [];
 
  constructor(root: FileSystemElement) {
    this.queue.push(root);
  }
 
  hasNext(): boolean {
    return this.queue.length > 0;
  }
 
  next(): FileSystemElement {
    const element = this.queue.shift()!;
    
    if (element instanceof Directory) {
      element.getChildren().forEach(child => this.queue.push(child));
    }
    
    return element;
  }
}
 
// Traversal + operation combined cleanly
function processFileSystem(
  iterator: FileSystemIterator,
  visitor: FileSystemVisitor
): void {
  while (iterator.hasNext()) {
    const element = iterator.next();
    element.accept(visitor);
  }
}
 
// Usage: Any iterator + any visitor
const root = new Directory('root');
// ... populate file system ...
 
const sizeCalc = new SizeCalculator();
processFileSystem(new DepthFirstIterator(root), sizeCalc);
console.log('Total size:', sizeCalc.getTotal());
 
const counter = new FileCounter();
processFileSystem(new BreadthFirstIterator(root), counter);
console.log('File counts:', counter.getCounts());

Composition Flexibility

Deep Dive: Chain of Responsibility + Command

Chain of Responsibility + Command create sophisticated request processing pipelines. Chain routes requests; Command encapsulates them for flexible handling.

The Individual Roles:

Chain of Responsibility: Passes requests along a chain of handlers
Command: Encapsulates requests as objects

The Synergy:

Commands become the what that flows through the chain. Handlers become the processors that can examine, modify, execute, or pass commands. This enables:

Request preprocessing (validation, logging)
Conditional execution
Post-processing (notifications, cleanup)
Request transformation

chain-command-integration.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
// Command represents the request
interface Command {
  readonly type: string;
  execute(): Promise<CommandResult>;
  getMetadata(): CommandMetadata;
}
 
interface CommandMetadata {
  userId: string;
  timestamp: Date;
  priority: 'low' | 'normal' | 'high';
}
 
interface CommandResult {
  success: boolean;
  data?: unknown;
  error?: Error;
}
 
// Handler in the chain
interface CommandHandler {
  setNext(handler: CommandHandler): CommandHandler;
  handle(command: Command): Promise<CommandResult>;
}
 
abstract class BaseHandler implements CommandHandler {
  private nextHandler: CommandHandler | null = null;
 
  setNext(handler: CommandHandler): CommandHandler {
    this.nextHandler = handler;
    return handler;
  }
 
  async handle(command: Command): Promise<CommandResult> {
    const result = await this.process(command);
    
    // If we handled it or no next handler, return result
    if (result !== null || !this.nextHandler) {
      return result ?? { success: false, error: new Error('Unhandled command') };
    }
    
    // Pass to next handler
    return this.nextHandler.handle(command);
  }
 
  protected abstract process(command: Command): Promise<CommandResult | null>;
}
 
// Authentication handler - validates user permissions
class AuthenticationHandler extends BaseHandler {
  private authorizedUsers = new Set(['admin', 'user1', 'user2']);
 
  protected async process(command: Command): Promise<CommandResult | null> {
    const { userId } = command.getMetadata();
    
    if (!this.authorizedUsers.has(userId)) {
      return { 
        success: false, 
        error: new Error(`Unauthorized: ${userId}`) 
      };
    }
    
    console.log(`[Auth] User ${userId} authorized`);
    return null; // Pass to next handler
  }
}
 
// Validation handler - validates command structure
class ValidationHandler extends BaseHandler {
  protected async process(command: Command): Promise<CommandResult | null> {
    // Validate command-specific requirements
    if (!command.type) {
      return { 
        success: false, 
        error: new Error('Invalid command: missing type') 
      };
    }
    
    console.log(`[Validation] Command ${command.type} validated`);
    return null; // Pass to next handler
  }
}
 
// Logging handler - logs all commands
class LoggingHandler extends BaseHandler {
  protected async process(command: Command): Promise<CommandResult | null> {
    const meta = command.getMetadata();
    console.log(`[Log] ${meta.timestamp.toISOString()} - User: ${meta.userId} - Command: ${command.type}`);
    return null; // Always pass to next handler
  }
}
 
// Rate limiting handler - prevents abuse
class RateLimitHandler extends BaseHandler {
  private requestCounts = new Map<string, number>();
  private readonly limit = 100;
 
  protected async process(command: Command): Promise<CommandResult | null> {
    const { userId } = command.getMetadata();
    const count = (this.requestCounts.get(userId) || 0) + 1;
    
    if (count > this.limit) {
      return { 
        success: false, 
        error: new Error('Rate limit exceeded') 
      };
    }
    
    this.requestCounts.set(userId, count);
    return null; // Pass to next handler
  }
}
 
// Executor handler - actually runs the command
class ExecutorHandler extends BaseHandler {
  protected async process(command: Command): Promise<CommandResult | null> {
    try {
      console.log(`[Executor] Executing ${command.type}...`);
      const result = await command.execute();
      console.log(`[Executor] ${command.type} completed`);
      return result;
    } catch (error) {
      return { success: false, error: error as Error };
    }
  }
}
 
// Build the pipeline
function createCommandPipeline(): CommandHandler {
  const auth = new AuthenticationHandler();
  const validation = new ValidationHandler();
  const logging = new LoggingHandler();
  const rateLimit = new RateLimitHandler();
  const executor = new ExecutorHandler();
 
  // Chain: Auth → Validation → Logging → RateLimit → Execute
  auth
    .setNext(validation)
    .setNext(logging)
    .setNext(rateLimit)
    .setNext(executor);
 
  return auth;
}
 
// Usage
const pipeline = createCommandPipeline();
const result = await pipeline.handle(someCommand);

Pipeline Benefits:

Concern	Handler	Responsibility
Security	AuthenticationHandler	Verify user permissions
Correctness	ValidationHandler	Validate command structure
Observability	LoggingHandler	Audit trail
Protection	RateLimitHandler	Prevent abuse
Execution	ExecutorHandler	Run the command

Each cross-cutting concern has a dedicated handler. Adding a new concern (caching, metrics, transformation) requires only adding a new handler to the chain.

Anti-Patterns in Pattern Combination

Pattern Combination Anti-Patterns

•Redundant Coupling — Using both Mediator AND Observer for the same communication. Choose one: Mediator for complex coordination, Observer for simple notification. Using both creates confusion about where communication logic lives.
•State Strategy Confusion — Using State AND Strategy on the same dimension. If the 'state' is just choosing an algorithm, use Strategy alone. If the 'strategy' involves state transitions, use State alone. Don't use both unless they're truly orthogonal.
•Command Everything — Wrapping every method call in a Command object 'for flexibility.' Command is for operations that need to be parameterized, queued, logged, or undone. Simple method calls don't need Command overhead.
•Visitor Over-Application — Using Visitor to add operations to simple class hierarchies. If you can just add a method to the base class, do that. Visitor is only needed when modification is truly prohibited.
•Chain of One — Creating a Chain of Responsibility with a single handler 'for future extensibility.' Just use the handler directly. Add the chain when you actually have multiple handlers.
•Pattern Ladder — Stacking patterns where one would suffice: Mediator holding Observers that notify Commands that execute via Strategies. Each pattern should address a distinct need. If the complexity isn't warranted, simplify.

The Combination Litmus Test

Summary: Mastering Pattern Combinations

We've explored how behavioral patterns work together in real architectures. Pattern combination is where design pattern knowledge transforms into architectural skill. Here are the essential insights:

Key Takeaways

•Patterns combine when orthogonal — Each pattern should address a distinct concern. Overlapping concerns signal redundancy.
•High-affinity pairs exist — Command+Memento, Observer+Mediator, State+Strategy, Iterator+Visitor are proven combinations.
•Layers create clean architectures — Context uses State uses Strategy, or Pipeline uses Command. Layer patterns for single responsibility.
•Composition beats merging — Keep patterns as distinct components that collaborate, not merged super-patterns.
•Avoid combination anti-patterns — Redundant patterns, premature abstraction, and pattern ladders add complexity without value.
•Test the combination — If removing a pattern would still meet requirements, the pattern wasn't needed.

What's Next:

Page Complete

3 / 4