System Design (LLD)Pattern Categories

Pattern Categories: Creational, Structural, Behavioral

LevelIntermediate

Duration60 mins

TopicPattern Categories

4 / 4

Categorization Purpose — Why the Taxonomy Matters

Beyond Learning Patterns: Using the Taxonomy

You've now surveyed the three categories of design patterns: Creational, Structural, and Behavioral. But understanding the taxonomy is not merely academic organization—it's a cognitive tool that fundamentally changes how you approach design challenges.

The categorization serves multiple strategic purposes:

It reduces the overwhelming catalog of patterns into navigable groups
It provides a diagnostic framework: identify the type of problem before searching for specific patterns
It establishes a shared vocabulary for architectural discussions
It reveals relationships between patterns within and across categories

This page explores the practical value of the pattern taxonomy and how to leverage it for faster, more confident design decisions.

What You Will Learn

By the end of this page, you'll understand how to use the Creational-Structural-Behavioral framework as a decision-making tool. You'll learn to diagnose design problems by category, navigate pattern selection efficiently, and communicate design intent using the taxonomy's vocabulary.

The Cognitive Load Problem

The Gang of Four documented 23 patterns. Since then, dozens more have emerged: patterns for concurrency, enterprise applications, domain-driven design, microservices, and functional programming. Confronted with this catalog, developers face a classic cognitive overload problem:

The memorization trap:

Trying to memorize all patterns and their applications is:

Overwhelming — Too many patterns, each with nuanced use cases
Fragile — Memorized knowledge without understanding fades quickly
Ineffective — Real design problems rarely match textbook descriptions exactly

The search bottleneck:

When facing a design challenge, linear searching through all known patterns is:

Slow — You must consider and reject many irrelevant patterns
Error-prone — You might miss better solutions or force-fit inappropriate patterns
Frustrating — Analysis paralysis sets in when choices multiply

The Anti-Pattern of Pattern Overuse

Developers who memorize patterns without understanding the taxonomy often over-apply patterns, creating "pattern soup" codebases. Every class becomes a Factory, every collection a Composite, every method call a Command. The taxonomy helps you recognize when patterns are appropriate—and when they're not.

The taxonomic solution:

Categories reduce cognitive load through chunking—the cognitive science principle that information organized into meaningful groups is easier to process and recall. Instead of 23+ independent patterns, you work with three categories, each containing related patterns that share common themes:

Category	Core Question	Typical Symptoms
Creational	How do we create objects?	`new` scattered everywhere; construction complexity; type selection at runtime
Structural	How do we compose objects?	Interface mismatches; complexity to hide; dynamic responsibilities
Behavioral	How do objects cooperate?	Algorithm variation; state-dependent behavior; event propagation

The Diagnostic Framework

The taxonomy provides a systematic approach to pattern selection: first diagnose the category, then explore patterns within that category. This narrows your search space from 23+ patterns to ~5-7 relevant candidates.

Step 1: Identify the Design Tension

Before reaching for any pattern, clearly articulate the problem:

What's currently awkward, fragile, or rigid in the design?
What change or extension is difficult to make?
What coupling or dependency causes the friction?

Step 2: Categorize the Problem

Ask targeted questions to identify the category:

Pattern Category Diagnostic Questions
Question	If Yes, Consider...	Category
Is the problem about which class to instantiate?	Factory Method, Abstract Factory, Prototype	Creational
Is the problem about how to construct a complex object?	Builder, Prototype	Creational
Is the problem about how many instances should exist?	Singleton, Object Pool	Creational
Is the problem about making incompatible things work together?	Adapter, Bridge	Structural
Is the problem about simplifying a complex interface?	Facade	Structural
Is the problem about adding behavior without subclassing?	Decorator, Proxy	Structural
Is the problem about treating composites and individuals uniformly?	Composite	Structural
Is the problem about selecting an algorithm at runtime?	Strategy	Behavioral
Is the problem about object behavior changing based on state?	State	Behavioral
Is the problem about notifying dependents of changes?	Observer	Behavioral
Is the problem about encapsulating operations for undo/queue/log?	Command	Behavioral
Is the problem about defining an algorithm skeleton with variable steps?	Template Method	Behavioral

The 80/20 Rule of Pattern Selection

In practice, about 80% of pattern applications involve just 6-8 patterns: Factory (Method or Abstract), Strategy, Observer, Decorator, Facade, Adapter, Command, and Composite. Master these thoroughly before worrying about the full catalog. The taxonomy helps you quickly determine which of these common patterns applies.

Cross-Category Pattern Composition

Real systems rarely need just one pattern. Complex designs often combine patterns from different categories, each solving a different aspect of the overall challenge. Understanding the taxonomy helps you recognize natural pattern combinations.

Common Cross-Category Collaborations:

