System Design (HLD)When to Use Patterns

When to Use Design Patterns

LevelIntermediate

Duration60 mins

TopicWhen to Use Patterns

3 / 4

Avoiding Premature Patterns

The Pattern Prediction Trap

There's a seductive logic that leads developers astray: "I can see that we'll probably need flexibility here, so I'll add the pattern now to prepare for it."

This reasoning feels responsible. It seems like good engineering—anticipating future needs, building for extensibility, being proactive. But it's often precisely wrong.

The uncomfortable truth: Most predicted requirements never materialize. Studies of software projects consistently show that features built "just in case" go unused 60-80% of the time. Patterns applied for hypothetical needs become technical debt—complexity with no payoff.

The Cost of Premature Patterns

A premature pattern isn't free even if the predicted need never arrives. You pay maintenance costs on extra classes and interfaces. New team members must understand the pattern to work on the code. Every modification must respect the pattern's contracts. You're taxed continuously for benefits you never receive.

This page examines why premature patterns are so tempting, how to recognize when you're about to apply one, and strategies for deferring pattern decisions until they're genuinely warranted.

Why We Apply Patterns Too Early

Understanding why premature pattern application is so common helps us resist it. Several psychological and professional factors push us toward early abstraction:

Psychological Drivers of Premature Patterns

•Fear of Future Refactoring: We worry that adding a pattern later will be painful, so we add it preemptively. But we overestimate refactoring difficulty with modern tooling.
•Pattern Enthusiasm: Having learned patterns, we want to use them. They're intellectually satisfying. But enthusiasm isn't justification.
•Perceived Professionalism: Patterns feel like "real engineering." Simple code feels like something a junior would write. This is ego, not engineering.
•Resume-Driven Development: We want to work with interesting architectures. Patterns make code more interesting—for us, not necessarily for the problem.
•Planning Fallacy: We believe we can predict future requirements accurately. We can't. Requirements change in ways we don't anticipate.
•Loss Aversion: We fear the regret of not having a pattern when we need it more than we fear the cost of having one we don't need.

The Courage of Simplicity

It takes confidence to write simple code. Any developer can make code complex. Making it simple requires discipline, restraint, and the professional maturity to resist abstraction theater. Simple code that works is not junior—it's masterful.

The "Just In Case" Fallacy

The most dangerous phrase in software design is "just in case."

"Let's add a factory just in case we need other implementations"
"Let's use Strategy just in case the algorithm changes"
"Let's add an abstraction layer just in case we switch databases"

Each "just in case" adds complexity that you pay for immediately while the benefit remains hypothetical. If the predicted need arrives, you were right—but you've been paying the complexity tax the entire time. If it doesn't arrive, you've paid for nothing.

The math rarely favors "just in case." Consider:

Scenario	Pattern Cost	Pattern Benefit
Need arrives (30% chance)	Paid full complexity cost	Benefit received
Need doesn't arrive (70% chance)	Paid full complexity cost	Zero benefit

Expected value is usually negative. Simple code with refactoring ability beats speculative patterns.

Signs You're Being Premature

Learn to recognize the warning signs that you're considering a pattern prematurely. These red flags should trigger reconsideration:

Red Flags for Premature Pattern Application
Red Flag	What It Sounds Like	Why It's Warning
Speculative Language	"We might need...", "In case we...", "What if later..."	Future needs are uncertain. Patterns for speculation are gambles.
Single Implementation	"I'll create an interface for this one class"	Interfaces exist for polymorphism. One implementation = no polymorphism.
Copying Tutorials	"The tutorial used Factory, so I should too"	Tutorials show patterns; they don't mean your problem needs them.
Impressive Architecture	"This will be more enterprise-grade"	Impressiveness is not a design criterion. Solving problems is.
Anticipating Rewrites	"When we rewrite this, we'll need flexibility"	Most predicted rewrites never happen. Don't design for fantasies.
Framework Mimicry	"Spring uses this pattern, so we should"	Frameworks serve different purposes than application code.
One Possible Variation	"There could theoretically be another way..."	Theoretical variation isn't actual variation. Wait for reality.

The One Implementation Problem

The most reliable indicator of a premature pattern is having exactly one implementation.

