When to Use Patterns - Learning Module

Loading content...

0/246

Problem-Pattern Matching

The Pattern Recognition Skill

You've understood that patterns are solutions to problems—not decorations or demonstrations of sophistication. But understanding this principle is only half the battle. The other half is developing the pattern recognition skill: the ability to look at a design challenge and quickly identify which patterns (if any) address it.

This skill separates fluent pattern users from those who fumble through catalogs hoping to find something that fits. The difference is substantial:

Without pattern recognition: Every new problem requires re-reading pattern catalogs, trial-and-error experimentation, and considerable time
With pattern recognition: Problems trigger immediate association with applicable patterns; evaluation happens in minutes, not hours

What This Page Covers

We'll develop systematic approaches to problem-pattern matching: how to decompose problems into pattern-relevant characteristics, how to build a mental taxonomy of pattern applicability, and how to rapidly evaluate whether a potential pattern match is genuine.

The Problem Decomposition Method

Pattern matching begins with understanding what kind of problem you have. Design problems fall into recognizable categories, and each category maps to specific pattern families. By decomposing your problem into its essential characteristics, you narrow the pattern search space dramatically.

The Core Problem Categories

Most design problems fall into one of these fundamental categories:

Problem Categories and Pattern Families
Problem Category	Core Question	Pattern Family
Object Creation	How should objects be instantiated?	Creational Patterns (Factory, Builder, Prototype, Singleton)
Object Structure	How should objects be composed or organized?	Structural Patterns (Adapter, Bridge, Composite, Decorator, Facade, Proxy)
Object Behavior	How should objects interact and distribute responsibilities?	Behavioral Patterns (Strategy, Observer, Command, State, Template Method)
Object Lifecycle	How should object state and lifetime be managed?	State, Memento, Object Pool, Flyweight
Algorithm Variation	How should varying algorithms be encapsulated?	Strategy, Template Method, Visitor
Interface Incompatibility	How should incompatible interfaces work together?	Adapter, Facade, Bridge
Notification & Events	How should objects learn about state changes?	Observer, Mediator, Event Sourcing

Step 1: Identify the Core Tension

Every pattern-worthy problem contains a design tension—a conflict between how you'd naturally write the code and requirements that make the natural approach problematic.

Common design tensions include:

Recognizable Design Tensions

•Flexibility vs. Simplicity: You need to swap implementations, but hardcoding is simpler
•Open/Closed Tension: You need to add behaviors without modifying existing code
•Coupling vs. Reuse: Components should be reusable but need to work together
•Uniform Treatment vs. Type Differences: Different types should be handled uniformly
•State Explosion: Multiple dimensions of variation create combinatorial complexity
•Notification Need: Changes in one object should trigger updates in others

Tension Naming Exercise

Practice naming the tension in problems you encounter. If you can say 'The tension here is between X and Y,' you've taken the first step toward pattern matching. If you can't articulate the tension, you may not have a pattern-worthy problem.

Problem Signatures: Pattern Fingerprints

Each pattern addresses problems with distinctive characteristics—a problem signature that acts as a fingerprint. Learning to recognize these signatures enables rapid pattern association.

Creational Pattern Signatures

Creational Pattern Problem Signatures
Pattern	Problem Signature	Key Indicators
Factory Method	Need to create objects without specifying exact class	• Type determined at runtime\n• Client should be decoupled from concrete types\n• Creation logic non-trivial
Abstract Factory	Need to create families of related objects consistently	• Multiple related objects created together\n• Family must be consistent\n• Platform/configuration varies families
Builder	Complex object construction with many parameters	• Many optional parameters\n• Step-by-step construction logic\n• Same process, different representations
Prototype	Creating objects by copying existing instances	• Costly to create from scratch\n• Runtime-determined object configuration\n• Need to avoid class dependency
Singleton	Exactly one instance with global access point	• Shared resource access\n• Coordination point needed\n• Expensive to create/destroy repeatedly

Structural Pattern Signatures

Structural Pattern Problem Signatures
Pattern	Problem Signature	Key Indicators
Adapter	Interface of existing class doesn't match what's needed	• Integrating third-party libraries\n• Legacy code with incompatible interface\n• Can't modify the adaptee
Bridge	Abstraction and implementation should vary independently	• Multiple dimensions of variation\n• Avoiding inheritance explosion\n• Platform-independent abstraction
Composite	Tree structure where individual and composite treated uniformly	• Part-whole hierarchies\n• Recursive structure\n• Operations on groups same as individuals
Decorator	Add responsibilities dynamically without subclassing	• Features combine in many ways\n• Subclass explosion otherwise\n• Need to add/remove at runtime
Facade	Complex subsystem needs a simplified interface	• Many classes to coordinate\n• Clients need simple entry point\n• Hiding complexity from clients
Proxy	Control access to another object	• Lazy initialization needed\n• Access control required\n• Remote object access\n• Logging/caching on access