Pattern Combination Examples

•Abstract Factory + Strategy — Factory creates strategy objects; context uses them. Creation meets behavior.
•Decorator + Factory Method — Factory produces appropriate decorators; composites dynamically stack. Structure meets creation.
•Composite + Visitor — Composite defines structure; Visitor adds operations. Structure enables behavior.
•Observer + Command — Commands are queued and executed; observers react to command completion. Two behavioral patterns orchestrating complex workflows.
•Facade + Singleton + Factory — Singleton facade provides access; internal factory creates subsystem components. All three categories in harmony.

pattern-composition-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
// Cross-category pattern composition: Plugin System
// Combines: Factory (Creational) + Composite (Structural) + Strategy (Behavioral)
 
// Strategy - defines plugin behavior
interface Plugin {
    name: string;
    execute(context: PluginContext): void;
    getPriority(): number;
}
 
// Composite - plugins can be grouped
interface PluginContainer extends Plugin {
    addPlugin(plugin: Plugin): void;
    removePlugin(plugin: Plugin): void;
    getPlugins(): Plugin[];
}
 
class PluginGroup implements PluginContainer {
    private plugins: Plugin[] = [];
    name: string;
    
    constructor(name: string) {
        this.name = name;
    }
    
    addPlugin(plugin: Plugin): void {
        this.plugins.push(plugin);
        // Sort by priority
        this.plugins.sort((a, b) => b.getPriority() - a.getPriority());
    }
    
    removePlugin(plugin: Plugin): void {
        this.plugins = this.plugins.filter(p => p !== plugin);
    }
    
    getPlugins(): Plugin[] { return this.plugins; }
    
    // Execute all plugins in order (composite behavior)
    execute(context: PluginContext): void {
        this.plugins.forEach(plugin => plugin.execute(context));
    }
    
    getPriority(): number {
        return Math.max(...this.plugins.map(p => p.getPriority()), 0);
    }
}
 
// Factory - creates plugins by name
interface PluginFactory {
    createPlugin(type: string, config: PluginConfig): Plugin;
    getAvailableTypes(): string[];
}
 
class DefaultPluginFactory implements PluginFactory {
    private creators: Map<string, (config: PluginConfig) => Plugin> = new Map();
    
    register(type: string, creator: (config: PluginConfig) => Plugin): void {
        this.creators.set(type, creator);
    }
    
    createPlugin(type: string, config: PluginConfig): Plugin {
        const creator = this.creators.get(type);
        if (!creator) {
            throw new Error(`Unknown plugin type: ${type}`);
        }
        return creator(config);
    }
    
    getAvailableTypes(): string[] {
        return Array.from(this.creators.keys());
    }
}
 
// Usage: All patterns work together
const factory = new DefaultPluginFactory();
 
// Register plugin creators (Factory pattern)
factory.register("logging", (config) => new LoggingPlugin(config));
factory.register("caching", (config) => new CachingPlugin(config));
factory.register("validation", (config) => new ValidationPlugin(config));
 
// Build plugin structure (Composite pattern)
const rootGroup = new PluginGroup("Root");
const preprocessors = new PluginGroup("Preprocessors");
const postprocessors = new PluginGroup("Postprocessors");
 
// Factory creates, Composite organizes
preprocessors.addPlugin(factory.createPlugin("validation", { strict: true }));
postprocessors.addPlugin(factory.createPlugin("logging", { level: "debug" }));
postprocessors.addPlugin(factory.createPlugin("caching", { ttl: 3600 }));
 
rootGroup.addPlugin(preprocessors);
rootGroup.addPlugin(postprocessors);
 
// Execute all (Strategy pattern - each plugin has its own execute behavior)
rootGroup.execute(new PluginContext({ request: "..." }));

The Design Patterns Matrix

When designing complex systems, think of patterns as a matrix: the vertical axis is categories (Creational, Structural, Behavioral), and the horizontal axis is specific patterns. Good designs often touch multiple cells in this matrix, each pattern addressing its respective concern while collaborating with others.

Communication and Shared Vocabulary

Perhaps the most practical value of the taxonomy is as a communication tool. Design patterns provide a shared vocabulary that compresses complex architectural concepts into single terms. The categories add another layer of precision.

Without pattern vocabulary:

"So we need this thing that creates the right kind of database connection based on whether we're in production or testing, and it should make sure there's only one connection pool, and when we create connections they should be wrapped in something that logs all queries..."

With pattern vocabulary:

"We'll use a Factory to create database connections, with configuration for production and test profiles. The connection pool will be a Singleton, and we'll apply a Logging Decorator to each connection."

Category-Level Communication:

Categories enable even higher-level discussions:

"We have a creational problem here" — Signals that the design challenge involves object instantiation
"This is structural" — Indicates the issue is about how components connect or compose
"We need a behavioral solution" — Points to algorithm distribution or object communication

