Pattern as Solution to Specific Problem - When to Use Design Patterns | OneNoughtOne

0/290

System Design (HLD)When to Use Patterns

When to Use Design Patterns

LevelIntermediate

Duration60 mins

TopicWhen to Use Patterns

1 / 4

Pattern as Solution to Specific Problem

The Pattern Paradox

There's a peculiar phenomenon in software engineering circles: developers who have just learned about design patterns suddenly see opportunities to apply them everywhere. A simple configuration reader becomes a Strategy pattern. A straightforward object creation becomes an Abstract Factory. A basic conditional becomes a State machine.

This enthusiasm is understandable—patterns are intellectually fascinating, and knowing them feels empowering. But here's the uncomfortable truth that experienced engineers eventually learn:

The hallmark of pattern mastery isn't knowing how to apply patterns—it's knowing when NOT to.

The Most Common Pattern Mistake

The most frequent design pattern mistake isn't applying the wrong pattern—it's applying a pattern when none was needed. Patterns add indirection, complexity, and cognitive overhead. They're only justified when they solve a specific, identified problem that outweighs these costs.

This page establishes the foundational principle that will guide all your pattern decisions: patterns exist to solve problems, not to demonstrate knowledge. We'll explore what it means to think problem-first, how to recognize when a pattern is truly warranted, and why the most expert pattern users are often the most restrained in their application.

The Problem-First Philosophy

Design patterns did not emerge from theoretical computer science research or academic speculation. They emerged from observation—practitioners noticing that the same structural solutions kept appearing across different projects, domains, and even programming languages.

The Gang of Four, who catalogued the original 23 patterns, explicitly stated in their seminal book:

"The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context."

Note the key phrase: solve a general design problem. Patterns are solutions—not goals, not architectural badges, not proof of engineering sophistication. They're tools that exist because specific recurring problems demanded structured responses.

The Problem Must Precede the Pattern

Before reaching for any pattern, you must be able to articulate the specific problem you're solving. If you cannot clearly describe the design challenge—in terms of flexibility needed, coupling to reduce, or behavior to encapsulate—you don't have a pattern opportunity. You have premature abstraction.

The Anatomy of a Pattern Problem

Every pattern addresses a specific category of design tension. To determine if a pattern applies, you must first recognize that tension in your code. Here's how pattern problems typically manifest:

Design Problems and Their Pattern Solutions
Design Problem	Symptom in Code	Pattern Category
Need to create objects without specifying concrete classes	Client code littered with `new ConcreteClass()` that should be configurable	Creational (Factory, Abstract Factory)
Algorithm should vary independently of clients	Multiple if/else or switch statements choosing algorithm at runtime	Behavioral (Strategy)
Multiple objects need to respond to state changes	Manual notification code scattered across the codebase	Behavioral (Observer)
Need to add responsibilities dynamically	Explosion of subclasses for every combination of features	Structural (Decorator)
Complex subsystem needs simpler interface	Client code depends on numerous classes for simple operations	Structural (Facade)
Need to ensure only one instance exists	Global variables or manual singleton logic repeated	Creational (Singleton)
Object behavior depends on its state	Complex state-dependent conditionals throughout the class	Behavioral (State)

The Problem Identification Discipline

Before applying any pattern, experienced engineers go through a mental checklist:

What specific problem am I solving? (If you can't articulate it, stop.)
Is this a recurring problem? (Will it appear elsewhere in this codebase?)
What happens if I don't use a pattern? (Is the simple solution actually sufficient?)
Does the problem justify the pattern's complexity? (Will the cure be worse than the disease?)
Is the pattern addressing current needs or speculative future needs? (YAGNI applies to patterns too.)

Only when you can answer these questions definitively should you proceed with pattern application.

Understanding Pattern Context

Every design pattern in the Gang of Four catalog includes a critical section called "Applicability"—the circumstances under which the pattern should be applied. This section is not decorative; it's definitional. A pattern divorced from its applicability context is just abstract structure with no guaranteed benefit.

Let's examine what proper context analysis looks like:

context-analysis-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
// ❌ WRONG: Pattern applied without context
// Developer thinks: "I have object creation, so I need a Factory!"
 
// Premature abstraction - only one type of payment processor exists
interface PaymentProcessorFactory {
    createProcessor(): PaymentProcessor;
}
 
class StripeProcessorFactory implements PaymentProcessorFactory {
    createProcessor(): PaymentProcessor {
        return new StripeProcessor();
    }
}
 
// This factory adds complexity but solves no problem
// There's no second payment processor, no configuration requirement,
// no need for runtime swapping
 
// ✅ RIGHT: Pattern applied with identified context
// Problem: We support multiple payment gateways (Stripe, PayPal, Square)
// Problem: Gateway selection happens at runtime based on merchant config
// Problem: New gateways added regularly; can't modify existing code each time
 
interface PaymentProcessorFactory {
    createProcessor(config: MerchantConfig): PaymentProcessor;
}
 
class PaymentProcessorFactoryImpl implements PaymentProcessorFactory {
    private readonly factories = new Map<GatewayType, () => PaymentProcessor>();
    
    registerGateway(type: GatewayType, factory: () => PaymentProcessor): void {
        this.factories.set(type, factory);
    }
    
    createProcessor(config: MerchantConfig): PaymentProcessor {
        const factory = this.factories.get(config.gateway);
        if (!factory) {
            throw new UnsupportedGatewayError(config.gateway);
        }
        return factory();
    }
}
 
// Now the pattern serves real purposes:
// 1. New gateways added without modifying factory code
// 2. Runtime selection based on configuration
// 3. Clear extension point for third-party integrations

The Contextual Questions

For each major pattern category, there are specific contextual questions that must be answered affirmatively before application is justified:

Factory Patterns Context Check

•Do you have multiple concrete types? If there's only one implementation with no plan for others, a factory adds no value.
•Is the type determined at runtime? If the type is always known at compile time, direct instantiation is clearer.
•Do creation details need encapsulation? If construction is trivial (new Thing()), there's nothing to encapsulate.
•Will clients need to be isolated from concrete types? If the client naturally knows and depends on the concrete type, factories add indirection without benefit.

Strategy Pattern Context Check

•Do you have multiple algorithms for the same operation? If there's only one algorithm, Strategy is overhead.
•Do algorithms change at runtime or based on context? If the algorithm is fixed, a simple method works better.
•Are the algorithms complex enough to warrant separate classes? Trivial variations don't justify the pattern's weight.
•Do different algorithms have different parameters? Strategy's uniform interface becomes a liability with divergent signatures.

Observer Pattern Context Check

•Do multiple objects need notification of state changes? If only one object cares, direct method calls are cleaner.
•Are observers unknown at compile time or dynamic? If you always notify the same fixed set, a simpler approach works.
•Do you need to add/remove observers at runtime? If the relationship is static, Observer is overkill.
•Is the subject unaware of who observes it? If the subject naturally knows its dependents, direct notification may be clearer.

The Cost-Benefit Calculus

Every design pattern carries costs. These costs are often invisible in tutorials and examples that focus on the pattern's benefits while glossing over its overhead. Professional pattern application requires honest cost-benefit analysis.

The Costs of Pattern Application

Hidden Costs of Design Patterns
Cost Category	Description	Impact
Indirection	Patterns introduce layers between caller and implementation	Harder to trace code flow; debugging becomes more complex
Cognitive Load	Readers must understand the pattern to understand the code	Onboarding time increases; pattern knowledge becomes prerequisite
Boilerplate	Interfaces, abstract classes, and additional files	More code to maintain, test, and keep synchronized
Abstraction Pressure	Patterns push toward abstraction that may not stabilize	Premature abstractions become technical debt
Performance Overhead	Virtual calls, indirection, and additional allocations	Usually negligible but not always—hot paths matter
Evolution Constraints	Patterns constrain how the design can change	Wrong pattern choice locks you into suboptimal structure

The Break-Even Point

Every pattern has a break-even point—the complexity level at which the pattern's benefits exceed its costs. Apply patterns below this threshold, and you've added complexity without benefit. The threshold varies by pattern, team expertise, and project context.

Benefit Categories

To justify a pattern's costs, you need tangible benefits in at least one of these areas:

Legitimate Pattern Benefits

•Variation Encapsulation: The pattern localizes what changes so that adding new variations requires minimal modification to existing code.
•Coupling Reduction: The pattern reduces dependencies between components, making each component more independently testable and modifiable.
•Responsibility Clarification: The pattern makes it clear where specific behaviors live, reducing confusion about code organization.
•Extension Enablement: The pattern creates explicit extension points that make adding new functionality straightforward.
•Communication Enhancement: The pattern provides a shared vocabulary that makes design discussions more efficient.

Pattern Justified When

•Problem is clearly articulated
•Multiple variations exist or are imminent
•Change frequency justifies flexibility
•Team understands the pattern
•Benefits outweigh added complexity
•Pattern solves current needs

Pattern NOT Justified When

•Problem is vague or speculative
•Only one implementation exists
•Code rarely changes
•Team unfamiliar with pattern
•Simple solution works well
•Solving imagined future needs

Case Studies: Appropriate vs. Misguided Pattern Application

Theory becomes concrete through examples. Let's examine real-world scenarios where patterns are appropriately applied versus where they add unnecessary complexity.

Case Study 1: Logging Configuration

A developer needs to support multiple logging destinations (console, file, remote service). Should they use the Strategy pattern?

logging-strategy.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// ✅ APPROPRIATE: Strategy pattern for logging destinations
// Why it's justified:
// 1. Multiple logging strategies exist NOW (console, file, cloud)
// 2. Configuration determines which strategy at runtime
// 3. Strategies may change per environment (dev vs prod)
// 4. New logging destinations will be added (Datadog, Splunk, etc.)
 
interface LoggingStrategy {
    log(level: LogLevel, message: string, context?: LogContext): void;
}
 
class ConsoleLoggingStrategy implements LoggingStrategy {
    log(level: LogLevel, message: string, context?: LogContext): void {
        const formatted = this.format(level, message, context);
        console[level](formatted);
    }
    
    private format(level: LogLevel, message: string, context?: LogContext): string {
        return `[${new Date().toISOString()}] [${level.toUpperCase()}] ${message}`;
    }
}
 
class CloudLoggingStrategy implements LoggingStrategy {
    constructor(private readonly client: CloudLoggingClient) {}
    
    log(level: LogLevel, message: string, context?: LogContext): void {
        this.client.write({
            severity: this.mapLevel(level),
            message,
            labels: context,
            timestamp: new Date(),
        });
    }
    
    private mapLevel(level: LogLevel): CloudSeverity { /* ... */ }
}
 
class Logger {
    constructor(private strategy: LoggingStrategy) {}
    
    setStrategy(strategy: LoggingStrategy): void {
        this.strategy = strategy;
    }
    
    info(message: string, context?: LogContext): void {
        this.strategy.log('info', message, context);
    }
    
    error(message: string, context?: LogContext): void {
        this.strategy.log('error', message, context);
    }
}
 
// Usage: Strategy selected based on configuration
const logger = new Logger(
    config.env === 'production' 
        ? new CloudLoggingStrategy(cloudClient)
        : new ConsoleLoggingStrategy()
);

Case Study 2: User Profile Picture Update

A developer is building a feature to update user profile pictures. They consider using the Command pattern to encapsulate the operation. Is this appropriate?

overengineered-profile.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
// ❌ OVERENGINEERED: Command pattern for simple profile update
// Why it's NOT justified:
// 1. Only one type of profile picture operation (update)
// 2. No undo requirement (users can just upload a new picture)
// 3. No queuing or delayed execution needed
// 4. No macro command aggregation needed
 
interface Command {
    execute(): Promise<void>;
    undo(): Promise<void>;
}
 
class UpdateProfilePictureCommand implements Command {
    private previousPictureUrl: string | null = null;
    
    constructor(
        private readonly userId: string,
        private readonly newPictureUrl: string,
        private readonly userRepository: UserRepository
    ) {}
    
    async execute(): Promise<void> {
        const user = await this.userRepository.findById(this.userId);
        this.previousPictureUrl = user.profilePictureUrl;
        user.profilePictureUrl = this.newPictureUrl;
        await this.userRepository.save(user);
    }
    
    async undo(): Promise<void> {
        if (this.previousPictureUrl === null) return;
        const user = await this.userRepository.findById(this.userId);
        user.profilePictureUrl = this.previousPictureUrl;
        await this.userRepository.save(user);
    }
}
 
// This adds significant complexity for zero benefit
// The undo functionality is never used
// We now have interface, command class, command invoker...
 
// ✅ SIMPLE SOLUTION: Direct service method
class UserProfileService {
    constructor(private readonly userRepository: UserRepository) {}
    
    async updateProfilePicture(userId: string, pictureUrl: string): Promise<void> {
        const user = await this.userRepository.findById(userId);
        user.profilePictureUrl = pictureUrl;
        await this.userRepository.save(user);
    }
}
 
// Clean, simple, does exactly what's needed with no overhead

The Difference Was the Problem

Notice that in both cases, the technical implementation of the pattern would have been similar. The difference was whether a genuine problem existed:

Logging: Multiple destinations, runtime selection, extension needs → Real problem, pattern justified
Profile picture: Single operation, no undo needed, no extension likely → No problem, pattern wastes effort

The pattern isn't inherently good or bad—its appropriateness depends entirely on whether it addresses a genuine design problem.

The Pattern Decision Framework

To systematically determine whether a pattern is appropriate, use this decision framework. It forces explicit reasoning about the problem before jumping to pattern application.

The Pattern Appropriateness Framework

•Problem Identification: Can you describe the design problem in language that doesn't reference patterns? (e.g., "I need to support multiple payment gateways" not "I need a Factory")
•Problem Recurrence: Will this same problem appear in multiple places in this codebase or across projects you work on?
•Simpler Alternative Check: What's the simplest possible solution? Does it adequately address the problem?
•Pattern Fit: Does a known pattern address this exact category of problem? (Check the pattern's stated applicability.)
•Cost Justification: Does the complexity of the pattern (indirection, abstractions, boilerplate) justify the benefit (flexibility, extensibility, clarity)?
•Team Alignment: Does the team understand this pattern, or will it create confusion and onboarding burden?
•Current Need: Are you solving a problem you have NOW, or a speculative future problem?

The Litmus Test

If you can't explain to a colleague why the pattern is necessary using concrete current requirements—not hypothetical future needs—then the pattern probably isn't warranted yet.

Scoring the Decision

When evaluating pattern application, score each factor:

Factor	Score +1 for Pattern	Score -1 Against Pattern
Problem clarity	Clear, specific problem	Vague or speculative
Recurrence	Problem appears 3+ times	One-off situation
Simple alternative	Simple solution inadequate	Simple solution works
Pattern fit	Pattern explicitly addresses this	Pattern tangentially related
Team expertise	Team knows pattern well	Team unfamiliar
Current need	Solving today's problem	Solving tomorrow's maybe-problem

Score 4+ points: Pattern application likely appropriate Score 2-3 points: Reconsider; simple solution may be better Score 1 or less: Do not apply pattern

The Martial Arts of Pattern Mastery

There's a concept in martial arts called Shuhari (守破離), representing three stages of mastery:

Shu (守) — Follow: The student learns the rules and techniques exactly as taught, without deviation.

Ha (破) — Break: The student begins to question the rules, understanding their purpose and when exceptions apply.

Ri (離) — Leave: The student transcends the rules, applying techniques naturally and instinctively, sometimes inventing new approaches.

Design pattern mastery follows the same trajectory:

The Three Stages of Pattern Mastery
Stage	Pattern Behavior	Characteristic Mistakes
Shu (Beginner)	Apply patterns exactly as documented; pattern-first thinking	Over-application; patterns where simple code suffices; rigid adherence to structure
Ha (Intermediate)	Question pattern applicability; examine tradeoffs; adapt patterns	Analysis paralysis; too much meta-discussion about patterns; hybrid patterns that confuse
Ri (Expert)	Patterns emerge naturally from design needs; problem-first thinking	May appear to "not use patterns" because application is so natural it's invisible

The Expert's Perspective

Expert pattern users often give contradictory-sounding advice:

"I rarely think about patterns anymore."

This doesn't mean they don't use patterns—it means patterns have become internalized vocabulary rather than conscious decoration. The expert sees a problem and naturally structures the solution in a way that, if you analyze it, follows a known pattern. But the pattern wasn't the goal; the clean solution was.

This is where we want you to arrive: not as a pattern collector who applies patterns for their own sake, but as a problem-solver whose solutions happen to align with proven patterns because those patterns capture effective design wisdom.

The Goal Is Good Design, Not Pattern Count

A codebase with zero named patterns but clean separation of concerns is superior to a codebase with fifteen named patterns and tangled dependencies. Patterns are a means to good design—never an end in themselves.

Summary: Pattern as Solution

We've established the foundational principle for pattern application: patterns are solutions to specific problems, not decorations for code or demonstrations of knowledge.

Key Takeaways

•Problem-first thinking is essential: Before considering any pattern, articulate the specific design problem you're solving.
•Context determines appropriateness: The same pattern can be essential or wasteful depending on whether its applicability criteria are met.
•Every pattern has costs: Indirection, cognitive load, boilerplate, and abstraction pressure are real costs that must be weighed against benefits.
•Simple solutions deserve preference: If a straightforward approach adequately solves the problem, it's likely better than a pattern.
•Current needs outweigh speculative ones: Apply patterns for today's requirements, not tomorrow's hypothetical needs.
•Mastery means restraint: Expert pattern users are notable for their judicious application, not their pattern enthusiasm.

Next up: With the problem-first philosophy established, we'll explore how to match specific problems to appropriate patterns—the skill of pattern recognition that enables rapid identification of when known solutions apply.

Page Complete

You now understand that patterns exist as solutions to recurring design problems. The decision to apply a pattern should always begin with clear problem identification and end with honest cost-benefit analysis. Next, we'll develop your problem-pattern matching skills.