A Factory that only ever creates one type of object
A Strategy interface with one strategy implementation
An abstract class with one concrete subclass
An event system with one event and one subscriber

These patterns exist to handle multiple variations. With one variation, there's no variation to handle—only abstraction overhead.

one-implementation-smell.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
// ❌ PREMATURE: Factory with single implementation
interface DatabaseConnection {
    query(sql: string): Promise<ResultSet>;
    close(): void;
}
 
interface DatabaseConnectionFactory {
    createConnection(): DatabaseConnection;
}
 
// Only implementation - the interface/factory add nothing
class PostgresConnectionFactory implements DatabaseConnectionFactory {
    createConnection(): DatabaseConnection {
        return new PostgresConnection(this.config);
    }
}
 
// The factory is just ceremony around "new PostgresConnection()"
// No other database is planned or even contemplated
 
// ✅ SIMPLE: Direct usage until variation actually needed
class DatabaseService {
    private connection: PostgresConnection;
    
    constructor(config: PostgresConfig) {
        this.connection = new PostgresConnection(config);
    }
    
    async query(sql: string): Promise<ResultSet> {
        return this.connection.query(sql);
    }
}
 
// If/when MySQL support is ACTUALLY needed:
// 1. Extract interface from PostgresConnection
// 2. Create MySQLConnection implementing interface
// 3. Introduce factory if creation logic warrants it
// 
// This refactoring takes 30 minutes with modern tools
// vs. years of unnecessary abstraction

The Rule of Three

Some developers use the 'rule of three': wait until you have three concrete cases before abstracting. This isn't perfect, but it's better than abstracting at one. Two implementations might share accidental similarity. Three implementations reveal intentional commonality.

The Real Cost of Premature Abstraction

Premature patterns don't just add minimal overhead—they create ongoing costs that compound over time. Let's examine the full impact:

The Hidden Costs of Premature Patterns

•Cognitive Load: Every abstraction layer requires mental effort to understand. New team members must learn patterns before contributing. Code that could be read top-to-bottom now requires jumping between interfaces, implementations, and factories.
•Wrong Abstraction Penalty: When you abstract before understanding, you often abstract at the wrong seam. The predicted flexibility isn't where you need it. Worse, the premature abstraction constrains future design—you've locked in the wrong structure.
•Maintenance Multiplication: Each interface, abstract class, and factory is a file to maintain, test, and update. When the one implementation changes, the interface must change too. You've doubled the work with no benefit.
•Debugging Indirection: Stack traces grow longer. Stepping through code requires navigating layers that exist only for hypothetical flexibility. Finding where behavior actually lives takes longer.
•Evolution Friction: Patterns create structure. Structure resists change. When requirements evolve differently than predicted, you must either work around the pattern or remove it—both are costly.

Case Study: The Abstraction That Backfired

A team anticipated multiple notification channels (email, SMS, push) and built a comprehensive notification system with Strategy pattern, Factory for channel creation, and Observer for subscriber management.

What actually happened: The product only ever used email notifications. But worse, when push notifications were finally added three years later, the requirements were completely different from what the pattern assumed:

Push notifications needed batching (the strategy interface didn't support it)
Different user preferences per notification type (the factory didn't account for this)
Rich media attachments (the channel interface was too narrow)

The "flexible" abstraction was less flexible for actual requirements than simple code would have been. The team spent more time working around the abstraction than they would have spent building from scratch.

The Irony of Speculative Flexibility

Pre-built abstractions often make systems LESS flexible, not more. When you abstract without concrete requirements, you guess at the variation points. When real requirements arrive, they vary along different dimensions than you predicted. You've locked in your guesses.

YAGNI Applied to Patterns

YAGNI—You Aren't Gonna Need It—is the antidote to premature patterns. This principle suggests that you should not add functionality until it's actually needed. Applied to patterns:

Don't apply a pattern until you have concrete evidence that it solves a current problem.

This doesn't mean never use patterns. It means use them reactively rather than speculatively.

YAGNI Pattern Questions

Before applying any pattern, ask:

The YAGNI Pattern Checklist

•Is this solving a problem I have RIGHT NOW? Not a problem I might have. Not a problem similar codebases have. A problem I actually have today.
•Can I name the second implementation? If I'm adding a factory or strategy, the second implementation should exist or be imminent. 'Maybe someday' doesn't count.
•What am I losing by waiting? Usually nothing. Modern refactoring tools make adding patterns later cheap. The cost of waiting is usually near zero.
•What am I gaining by adding now? Be specific. Vague 'flexibility' isn't a gain. Name the concrete benefit.
•Am I solving a requirement or anticipating one? Requirements are documented needs. Anticipated needs are guesses.

The Reversibility Argument

A key YAGNI insight: most pattern additions are reversible decisions. If you don't add a pattern now and need it later, you can add it then. The cost of adding later (refactoring) is usually lower than the cost of maintaining unnecessary abstraction.

This changes the decision calculus dramatically:

Decision	Add Pattern Now	Wait and Add Later if Needed
If need arises	Already have it	Add it then (minor refactoring cost)
If need doesn't arise	Paying ongoing maintenance cost	Zero cost

Unless you're nearly certain the need will arise, waiting is the economically rational choice.

yagni-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
// ❌ YAGNI VIOLATION: Pattern for anticipated need
// "We might want to switch search providers someday"
 
interface SearchProvider {
    search(query: string): Promise<SearchResults>;
}
 
class ElasticSearchProvider implements SearchProvider {
    search(query: string): Promise<SearchResults> {
        return this.client.search({ query });
    }
}
 
// No other provider exists or is planned
// We're paying abstraction costs for "someday"
 
// ✅ YAGNI COMPLIANT: Simple solution now
class ProductSearchService {
    constructor(private readonly elastic: ElasticSearchClient) {}
    
    async search(query: string): Promise<SearchResults> {
        return this.elastic.search({ query });
    }
}
 
// If/when we need to support Algolia:
// Step 1: Extract interface from existing code
// Step 2: Create Algolia implementation
// Step 3: Inject through constructor
// 
// Total refactoring time: ~1 hour
// Cost avoided by waiting: Years of unnecessary abstraction

Trust Your Refactoring Skills

Fear of future refactoring drives premature abstraction. But refactoring is a skill. With practice, extracting interfaces and introducing patterns takes minutes, not hours. Build refactoring confidence, and you'll resist premature patterns more easily.

When Deferral Is Correct

Let's be concrete about when to defer pattern application and what that deferral looks like in practice.

Defer Pattern When

•Only one implementation exists
•Requirements are still being discovered
•The variation point is unclear
•You're copying an architecture from elsewhere
•The simple solution works well
•Nobody has asked for the flexibility
•You're optimizing for hypothetical scale

Apply Pattern Now When

•Multiple implementations exist today
•Requirements explicitly specify flexibility
•The variation point is well understood
•Pattern directly solves current pain
•Simple solution is causing problems
•Stakeholders need the capability now
•Current scale requires it

The Deferral Strategy

Deferral doesn't mean ignoring future needs—it means handling them appropriately:

1. Write simple, clean code: Keep code well-organized even without patterns. Good structure makes pattern introduction easier later.

2. Note potential variation points: Keep a TODO or design document noting where patterns might help if needed. But don't act on it.

3. Watch for the trigger: When you're about to add a second implementation, or when the simple solution starts causing maintenance pain—that's your trigger.

4. Refactor then, not before: When the trigger fires, introduce the pattern. With good tooling and clean existing code, this is usually straightforward.

deferral-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
// Initial state: Simple, direct code
// Note: If we need other report formats, extract interface
class ReportGenerator {
    generate(data: ReportData): PDFDocument {
        return this.buildPDF(data);
    }
    
    private buildPDF(data: ReportData): PDFDocument {
        // PDF generation logic
    }
}
 
// ----- Time passes... -----
 
// Trigger: Business requests Excel export
// Now is the time to introduce Strategy
 
// Step 1: Extract interface from existing code
interface ReportGenerator {
    generate(data: ReportData): Document;
}
 
// Step 2: Rename existing class to be one implementation
class PDFReportGenerator implements ReportGenerator {
    generate(data: ReportData): PDFDocument {
        return this.buildPDF(data);
    }
    
    private buildPDF(data: ReportData): PDFDocument {
        // Existing PDF logic unchanged
    }
}
 
// Step 3: Add new implementation
class ExcelReportGenerator implements ReportGenerator {
    generate(data: ReportData): ExcelDocument {
        return this.buildExcel(data);
    }
    
    private buildExcel(data: ReportData): ExcelDocument {
        // New Excel logic
    }
}
 
// Total time: ~30 minutes
// Benefit: Pattern now serves real need
// We avoided years of unnecessary abstraction

Legitimate Exceptions: When Early Patterns Are Justified

Deferral is the default strategy, but there are legitimate exceptions where early pattern application is justified:

Valid Early Pattern Exceptions

•Testing requirements: When the only way to unit test code is to inject mocks, interfaces are justified even with one implementation. Testing is a current need, not speculation.
•External API boundaries: Wrapping external APIs behind interfaces provides insulation from third-party changes. This is protection, not speculation—APIs do change.
•Contractual extension points: When you're building frameworks or libraries for others to extend, extension points are requirements, not speculation.
•Regulatory/compliance needs: Some compliance frameworks require specific architectural patterns for auditability. This is a real current requirement.
•Well-understood domains: If you've built the same system multiple times and know exactly where variation occurs, that experience counts as evidence.

Exception Abuse Warning

These exceptions can be abused. 'We need it for testing' shouldn't justify every interface. 'It's an external API' doesn't mean every library call needs a wrapper. Apply exceptions honestly, not as loopholes for pattern enthusiasm.

The Testing Exception in Detail

The testing exception deserves elaboration because it's frequently invoked:

Justified: Code that talks to databases, file systems, external services, or system clocks often needs interfaces for mocking in tests. This is a real need.

Not justified: Pure business logic that can be tested directly doesn't need interfaces "for testing." If you can instantiate the class and call its methods, you don't need indirection.

Ask: "Would I add this interface if I weren't thinking about testing?" If yes, proceed. If no, question whether simpler testing approaches exist.

Summary: Avoiding Premature Patterns

Premature pattern application is one of the most common design mistakes. Armed with this understanding, you can resist the temptation:

Key Takeaways

•"Just in case" is a red flag: Patterns applied speculatively have low expected value. Most predicted needs never materialize.
•One implementation means no pattern needed: Patterns handle variation. No variation, no pattern. Wait for the second implementation.
•Premature abstraction is often wrong abstraction: When you abstract without concrete requirements, you guess at the wrong seam.
•YAGNI applies to patterns: Don't add pattern complexity until you have evidence it solves a current problem.
•Refactoring is cheap: Modern tools make introducing patterns later fast and safe. Fear of future refactoring is usually overblown.
•Simple code is not junior code: It takes professional maturity to resist unnecessary abstraction. Simplicity is mastery.
•Exceptions exist but require honesty: Testing, API boundaries, and known domains can justify early patterns—but don't abuse these loopholes.

Next up: We've covered when not to apply patterns early. Now we'll explore the flip side—how to refactor toward patterns when the need genuinely emerges. This completes the pattern application lifecycle: wait, recognize the need, then refactor to patterns.

Page Complete

You now understand why premature patterns are costly and how to resist the temptation to apply them speculatively. The decision to defer is usually correct—and when the need arrives, refactoring is quick. Next, we'll learn how to recognize the right moment and refactor effectively toward patterns.

3 / 4

Loading learning content...

System Design (HLD)When to Use Patterns

When to Use Design Patterns

LevelIntermediate

Duration60 mins

TopicWhen to Use Patterns

3 / 4

Avoiding Premature Patterns

The Pattern Prediction Trap

There's a seductive logic that leads developers astray: "I can see that we'll probably need flexibility here, so I'll add the pattern now to prepare for it."

This reasoning feels responsible. It seems like good engineering—anticipating future needs, building for extensibility, being proactive. But it's often precisely wrong.

The Cost of Premature Patterns

This page examines why premature patterns are so tempting, how to recognize when you're about to apply one, and strategies for deferring pattern decisions until they're genuinely warranted.

Why We Apply Patterns Too Early

Understanding why premature pattern application is so common helps us resist it. Several psychological and professional factors push us toward early abstraction:

Psychological Drivers of Premature Patterns

•Fear of Future Refactoring: We worry that adding a pattern later will be painful, so we add it preemptively. But we overestimate refactoring difficulty with modern tooling.
•Pattern Enthusiasm: Having learned patterns, we want to use them. They're intellectually satisfying. But enthusiasm isn't justification.
•Perceived Professionalism: Patterns feel like "real engineering." Simple code feels like something a junior would write. This is ego, not engineering.
•Resume-Driven Development: We want to work with interesting architectures. Patterns make code more interesting—for us, not necessarily for the problem.
•Planning Fallacy: We believe we can predict future requirements accurately. We can't. Requirements change in ways we don't anticipate.
•Loss Aversion: We fear the regret of not having a pattern when we need it more than we fear the cost of having one we don't need.

The Courage of Simplicity

The "Just In Case" Fallacy

The most dangerous phrase in software design is "just in case."

"Let's add a factory just in case we need other implementations"
"Let's use Strategy just in case the algorithm changes"
"Let's add an abstraction layer just in case we switch databases"

The math rarely favors "just in case." Consider:

Scenario	Pattern Cost	Pattern Benefit
Need arrives (30% chance)	Paid full complexity cost	Benefit received
Need doesn't arrive (70% chance)	Paid full complexity cost	Zero benefit

Expected value is usually negative. Simple code with refactoring ability beats speculative patterns.

Signs You're Being Premature

Learn to recognize the warning signs that you're considering a pattern prematurely. These red flags should trigger reconsideration:

Red Flags for Premature Pattern Application
Red Flag	What It Sounds Like	Why It's Warning
Speculative Language	"We might need...", "In case we...", "What if later..."	Future needs are uncertain. Patterns for speculation are gambles.
Single Implementation	"I'll create an interface for this one class"	Interfaces exist for polymorphism. One implementation = no polymorphism.
Copying Tutorials	"The tutorial used Factory, so I should too"	Tutorials show patterns; they don't mean your problem needs them.
Impressive Architecture	"This will be more enterprise-grade"	Impressiveness is not a design criterion. Solving problems is.
Anticipating Rewrites	"When we rewrite this, we'll need flexibility"	Most predicted rewrites never happen. Don't design for fantasies.
Framework Mimicry	"Spring uses this pattern, so we should"	Frameworks serve different purposes than application code.
One Possible Variation	"There could theoretically be another way..."	Theoretical variation isn't actual variation. Wait for reality.

The One Implementation Problem

The most reliable indicator of a premature pattern is having exactly one implementation.

A Factory that only ever creates one type of object
A Strategy interface with one strategy implementation
An abstract class with one concrete subclass
An event system with one event and one subscriber

These patterns exist to handle multiple variations. With one variation, there's no variation to handle—only abstraction overhead.

one-implementation-smell.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
// ❌ PREMATURE: Factory with single implementation
interface DatabaseConnection {
    query(sql: string): Promise<ResultSet>;
    close(): void;
}
 
interface DatabaseConnectionFactory {
    createConnection(): DatabaseConnection;
}
 
// Only implementation - the interface/factory add nothing
class PostgresConnectionFactory implements DatabaseConnectionFactory {
    createConnection(): DatabaseConnection {
        return new PostgresConnection(this.config);
    }
}
 
// The factory is just ceremony around "new PostgresConnection()"
// No other database is planned or even contemplated
 
// ✅ SIMPLE: Direct usage until variation actually needed
class DatabaseService {
    private connection: PostgresConnection;
    
    constructor(config: PostgresConfig) {
        this.connection = new PostgresConnection(config);
    }
    
    async query(sql: string): Promise<ResultSet> {
        return this.connection.query(sql);
    }
}
 
// If/when MySQL support is ACTUALLY needed:
// 1. Extract interface from PostgresConnection
// 2. Create MySQLConnection implementing interface
// 3. Introduce factory if creation logic warrants it
// 
// This refactoring takes 30 minutes with modern tools
// vs. years of unnecessary abstraction

The Rule of Three

The Real Cost of Premature Abstraction

Premature patterns don't just add minimal overhead—they create ongoing costs that compound over time. Let's examine the full impact:

The Hidden Costs of Premature Patterns

•Cognitive Load: Every abstraction layer requires mental effort to understand. New team members must learn patterns before contributing. Code that could be read top-to-bottom now requires jumping between interfaces, implementations, and factories.
•Wrong Abstraction Penalty: When you abstract before understanding, you often abstract at the wrong seam. The predicted flexibility isn't where you need it. Worse, the premature abstraction constrains future design—you've locked in the wrong structure.
•Maintenance Multiplication: Each interface, abstract class, and factory is a file to maintain, test, and update. When the one implementation changes, the interface must change too. You've doubled the work with no benefit.
•Debugging Indirection: Stack traces grow longer. Stepping through code requires navigating layers that exist only for hypothetical flexibility. Finding where behavior actually lives takes longer.
•Evolution Friction: Patterns create structure. Structure resists change. When requirements evolve differently than predicted, you must either work around the pattern or remove it—both are costly.

Case Study: The Abstraction That Backfired

Push notifications needed batching (the strategy interface didn't support it)
Different user preferences per notification type (the factory didn't account for this)
Rich media attachments (the channel interface was too narrow)

The Irony of Speculative Flexibility

YAGNI Applied to Patterns

YAGNI—You Aren't Gonna Need It—is the antidote to premature patterns. This principle suggests that you should not add functionality until it's actually needed. Applied to patterns:

Don't apply a pattern until you have concrete evidence that it solves a current problem.

This doesn't mean never use patterns. It means use them reactively rather than speculatively.

YAGNI Pattern Questions

Before applying any pattern, ask:

The YAGNI Pattern Checklist

•Is this solving a problem I have RIGHT NOW? Not a problem I might have. Not a problem similar codebases have. A problem I actually have today.
•Can I name the second implementation? If I'm adding a factory or strategy, the second implementation should exist or be imminent. 'Maybe someday' doesn't count.
•What am I losing by waiting? Usually nothing. Modern refactoring tools make adding patterns later cheap. The cost of waiting is usually near zero.
•What am I gaining by adding now? Be specific. Vague 'flexibility' isn't a gain. Name the concrete benefit.
•Am I solving a requirement or anticipating one? Requirements are documented needs. Anticipated needs are guesses.

The Reversibility Argument

This changes the decision calculus dramatically:

Decision	Add Pattern Now	Wait and Add Later if Needed
If need arises	Already have it	Add it then (minor refactoring cost)
If need doesn't arise	Paying ongoing maintenance cost	Zero cost

Unless you're nearly certain the need will arise, waiting is the economically rational choice.

yagni-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
// ❌ YAGNI VIOLATION: Pattern for anticipated need
// "We might want to switch search providers someday"
 
interface SearchProvider {
    search(query: string): Promise<SearchResults>;
}
 
class ElasticSearchProvider implements SearchProvider {
    search(query: string): Promise<SearchResults> {
        return this.client.search({ query });
    }
}
 
// No other provider exists or is planned
// We're paying abstraction costs for "someday"
 
// ✅ YAGNI COMPLIANT: Simple solution now
class ProductSearchService {
    constructor(private readonly elastic: ElasticSearchClient) {}
    
    async search(query: string): Promise<SearchResults> {
        return this.elastic.search({ query });
    }
}
 
// If/when we need to support Algolia:
// Step 1: Extract interface from existing code
// Step 2: Create Algolia implementation
// Step 3: Inject through constructor
// 
// Total refactoring time: ~1 hour
// Cost avoided by waiting: Years of unnecessary abstraction

Trust Your Refactoring Skills

When Deferral Is Correct

Let's be concrete about when to defer pattern application and what that deferral looks like in practice.

Defer Pattern When

•Only one implementation exists
•Requirements are still being discovered
•The variation point is unclear
•You're copying an architecture from elsewhere
•The simple solution works well
•Nobody has asked for the flexibility
•You're optimizing for hypothetical scale

Apply Pattern Now When

•Multiple implementations exist today
•Requirements explicitly specify flexibility
•The variation point is well understood
•Pattern directly solves current pain
•Simple solution is causing problems
•Stakeholders need the capability now
•Current scale requires it

The Deferral Strategy

Deferral doesn't mean ignoring future needs—it means handling them appropriately:

1. Write simple, clean code: Keep code well-organized even without patterns. Good structure makes pattern introduction easier later.

2. Note potential variation points: Keep a TODO or design document noting where patterns might help if needed. But don't act on it.

3. Watch for the trigger: When you're about to add a second implementation, or when the simple solution starts causing maintenance pain—that's your trigger.

4. Refactor then, not before: When the trigger fires, introduce the pattern. With good tooling and clean existing code, this is usually straightforward.

deferral-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
// Initial state: Simple, direct code
// Note: If we need other report formats, extract interface
class ReportGenerator {
    generate(data: ReportData): PDFDocument {
        return this.buildPDF(data);
    }
    
    private buildPDF(data: ReportData): PDFDocument {
        // PDF generation logic
    }
}
 
// ----- Time passes... -----
 
// Trigger: Business requests Excel export
// Now is the time to introduce Strategy
 
// Step 1: Extract interface from existing code
interface ReportGenerator {
    generate(data: ReportData): Document;
}
 
// Step 2: Rename existing class to be one implementation
class PDFReportGenerator implements ReportGenerator {
    generate(data: ReportData): PDFDocument {
        return this.buildPDF(data);
    }
    
    private buildPDF(data: ReportData): PDFDocument {
        // Existing PDF logic unchanged
    }
}
 
// Step 3: Add new implementation
class ExcelReportGenerator implements ReportGenerator {
    generate(data: ReportData): ExcelDocument {
        return this.buildExcel(data);
    }
    
    private buildExcel(data: ReportData): ExcelDocument {
        // New Excel logic
    }
}
 
// Total time: ~30 minutes
// Benefit: Pattern now serves real need
// We avoided years of unnecessary abstraction

Legitimate Exceptions: When Early Patterns Are Justified

Deferral is the default strategy, but there are legitimate exceptions where early pattern application is justified:

Valid Early Pattern Exceptions

•Testing requirements: When the only way to unit test code is to inject mocks, interfaces are justified even with one implementation. Testing is a current need, not speculation.
•External API boundaries: Wrapping external APIs behind interfaces provides insulation from third-party changes. This is protection, not speculation—APIs do change.
•Contractual extension points: When you're building frameworks or libraries for others to extend, extension points are requirements, not speculation.
•Regulatory/compliance needs: Some compliance frameworks require specific architectural patterns for auditability. This is a real current requirement.
•Well-understood domains: If you've built the same system multiple times and know exactly where variation occurs, that experience counts as evidence.

Exception Abuse Warning

The Testing Exception in Detail

The testing exception deserves elaboration because it's frequently invoked:

Justified: Code that talks to databases, file systems, external services, or system clocks often needs interfaces for mocking in tests. This is a real need.

Not justified: Pure business logic that can be tested directly doesn't need interfaces "for testing." If you can instantiate the class and call its methods, you don't need indirection.

Ask: "Would I add this interface if I weren't thinking about testing?" If yes, proceed. If no, question whether simpler testing approaches exist.

Summary: Avoiding Premature Patterns

Premature pattern application is one of the most common design mistakes. Armed with this understanding, you can resist the temptation:

Key Takeaways

•"Just in case" is a red flag: Patterns applied speculatively have low expected value. Most predicted needs never materialize.
•One implementation means no pattern needed: Patterns handle variation. No variation, no pattern. Wait for the second implementation.
•Premature abstraction is often wrong abstraction: When you abstract without concrete requirements, you guess at the wrong seam.
•YAGNI applies to patterns: Don't add pattern complexity until you have evidence it solves a current problem.
•Refactoring is cheap: Modern tools make introducing patterns later fast and safe. Fear of future refactoring is usually overblown.
•Simple code is not junior code: It takes professional maturity to resist unnecessary abstraction. Simplicity is mastery.
•Exceptions exist but require honesty: Testing, API boundaries, and known domains can justify early patterns—but don't abuse these loopholes.

Page Complete

3 / 4