This vocabulary accelerates design sessions, code reviews, and technical documentation.

Benefits of Pattern Vocabulary

•Compression — One word replaces paragraphs of explanation
•Precision — Patterns have agreed-upon definitions
•Speed — Teams aligned on vocabulary move faster
•Documentation — Pattern names in code are self-documenting
•Onboarding — New team members can look up pattern details

Vocabulary Pitfalls

•Assumed knowledge — Verify the audience knows the pattern
•Imprecise usage — Don't call everything a "Factory"
•Over-formalism — Simple solutions don't need pattern names
•Gatekeeping — Don't use vocabulary to exclude or intimidate
•Pattern worship — Patterns serve design, not vice versa

Pattern Relationships Within Categories

Patterns within the same category often have relationships—they may be alternatives, complements, or evolutionary stages. Understanding these relationships helps you choose the right pattern level for your problem.

Creational Pattern Relationships:

Creational Pattern Comparisons
Relationship	Patterns	Use Case Distinction
Alternatives	Factory Method vs. Abstract Factory	One product type vs. product families
Alternatives	Prototype vs. Factory	Clone from template vs. create from scratch
Complementary	Builder + Abstract Factory	Factory selects components; Builder assembles them
Specialized	Singleton (subset of Factory)	Factory that always returns the same instance

Structural Pattern Relationships:

Relationship	Patterns	Use Case Distinction
Similar mechanism	Adapter vs. Decorator vs. Proxy	Different intents: compatibility, extension, control
Organizational	Facade vs. Mediator	Facade simplifies; Mediator coordinates
Complementary	Composite + Flyweight	Composite for structure; Flyweight for shared leaf state
Hierarchy	Bridge generalizes Adapter	Bridge is designed in; Adapter fixes after

Behavioral Pattern Relationships:

Relationship	Patterns	Use Case Distinction
Often confused	Strategy vs. State	Who controls transition? (Client vs. State itself)
Closely related	Command + Memento	Command stores operation; Memento stores state
Alternative traversal	Iterator vs. Visitor	Sequential access vs. operation application
Communication styles	Observer vs. Mediator	Direct broadcast vs. centralized routing
Algorithm structure	Template Method vs. Strategy	Inheritance vs. composition

Evolving Patterns

Designs often evolve through patterns. A hardcoded algorithm becomes a Strategy. A simple object becomes decorated with additional responsibilities. A component grows and needs a Facade. Recognizing how patterns relate helps you plan for and execute these evolutions gracefully.

Applying the Taxonomy in Practice

Let's walk through a practical scenario demonstrating how the taxonomy guides design decisions.

Scenario: Building an E-Commerce Notification System

Requirements:

Send notifications through multiple channels (email, SMS, push)
Support different message formats per channel
Allow users to subscribe/unsubscribe from notification types
Log all notifications for audit
Support batching for bulk operations

Step 1: Break Down into Design Challenges

Decomposing Requirements by Category
Requirement	Design Question	Category	Candidate Patterns
Multiple channels	How do we create the right sender?	Creational	Factory Method, Abstract Factory
Different formats	How do we adapt messages to channels?	Structural	Adapter, Strategy
Subscribe/unsubscribe	How do users get notified?	Behavioral	Observer
Audit logging	How do we add logging transparently?	Structural	Decorator, Proxy
Batching	How do we handle single vs. batch?	Structural	Composite + Strategy

taxonomy-application-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
// Notification System - Pattern Selection Guided by Taxonomy
 
// BEHAVIORAL: Observer - manages subscriptions
interface NotificationObserver {
    onNotification(event: NotificationEvent): void;
}
 
class NotificationSubscriptionManager {
    private subscribers: Map<NotificationType, Set<NotificationObserver>> = new Map();
    
    subscribe(type: NotificationType, observer: NotificationObserver): void {
        if (!this.subscribers.has(type)) {
            this.subscribers.set(type, new Set());
        }
        this.subscribers.get(type)!.add(observer);
    }
    
    notify(event: NotificationEvent): void {
        this.subscribers.get(event.type)?.forEach(observer => {
            observer.onNotification(event);
        });
    }
}
 
// CREATIONAL: Abstract Factory - creates channel-specific components
interface NotificationChannelFactory {
    createSender(): NotificationSender;
    createFormatter(): MessageFormatter;
}
 
class EmailChannelFactory implements NotificationChannelFactory {
    createSender(): NotificationSender { return new EmailSender(); }
    createFormatter(): MessageFormatter { return new HTMLEmailFormatter(); }
}
 
class SMSChannelFactory implements NotificationChannelFactory {
    createSender(): NotificationSender { return new SMSSender(); }
    createFormatter(): MessageFormatter { return new PlainTextFormatter(); }
}
 