Behavioral Pattern Signatures

Behavioral Pattern Problem Signatures
Pattern	Problem Signature	Key Indicators
Strategy	Algorithm should vary independently of the clients	• Multiple algorithms for same operation\n• Algorithm selected at runtime\n• Avoid conditional statements for selection
Observer	One object changes, others must be notified	• One-to-many dependency\n• Unknown number of dependents\n• Loose coupling needed
Command	Encapsulate requests as objects	• Queue, log, or undo operations\n• Parameterize objects with operations\n• Decouple invoker from performer
State	Object behavior changes based on internal state	• Complex state-dependent behavior\n• Many conditionals on state\n• State transitions at runtime
Template Method	Algorithm steps fixed, but some steps vary	• Invariant parts of algorithm\n• Customizable hooks\n• Avoid code duplication
Chain of Responsibility	Multiple objects may handle a request	• Handler not known a priori\n• Handler determined at runtime\n• Multiple handlers possible

The Systematic Matching Process

With problem decomposition skills and pattern signatures in hand, here's a systematic process for matching problems to patterns:

The Five-Step Matching Process

•Describe the problem in plain language — Write down what you're trying to accomplish and what's making it difficult. Use no pattern vocabulary.
•Identify the core category — Is this about creating objects, structuring relationships, or defining behaviors? This eliminates two-thirds of patterns immediately.
•Articulate the design tension — What conflicting forces make a simple solution inadequate? (e.g., 'I need flexibility but also simplicity')
•Match against problem signatures — Within the relevant category, which pattern signatures match your situation?
•Verify the match — Check the pattern's applicability section. Do your specific circumstances match the stated use cases?

Worked Example: The Payment Processing Problem

Let's apply this process to a real scenario:

Scenario

You're building an e-commerce platform that must support multiple payment methods: credit cards, PayPal, Apple Pay, and cryptocurrency. Each has different integration requirements, and merchants can configure which methods they support. New payment methods will be added as they become popular.

pattern-matching-analysis.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
// Step 1: Describe in plain language
// "I need to process payments through different providers.
// The provider is determined by user choice and merchant config.
// Each provider has different APIs and requirements.
// I want to add new providers without modifying existing code."
 
// Step 2: Identify core category
// This is about BEHAVIOR - how payment processing happens
// (Not about creation or structure)
 
// Step 3: Articulate the design tension
// Tension: I need a uniform way to handle payments, but the 
// implementations are all different. I also need extensibility.
 
// Step 4: Match against signatures
// Looking at behavioral patterns...
// - Strategy: "Algorithm should vary independently of clients"
//   ✓ Multiple algorithms (payment methods) for same operation (process payment)
//   ✓ Algorithm selected at runtime (user/merchant choice)
//   ✓ Avoid conditionals for method selection
// 
// This matches! But let's check one more...
// - Factory might also apply if the issue is CREATING processors
//   → It is, but the core problem is the varying BEHAVIOR
 
// Step 5: Verify the match
// Strategy applicability (from GoF):
// - "Many related classes differ only in their behavior" ✓
// - "You need different variants of an algorithm" ✓
// - "An algorithm uses data a client shouldn't know about" ✓
// - "A class defines many behaviors as conditionals" ✓
 
// CONCLUSION: Strategy pattern is appropriate
// (Factory may complement it for creating strategy instances)
 
interface PaymentProcessor {
    processPayment(amount: Money, context: PaymentContext): Promise<PaymentResult>;
    validatePaymentDetails(details: PaymentDetails): ValidationResult;
    supportsRefund(): boolean;
    processRefund(paymentId: string, amount: Money): Promise<RefundResult>;
}
 
class StripePaymentProcessor implements PaymentProcessor {
    constructor(private readonly stripeClient: StripeAPI) {}
    
    async processPayment(amount: Money, context: PaymentContext): Promise<PaymentResult> {
        const charge = await this.stripeClient.charges.create({
            amount: amount.cents,
            currency: amount.currency,
            source: context.stripeToken,
        });
        return { success: true, transactionId: charge.id };
    }
    
    validatePaymentDetails(details: PaymentDetails): ValidationResult {
        // Stripe-specific validation
        return { valid: true };
    }
    
    supportsRefund(): boolean { return true; }
    
    async processRefund(paymentId: string, amount: Money): Promise<RefundResult> {
        const refund = await this.stripeClient.refunds.create({
            charge: paymentId,
            amount: amount.cents,
        });
        return { success: true, refundId: refund.id };
    }
}
 