// BEHAVIORAL: Strategy - interchangeable formatting
interface MessageFormatter {
    format(notification: Notification): string;
}
 
class HTMLEmailFormatter implements MessageFormatter {
    format(notification: Notification): string {
        return `<h1>${notification.title}</h1><p>${notification.body}</p>`;
    }
}
 
class PlainTextFormatter implements MessageFormatter {
    format(notification: Notification): string {
        return `${notification.title}
 
${notification.body}`;
    }
}
 
// STRUCTURAL: Decorator - adds logging transparently
interface NotificationSender {
    send(message: string, recipient: string): Promise<void>;
}
 
class EmailSender implements NotificationSender {
    async send(message: string, recipient: string): Promise<void> {
        console.log(`Sending email to ${recipient}`);
    }
}
 
class LoggingDecorator implements NotificationSender {
    constructor(private wrapped: NotificationSender, private logger: AuditLogger) {}
    
    async send(message: string, recipient: string): Promise<void> {
        await this.logger.log({ recipient, timestamp: new Date(), messageHash: hash(message) });
        await this.wrapped.send(message, recipient);
        await this.logger.log({ recipient, timestamp: new Date(), status: "sent" });
    }
}
 
// STRUCTURAL: Composite - handles single and batch uniformly
interface NotificationTarget {
    getRecipients(): string[];
}
 
class SingleRecipient implements NotificationTarget {
    constructor(private email: string) {}
    getRecipients(): string[] { return [this.email]; }
}
 
class RecipientGroup implements NotificationTarget {
    private members: NotificationTarget[] = [];
    
    add(target: NotificationTarget): void { this.members.push(target); }
    
    getRecipients(): string[] {
        return this.members.flatMap(m => m.getRecipients());
    }
}
 
// Orchestrating all patterns together
class NotificationService {
    constructor(
        private subscriptionManager: NotificationSubscriptionManager,
        private channelFactories: Map<Channel, NotificationChannelFactory>
    ) {}
    
    async sendNotification(
        notification: Notification,
        channel: Channel,
        target: NotificationTarget
    ): Promise<void> {
        const factory = this.channelFactories.get(channel)!;
        const formatter = factory.createFormatter();
        let sender = factory.createSender();
        
        // Apply decorator
        sender = new LoggingDecorator(sender, new AuditLogger());
        
        const message = formatter.format(notification);
        
        // Composite handles single or batch
        for (const recipient of target.getRecipients()) {
            await sender.send(message, recipient);
        }
        
        // Notify observers
        this.subscriptionManager.notify({
            type: notification.type,
            timestamp: new Date()
        });
    }
}

Common Mistakes in Pattern Selection

Understanding the taxonomy helps you avoid common pattern selection errors:

Pattern Selection Anti-Patterns

•Wrong Category — Using a Behavioral pattern for a Creational problem. Example: Using Strategy to select which class to instantiate (should be Factory).
•Over-engineering — Applying Abstract Factory when Factory Method suffices. Categorize first, then use the simplest pattern that solves the problem.
•Pattern Forcing — Having a favorite pattern and applying it everywhere. Let the problem category guide selection.
•Premature Patterns — Adding patterns before the problem manifests. Start simple; introduce patterns when complexity demands them.
•Category Confusion — Confusing similar patterns across categories. Adapter (Structural) vs. Strategy (Behavioral): both involve polymorphism, but Adapter is about interface matching while Strategy is about algorithm selection.

The YAGNI Principle Applies

Don't add patterns speculatively. If you're not sure which category your problem falls into—or whether it's a pattern-level problem at all—you might not need a pattern yet. The taxonomy is a diagnostic tool, not a prescription. Sometimes the simplest solution is no pattern at all.

Beyond the Gang of Four

The Gang of Four's 23 patterns and three categories were documented in 1994. Software development has evolved enormously since then, and so has pattern thinking.

Extended Categories:

Modern pattern catalogs often include additional categories:

Concurrency Patterns — Thread Pool, Read-Write Lock, Double-Checked Locking, Active Object
Architectural Patterns — MVC, MVP, MVVM, Clean Architecture, Hexagonal Architecture
Integration Patterns — Message Router, Content-Based Router, Aggregator, Splitter (Enterprise Integration Patterns)
Cloud Patterns — Circuit Breaker, Saga, Event Sourcing, CQRS, Sidecar
Functional Patterns — Monad, Functor, Lens, Transducer

How the Taxonomy Extends:

These new patterns still fit the fundamental categories:

New Pattern Area	Primary Categories	Example
Concurrency	Creational + Behavioral	Thread Pool (Creational); Producer-Consumer (Behavioral)
Microservices	All three	Service Factory (Creational); API Gateway (Structural); Saga (Behavioral)
Reactive	Behavioral	Observer-based patterns extended for async streams
Functional	Structural + Behavioral	Composition patterns (Structural); Pipeline patterns (Behavioral)

The Creational-Structural-Behavioral framework remains valid—new patterns find their place within it or extend it naturally.

Continuous Learning

The pattern landscape evolves with technology. As you encounter new patterns, use the taxonomy to contextualize them: Is this about object creation? Object composition? Object interaction? This mental model helps you integrate new knowledge with existing understanding, making it easier to learn and apply new patterns.

Summary: The Power of Pattern Taxonomy

The Creational-Structural-Behavioral taxonomy is far more than an organizational convenience—it's a thinking tool that transforms how you approach software design. By understanding pattern categories, you gain a diagnostic framework, a communication vocabulary, and a mental map for navigating the pattern landscape.

Key Takeaways

•Categories reduce cognitive load — Chunk patterns into meaningful groups for faster recall and selection
•Diagnose before prescribing — Identify the category of your problem before comparing specific patterns
•Patterns compose across categories — Real designs combine Creational, Structural, and Behavioral patterns
•The taxonomy is a communication tool — Category-level vocabulary enables precise, efficient design discussions
•Understand pattern relationships — Know when patterns are alternatives, complements, or evolutionary steps
•The taxonomy extends naturally — New patterns fit into or extend the fundamental categories
•Use patterns appropriately — The taxonomy helps you avoid over-engineering and category confusion

Module Complete

You now understand the three fundamental design pattern categories and why this taxonomy matters for practical software design. You can diagnose problems by category, navigate pattern options efficiently, and communicate design decisions using a shared vocabulary. In subsequent chapters, you'll dive deep into specific patterns within each category, applying this taxonomic foundation to master individual pattern implementations.

4 / 4

Loading learning content...

System Design (LLD)Pattern Categories

Pattern Categories: Creational, Structural, Behavioral

LevelIntermediate

Duration60 mins

TopicPattern Categories

4 / 4

Categorization Purpose — Why the Taxonomy Matters

Beyond Learning Patterns: Using the Taxonomy

The categorization serves multiple strategic purposes:

It reduces the overwhelming catalog of patterns into navigable groups
It provides a diagnostic framework: identify the type of problem before searching for specific patterns
It establishes a shared vocabulary for architectural discussions
It reveals relationships between patterns within and across categories

This page explores the practical value of the pattern taxonomy and how to leverage it for faster, more confident design decisions.

What You Will Learn

The Cognitive Load Problem

The memorization trap:

Trying to memorize all patterns and their applications is:

Overwhelming — Too many patterns, each with nuanced use cases
Fragile — Memorized knowledge without understanding fades quickly
Ineffective — Real design problems rarely match textbook descriptions exactly

The search bottleneck:

When facing a design challenge, linear searching through all known patterns is:

Slow — You must consider and reject many irrelevant patterns
Error-prone — You might miss better solutions or force-fit inappropriate patterns
Frustrating — Analysis paralysis sets in when choices multiply

The Anti-Pattern of Pattern Overuse

The taxonomic solution:

Category	Core Question	Typical Symptoms
Creational	How do we create objects?	`new` scattered everywhere; construction complexity; type selection at runtime
Structural	How do we compose objects?	Interface mismatches; complexity to hide; dynamic responsibilities
Behavioral	How do objects cooperate?	Algorithm variation; state-dependent behavior; event propagation

The Diagnostic Framework

Step 1: Identify the Design Tension

Before reaching for any pattern, clearly articulate the problem:

What's currently awkward, fragile, or rigid in the design?
What change or extension is difficult to make?
What coupling or dependency causes the friction?

Step 2: Categorize the Problem

Ask targeted questions to identify the category:

Pattern Category Diagnostic Questions
Question	If Yes, Consider...	Category
Is the problem about which class to instantiate?	Factory Method, Abstract Factory, Prototype	Creational
Is the problem about how to construct a complex object?	Builder, Prototype	Creational
Is the problem about how many instances should exist?	Singleton, Object Pool	Creational
Is the problem about making incompatible things work together?	Adapter, Bridge	Structural
Is the problem about simplifying a complex interface?	Facade	Structural
Is the problem about adding behavior without subclassing?	Decorator, Proxy	Structural
Is the problem about treating composites and individuals uniformly?	Composite	Structural
Is the problem about selecting an algorithm at runtime?	Strategy	Behavioral
Is the problem about object behavior changing based on state?	State	Behavioral
Is the problem about notifying dependents of changes?	Observer	Behavioral
Is the problem about encapsulating operations for undo/queue/log?	Command	Behavioral
Is the problem about defining an algorithm skeleton with variable steps?	Template Method	Behavioral

The 80/20 Rule of Pattern Selection