class PayPalPaymentProcessor implements PaymentProcessor {
    // PayPal-specific implementation
}
 
class CryptoPaymentProcessor implements PaymentProcessor {
    // Cryptocurrency-specific implementation  
}
 
// Usage in checkout service
class CheckoutService {
    constructor(
        private readonly processorFactory: PaymentProcessorFactory
    ) {}
    
    async checkout(cart: Cart, method: PaymentMethod): Promise<OrderResult> {
        const processor = this.processorFactory.getProcessor(method);
        const validation = processor.validatePaymentDetails(cart.paymentDetails);
        
        if (!validation.valid) {
            throw new InvalidPaymentDetailsError(validation.errors);
        }
        
        const result = await processor.processPayment(cart.total, cart.context);
        return this.completeOrder(cart, result);
    }
}

Common Pattern Matching Mistakes

Even with systematic processes, pattern matching has pitfalls. Here are the most common mistakes and how to avoid them:

Mistake 1: Superficial Keyword Matching

•The mistake: 'I have objects observing things, so I need Observer pattern!'
•Why it's wrong: Pattern names are metaphors, not literal descriptions. Having 'observers' in your domain doesn't mean you need the Observer pattern.
•The fix: Match problem characteristics, not vocabulary. Ask: Do I have a one-to-many dependency where changes in one object should automatically notify multiple others with unknown registration?

Mistake 2: Pattern Jealousy

•The mistake: 'This project needs more patterns. Let me find places to add some.'
•Why it's wrong: Patterns solve problems; they don't make code better by mere presence. Seeking pattern opportunities is backwards thinking.
•The fix: Never start with 'Where can I use a pattern?' Always start with 'What problem am I solving?'

Mistake 3: Ignoring Simpler Alternatives

•The mistake: Jumping to patterns when language features or simple approaches work fine.
•Why it's wrong: A switch statement with three cases doesn't need Strategy. A function with two implementations doesn't need Factory.
•The fix: Always ask 'What's the simplest solution?' If it adequately addresses the requirements, use it.

Mistake 4: Confusing Similar Patterns

•The mistake: Mixing up Strategy/State, Factory/Builder, Adapter/Facade when they serve different purposes.
•Why it's wrong: These patterns solve different problems despite superficial similarities.
•The fix: Learn the intent distinctions: Strategy swaps algorithms; State manages state-dependent behavior. Factory creates objects; Builder constructs complex objects step-by-step.

The Pattern Comparison Technique

When unsure between similar patterns, ask: 'What is the core problem each pattern solves?' If you can articulate this distinction, you'll match correctly. Strategy: varying algorithms. State: state-dependent behavior changes. Decorator: adding responsibilities. Adapter: interface translation.

Building Pattern Intuition

Pattern matching ultimately becomes intuitive—experienced engineers 'see' patterns in problems without conscious analysis. This intuition develops through deliberate practice:

Practice Method 1: Retrospective Pattern Analysis

Take well-designed open-source projects and analyze their pattern usage:

Identify a design decision that seems elegant
Ask: What problem does this solve?
Does it match a known pattern?
If yes, was the pattern necessary? What alternatives existed?
If no pattern is visible, would one have helped?

Practice Method 2: Code Smell to Pattern Mapping

Certain code smells suggest pattern opportunities. Learn to recognize them:

Code Smells That Suggest Patterns
Code Smell	What It Suggests	Potential Pattern
Switch/if-else on type	Type-dependent behavior	Strategy, State, or polymorphism
Subclass explosion	Combinations of variations	Decorator, Bridge, or Strategy
Complex object construction	Too many constructor parameters	Builder
`new` scattered throughout code	Tight coupling to concrete classes	Factory Method, Abstract Factory
Many classes referencing each other	High coupling, change ripples	Mediator, Facade
Checking null before operations	Optional behavior or lazy loading	Null Object, Proxy
Duplicate code in hierarchies	Template with variation points	Template Method

Practice Method 3: Problem-First Exercises

Given a problem description, practice the matching process:

E-commerce discount system: Discounts can be percentage-based, fixed-amount, buy-one-get-one, or tiered. They can stack in specific ways.
- Analysis: Algorithm variation (Strategy), potentially Decorator for stacking, Chain of Responsibility for ordered application.
Document editor undo/redo: Users should be able to undo any action and redo undone actions. Some actions are compound (multiple operations).
- Analysis: Clearly Command pattern for encapsulating operations. Memento for state snapshots if needed.
Plugin system for IDE: Third parties should be able to add new functionality without modifying core code. Plugins can extend multiple extension points.
- Analysis: Observer for event-based extensions, Strategy for pluggable implementations, Factory for plugin instantiation.

Intuition Is Compressed Experience