Cross-Category Pattern Composition

Common Cross-Category Collaborations:

Pattern Combination Examples

•Abstract Factory + Strategy — Factory creates strategy objects; context uses them. Creation meets behavior.
•Decorator + Factory Method — Factory produces appropriate decorators; composites dynamically stack. Structure meets creation.
•Composite + Visitor — Composite defines structure; Visitor adds operations. Structure enables behavior.
•Observer + Command — Commands are queued and executed; observers react to command completion. Two behavioral patterns orchestrating complex workflows.
•Facade + Singleton + Factory — Singleton facade provides access; internal factory creates subsystem components. All three categories in harmony.

pattern-composition-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
// Cross-category pattern composition: Plugin System
// Combines: Factory (Creational) + Composite (Structural) + Strategy (Behavioral)
 
// Strategy - defines plugin behavior
interface Plugin {
    name: string;
    execute(context: PluginContext): void;
    getPriority(): number;
}
 
// Composite - plugins can be grouped
interface PluginContainer extends Plugin {
    addPlugin(plugin: Plugin): void;
    removePlugin(plugin: Plugin): void;
    getPlugins(): Plugin[];
}
 
class PluginGroup implements PluginContainer {
    private plugins: Plugin[] = [];
    name: string;
    
    constructor(name: string) {
        this.name = name;
    }
    
    addPlugin(plugin: Plugin): void {
        this.plugins.push(plugin);
        // Sort by priority
        this.plugins.sort((a, b) => b.getPriority() - a.getPriority());
    }
    
    removePlugin(plugin: Plugin): void {
        this.plugins = this.plugins.filter(p => p !== plugin);
    }
    
    getPlugins(): Plugin[] { return this.plugins; }
    
    // Execute all plugins in order (composite behavior)
    execute(context: PluginContext): void {
        this.plugins.forEach(plugin => plugin.execute(context));
    }
    
    getPriority(): number {
        return Math.max(...this.plugins.map(p => p.getPriority()), 0);
    }
}
 
// Factory - creates plugins by name
interface PluginFactory {
    createPlugin(type: string, config: PluginConfig): Plugin;
    getAvailableTypes(): string[];
}
 
class DefaultPluginFactory implements PluginFactory {
    private creators: Map<string, (config: PluginConfig) => Plugin> = new Map();
    
    register(type: string, creator: (config: PluginConfig) => Plugin): void {
        this.creators.set(type, creator);
    }
    
    createPlugin(type: string, config: PluginConfig): Plugin {
        const creator = this.creators.get(type);
        if (!creator) {
            throw new Error(`Unknown plugin type: ${type}`);
        }
        return creator(config);
    }
    
    getAvailableTypes(): string[] {
        return Array.from(this.creators.keys());
    }
}
 
// Usage: All patterns work together
const factory = new DefaultPluginFactory();
 
// Register plugin creators (Factory pattern)
factory.register("logging", (config) => new LoggingPlugin(config));
factory.register("caching", (config) => new CachingPlugin(config));
factory.register("validation", (config) => new ValidationPlugin(config));
 
// Build plugin structure (Composite pattern)
const rootGroup = new PluginGroup("Root");
const preprocessors = new PluginGroup("Preprocessors");
const postprocessors = new PluginGroup("Postprocessors");
 
// Factory creates, Composite organizes
preprocessors.addPlugin(factory.createPlugin("validation", { strict: true }));
postprocessors.addPlugin(factory.createPlugin("logging", { level: "debug" }));
postprocessors.addPlugin(factory.createPlugin("caching", { ttl: 3600 }));
 
rootGroup.addPlugin(preprocessors);
rootGroup.addPlugin(postprocessors);
 
// Execute all (Strategy pattern - each plugin has its own execute behavior)
rootGroup.execute(new PluginContext({ request: "..." }));

The Design Patterns Matrix

Communication and Shared Vocabulary

Without pattern vocabulary:

"So we need this thing that creates the right kind of database connection based on whether we're in production or testing, and it should make sure there's only one connection pool, and when we create connections they should be wrapped in something that logs all queries..."

With pattern vocabulary:

"We'll use a Factory to create database connections, with configuration for production and test profiles. The connection pool will be a Singleton, and we'll apply a Logging Decorator to each connection."

Category-Level Communication:

Categories enable even higher-level discussions:

"We have a creational problem here" — Signals that the design challenge involves object instantiation
"This is structural" — Indicates the issue is about how components connect or compose
"We need a behavioral solution" — Points to algorithm distribution or object communication

This vocabulary accelerates design sessions, code reviews, and technical documentation.

Benefits of Pattern Vocabulary

•Compression — One word replaces paragraphs of explanation
•Precision — Patterns have agreed-upon definitions
•Speed — Teams aligned on vocabulary move faster
•Documentation — Pattern names in code are self-documenting
•Onboarding — New team members can look up pattern details

Vocabulary Pitfalls

•Assumed knowledge — Verify the audience knows the pattern
•Imprecise usage — Don't call everything a "Factory"
•Over-formalism — Simple solutions don't need pattern names
•Gatekeeping — Don't use vocabulary to exclude or intimidate
•Pattern worship — Patterns serve design, not vice versa

Pattern Relationships Within Categories

Creational Pattern Relationships:

Creational Pattern Comparisons
Relationship	Patterns	Use Case Distinction
Alternatives	Factory Method vs. Abstract Factory	One product type vs. product families
Alternatives	Prototype vs. Factory	Clone from template vs. create from scratch
Complementary	Builder + Abstract Factory	Factory selects components; Builder assembles them
Specialized	Singleton (subset of Factory)	Factory that always returns the same instance

Structural Pattern Relationships:

Relationship	Patterns	Use Case Distinction
Similar mechanism	Adapter vs. Decorator vs. Proxy	Different intents: compatibility, extension, control
Organizational	Facade vs. Mediator	Facade simplifies; Mediator coordinates
Complementary	Composite + Flyweight	Composite for structure; Flyweight for shared leaf state
Hierarchy	Bridge generalizes Adapter	Bridge is designed in; Adapter fixes after

Behavioral Pattern Relationships:

Relationship	Patterns	Use Case Distinction
Often confused	Strategy vs. State	Who controls transition? (Client vs. State itself)
Closely related	Command + Memento	Command stores operation; Memento stores state
Alternative traversal	Iterator vs. Visitor	Sequential access vs. operation application
Communication styles	Observer vs. Mediator	Direct broadcast vs. centralized routing
Algorithm structure	Template Method vs. Strategy	Inheritance vs. composition

Evolving Patterns

Applying the Taxonomy in Practice

Let's walk through a practical scenario demonstrating how the taxonomy guides design decisions.

Scenario: Building an E-Commerce Notification System

Requirements:

Send notifications through multiple channels (email, SMS, push)
Support different message formats per channel
Allow users to subscribe/unsubscribe from notification types
Log all notifications for audit
Support batching for bulk operations

Step 1: Break Down into Design Challenges

Decomposing Requirements by Category
Requirement	Design Question	Category	Candidate Patterns
Multiple channels	How do we create the right sender?	Creational	Factory Method, Abstract Factory
Different formats	How do we adapt messages to channels?	Structural	Adapter, Strategy
Subscribe/unsubscribe	How do users get notified?	Behavioral	Observer
Audit logging	How do we add logging transparently?	Structural	Decorator, Proxy
Batching	How do we handle single vs. batch?	Structural	Composite + Strategy

taxonomy-application-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
// Notification System - Pattern Selection Guided by Taxonomy
 
// BEHAVIORAL: Observer - manages subscriptions
interface NotificationObserver {
    onNotification(event: NotificationEvent): void;
}
 
class NotificationSubscriptionManager {
    private subscribers: Map<NotificationType, Set<NotificationObserver>> = new Map();
    
    subscribe(type: NotificationType, observer: NotificationObserver): void {
        if (!this.subscribers.has(type)) {
            this.subscribers.set(type, new Set());
        }
        this.subscribers.get(type)!.add(observer);
    }
    
    notify(event: NotificationEvent): void {
        this.subscribers.get(event.type)?.forEach(observer => {
            observer.onNotification(event);
        });
    }
}
 
// CREATIONAL: Abstract Factory - creates channel-specific components
interface NotificationChannelFactory {
    createSender(): NotificationSender;
    createFormatter(): MessageFormatter;
}
 
class EmailChannelFactory implements NotificationChannelFactory {
    createSender(): NotificationSender { return new EmailSender(); }
    createFormatter(): MessageFormatter { return new HTMLEmailFormatter(); }
}
 
class SMSChannelFactory implements NotificationChannelFactory {
    createSender(): NotificationSender { return new SMSSender(); }
    createFormatter(): MessageFormatter { return new PlainTextFormatter(); }
}
 
// BEHAVIORAL: Strategy - interchangeable formatting
interface MessageFormatter {
    format(notification: Notification): string;
}
 
class HTMLEmailFormatter implements MessageFormatter {
    format(notification: Notification): string {
        return `<h1>${notification.title}</h1><p>${notification.body}</p>`;
    }
}
 
class PlainTextFormatter implements MessageFormatter {
    format(notification: Notification): string {
        return `${notification.title}
 
${notification.body}`;
    }
}
 
// STRUCTURAL: Decorator - adds logging transparently
interface NotificationSender {
    send(message: string, recipient: string): Promise<void>;
}
 