What feels like intuition is actually pattern matching against accumulated examples. The more problems you analyze, the more problem shapes you recognize. There's no shortcut—only deliberate practice over time.

Multi-Pattern Recognition

Real problems often require multiple patterns working together. Recognizing these compound scenarios is an advanced skill that comes with experience.

Common Pattern Combinations

Frequently Combined Patterns
Combination	Use Case	How They Complement
Factory + Strategy	Creating varying algorithm instances	Factory creates the appropriate Strategy implementation
Composite + Visitor	Operations on tree structures	Composite defines structure; Visitor adds operations
Observer + Command	Undoable event-driven systems	Observer notifies; Command encapsulates undoable actions
Decorator + Strategy	Configurable, stackable behaviors	Decorators add responsibilities; Strategies vary algorithms
Factory + Prototype	Complex object hierarchies	Factory determines what to create; Prototype clones it
State + Singleton	Application-wide state machine	State manages transitions; Singleton ensures single state context

multi-pattern-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// Example: Factory + Strategy + Decorator combination
// Problem: Report generation with multiple formats, optional features, 
// and runtime format selection
 
// Strategy: Different output formats
interface ReportFormatter {
    format(data: ReportData): string;
}
 
class PDFFormatter implements ReportFormatter {
    format(data: ReportData): string { /* PDF generation */ }
}
 
class ExcelFormatter implements ReportFormatter {
    format(data: ReportData): string { /* Excel generation */ }
}
 
// Decorator: Optional features layered on top
abstract class ReportFormatterDecorator implements ReportFormatter {
    constructor(protected readonly wrapped: ReportFormatter) {}
    format(data: ReportData): string {
        return this.wrapped.format(data);
    }
}
 
class EncryptedFormatter extends ReportFormatterDecorator {
    format(data: ReportData): string {
        const output = this.wrapped.format(data);
        return this.encrypt(output);
    }
    private encrypt(content: string): string { /* encryption logic */ }
}
 
class CompressedFormatter extends ReportFormatterDecorator {
    format(data: ReportData): string {
        const output = this.wrapped.format(data);
        return this.compress(output);
    }
    private compress(content: string): string { /* compression logic */ }
}
 
// Factory: Creates the appropriate stack based on configuration
class ReportFormatterFactory {
    create(config: ReportConfig): ReportFormatter {
        // Base formatter from strategy selection
        let formatter: ReportFormatter = this.createBaseFormatter(config.format);
        
        // Layer decorators based on options
        if (config.encrypted) {
            formatter = new EncryptedFormatter(formatter);
        }
        if (config.compressed) {
            formatter = new CompressedFormatter(formatter);
        }
        
        return formatter;
    }
    
    private createBaseFormatter(format: FormatType): ReportFormatter {
        switch (format) {
            case 'pdf': return new PDFFormatter();
            case 'excel': return new ExcelFormatter();
            default: throw new Error(`Unknown format: ${format}`);
        }
    }
}
 
// Usage: Clean client code despite underlying complexity
const factory = new ReportFormatterFactory();
const formatter = factory.create({ 
    format: 'pdf', 
    encrypted: true, 
    compressed: true 
});
const output = formatter.format(reportData);

Avoid Pattern Stacking for Its Own Sake

Multi-pattern solutions are powerful but carry multiplicative complexity. Only combine patterns when each solves a distinct, genuine problem. 'We might need this flexibility someday' is not justification for pattern stacking.

Summary: Problem-Pattern Matching

Pattern matching is a learnable skill that transforms pattern knowledge from academic to practical. Let's consolidate the key insights:

Key Takeaways

•Decompose problems into categories: Is it about creation, structure, or behavior? This immediately eliminates most patterns from consideration.
•Identify the design tension: Articulate what makes a simple solution inadequate. The tension points to applicable patterns.
•Learn problem signatures: Each pattern addresses problems with distinctive characteristics. Memorize these signatures.
•Use a systematic process: Problem description → Category identification → Tension articulation → Signature matching → Verification.
•Avoid common mistakes: Don't match by vocabulary, seek patterns for their own sake, ignore simpler alternatives, or confuse similar patterns.
•Build intuition through practice: Analyze open-source code, map code smells to patterns, and work through problem-first exercises.
•Recognize compound scenarios: Real problems often require multiple patterns working together with clear responsibilities.

Next up: With pattern matching skills developing, we'll explore the dangers of premature pattern application—why waiting to introduce patterns is often wiser than applying them early, and how to recognize when the time is right.

Page Complete

You now have a systematic approach to matching problems with patterns. The five-step process—describe, categorize, identify tension, match signatures, verify—transforms pattern selection from guesswork into disciplined analysis. Next, we'll explore why premature patterns are dangerous and how to time pattern introduction correctly.