class EmailSender implements NotificationSender {
    async send(message: string, recipient: string): Promise<void> {
        console.log(`Sending email to ${recipient}`);
    }
}
 
class LoggingDecorator implements NotificationSender {
    constructor(private wrapped: NotificationSender, private logger: AuditLogger) {}
    
    async send(message: string, recipient: string): Promise<void> {
        await this.logger.log({ recipient, timestamp: new Date(), messageHash: hash(message) });
        await this.wrapped.send(message, recipient);
        await this.logger.log({ recipient, timestamp: new Date(), status: "sent" });
    }
}
 
// STRUCTURAL: Composite - handles single and batch uniformly
interface NotificationTarget {
    getRecipients(): string[];
}
 
class SingleRecipient implements NotificationTarget {
    constructor(private email: string) {}
    getRecipients(): string[] { return [this.email]; }
}
 
class RecipientGroup implements NotificationTarget {
    private members: NotificationTarget[] = [];
    
    add(target: NotificationTarget): void { this.members.push(target); }
    
    getRecipients(): string[] {
        return this.members.flatMap(m => m.getRecipients());
    }
}
 
// Orchestrating all patterns together
class NotificationService {
    constructor(
        private subscriptionManager: NotificationSubscriptionManager,
        private channelFactories: Map<Channel, NotificationChannelFactory>
    ) {}
    
    async sendNotification(
        notification: Notification,
        channel: Channel,
        target: NotificationTarget
    ): Promise<void> {
        const factory = this.channelFactories.get(channel)!;
        const formatter = factory.createFormatter();
        let sender = factory.createSender();
        
        // Apply decorator
        sender = new LoggingDecorator(sender, new AuditLogger());
        
        const message = formatter.format(notification);
        
        // Composite handles single or batch
        for (const recipient of target.getRecipients()) {
            await sender.send(message, recipient);
        }
        
        // Notify observers
        this.subscriptionManager.notify({
            type: notification.type,
            timestamp: new Date()
        });
    }
}

Common Mistakes in Pattern Selection

Understanding the taxonomy helps you avoid common pattern selection errors:

Pattern Selection Anti-Patterns

•Wrong Category — Using a Behavioral pattern for a Creational problem. Example: Using Strategy to select which class to instantiate (should be Factory).
•Over-engineering — Applying Abstract Factory when Factory Method suffices. Categorize first, then use the simplest pattern that solves the problem.
•Pattern Forcing — Having a favorite pattern and applying it everywhere. Let the problem category guide selection.
•Premature Patterns — Adding patterns before the problem manifests. Start simple; introduce patterns when complexity demands them.
•Category Confusion — Confusing similar patterns across categories. Adapter (Structural) vs. Strategy (Behavioral): both involve polymorphism, but Adapter is about interface matching while Strategy is about algorithm selection.

The YAGNI Principle Applies

Beyond the Gang of Four

The Gang of Four's 23 patterns and three categories were documented in 1994. Software development has evolved enormously since then, and so has pattern thinking.

Extended Categories:

Modern pattern catalogs often include additional categories:

Concurrency Patterns — Thread Pool, Read-Write Lock, Double-Checked Locking, Active Object
Architectural Patterns — MVC, MVP, MVVM, Clean Architecture, Hexagonal Architecture
Integration Patterns — Message Router, Content-Based Router, Aggregator, Splitter (Enterprise Integration Patterns)
Cloud Patterns — Circuit Breaker, Saga, Event Sourcing, CQRS, Sidecar
Functional Patterns — Monad, Functor, Lens, Transducer

How the Taxonomy Extends:

These new patterns still fit the fundamental categories:

New Pattern Area	Primary Categories	Example
Concurrency	Creational + Behavioral	Thread Pool (Creational); Producer-Consumer (Behavioral)
Microservices	All three	Service Factory (Creational); API Gateway (Structural); Saga (Behavioral)
Reactive	Behavioral	Observer-based patterns extended for async streams
Functional	Structural + Behavioral	Composition patterns (Structural); Pipeline patterns (Behavioral)

The Creational-Structural-Behavioral framework remains valid—new patterns find their place within it or extend it naturally.

Continuous Learning

Summary: The Power of Pattern Taxonomy

Key Takeaways

•Categories reduce cognitive load — Chunk patterns into meaningful groups for faster recall and selection
•Diagnose before prescribing — Identify the category of your problem before comparing specific patterns
•Patterns compose across categories — Real designs combine Creational, Structural, and Behavioral patterns
•The taxonomy is a communication tool — Category-level vocabulary enables precise, efficient design discussions
•Understand pattern relationships — Know when patterns are alternatives, complements, or evolutionary steps
•The taxonomy extends naturally — New patterns fit into or extend the fundamental categories
•Use patterns appropriately — The taxonomy helps you avoid over-engineering and category confusion

Module Complete

4 / 4