System Design (HLD)When to Use Patterns

When to Use Design Patterns

LevelIntermediate

Duration60 mins

TopicWhen to Use Patterns

4 / 4

Refactoring to Patterns

Patterns as Destinations, Not Starting Points

We've established that patterns should not be applied prematurely. But this raises a practical question: When the genuine need arrives, how do we introduce patterns into existing code?

This question is more important than it might seem. The ability to refactor toward patterns confidently is what makes deferral a viable strategy. If refactoring were painful and risky, early pattern application would be the safer choice. But refactoring, done properly, is neither painful nor risky—it's a disciplined transformation that improves code structure while preserving behavior.

This page teaches the mechanics of pattern-targeted refactoring: recognizing the trigger, preparing the codebase, executing incrementally, and verifying correctness throughout.

The Refactoring Mindset

Refactoring to patterns is not rewriting. You're not discarding working code—you're restructuring it to accommodate new requirements while preserving existing behavior. Every step should leave the code working. If tests pass before a step and fail after, something went wrong.

Recognizing the Trigger

The trigger to refactor toward a pattern comes when code begins to resist change in ways a pattern would address. These trigger moments are specific and recognizable:

Pattern Refactoring Triggers
Trigger Situation	What You're Experiencing	Pattern to Consider
Second implementation needed	You need to support another way of doing something that was previously hardcoded	Strategy, Factory, Bridge
Switch statement on type growing	Adding new behaviors means adding more cases to switches/if-else chains	Strategy, State, Command
Configuration-based behavior	Behavior should change based on configuration without code changes	Strategy, Abstract Factory
Subclass explosion	You're creating subclasses for every combination of features	Decorator, Strategy + Factory
Tightly coupled notifications	Adding a new notification recipient requires modifying the sender	Observer
Complex object construction	Constructors have too many parameters or complex initialization logic	Builder, Factory
Interface mismatch with third party	External code doesn't match your expected interface	Adapter
Conditional on object state	Methods have complex conditionals checking object state	State

The "Feel" of a Trigger Moment

Triggers often feel like friction during development:

"Adding this new payment method requires changes in five places..." → Strategy/Factory
"Every time we add a report format, the export function grows..." → Strategy
"This class has become impossible to test because it creates its dependencies..." → Dependency Injection
"The notification code knows about every subscriber and needs updating for each new one..." → Observer

When you feel friction during development, pause and ask: "Is this friction because the code structure doesn't match the problem structure?" If yes, a pattern may help.

Friction Is Information

Development friction isn't just annoyance—it's signal. When code fights against changes, it's telling you about a structural mismatch. Patterns exist precisely to resolve these mismatches. Learn to read friction as a guide to appropriate patterns.

Preparing for Pattern Refactoring

Before restructuring code, ensure you have the safety nets and understanding needed for confident transformation:

Refactoring Prerequisites

•Test coverage: You need tests that verify current behavior. Without tests, you can't know if refactoring preserved correctness. If tests don't exist, write characterization tests first.
•Pattern understanding: Know the pattern you're moving toward—its structure, participants, and variations. Half-understood patterns lead to half-correct implementations.
•Clear end state vision: Visualize what the refactored code will look like. Which classes will exist? How will they interact? Sketch the target structure before coding.
•Incremental path: Plan small steps from current state to target. Each step should be committable with passing tests. Never make a "big bang" refactor.
•Rollback capability: Ensure you can abandon the refactoring if it goes wrong. Version control is essential; consider working on a branch.

Characterization Tests

If the code to be refactored lacks tests, write characterization tests first. These tests don't verify intended behavior—they document current behavior, whatever it is:

// Characterization test: Capture current behavior
test('processOrder with standard shipping (characterization)', () => {
    const order = createTestOrder({ shipping: 'standard' });
    const result = processOrder(order);
    
    // Whatever the current behavior is, lock it in
    expect(result.shippingCost).toBe(5.99);
    expect(result.estimatedDays).toBe(5);
    expect(result.carrier).toBe('USPS');
});

Characterization tests become guardrails during refactoring. If behavior accidentally changes, tests fail immediately.

No Tests, No Refactoring

Refactoring without tests is not refactoring—it's restructuring and hoping. If you can't verify behavior preservation, you're accepting unquantified risk. Write the tests first, even if it delays the refactoring.

The Incremental Approach

Pattern refactoring should happen in small, verified steps. Each step changes code structure while preserving behavior. This section demonstrates the incremental approach through a worked example:

Starting situation: A report generator that handles multiple formats through conditional logic.

before-refactoring.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
// BEFORE: Conditionals for each format
class ReportGenerator {
    generate(data: ReportData, format: 'pdf' | 'excel' | 'csv'): Document {
        if (format === 'pdf') {
            // PDF generation logic (~50 lines)
            const doc = new PDFDocument();
            doc.addTitle(data.title);
            doc.addTable(data.rows);
            doc.setPageSize('A4');
            return doc.finalize();
        } else if (format === 'excel') {
            // Excel generation logic (~50 lines)
            const workbook = new ExcelWorkbook();
            const sheet = workbook.addSheet(data.title);
            sheet.addRows(data.rows);
            sheet.formatAsTable();
            return workbook.finalize();
        } else if (format === 'csv') {
            // CSV generation logic (~30 lines)
            const lines = [data.headers.join(',')];
            for (const row of data.rows) {
                lines.push(row.values.join(','));
            }
            return new CSVDocument(lines.join('\n'));
        }
        throw new Error(`Unknown format: ${format}`);
    }
}
 
// TRIGGER: Business requests HTML format
// Adding another if-else block is the wrong direction
// Time to refactor to Strategy pattern

Step-by-Step Refactoring to Strategy

step-1-extract-interface.ts
TypeScript
1
2
3
4
5
6
7
8
// STEP 1: Define the strategy interface
// This captures the common operation all formats perform
 
interface ReportFormatter {
    format(data: ReportData): Document;
}
 
// Tests still pass - we've only added an interface, changed nothing

step-2-extract-first-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
// STEP 2: Extract first strategy (PDF)
// Move the PDF logic to its own class implementing the interface
 
class PDFFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        const doc = new PDFDocument();
        doc.addTitle(data.title);
        doc.addTable(data.rows);
        doc.setPageSize('A4');
        return doc.finalize();
    }
}
 
// Original class still has conditionals but calls new strategy for PDF
class ReportGenerator {
    generate(data: ReportData, format: 'pdf' | 'excel' | 'csv'): Document {
        if (format === 'pdf') {
            return new PDFFormatter().format(data);  // Delegated
        } else if (format === 'excel') {
            // Still inline
        } else if (format === 'csv') {
            // Still inline
        }
        throw new Error(`Unknown format: ${format}`);
    }
}
 
// Tests still pass - behavior identical, structure changing

step-3-extract-remaining.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
// STEP 3: Extract remaining strategies
class ExcelFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        const workbook = new ExcelWorkbook();
        const sheet = workbook.addSheet(data.title);
        sheet.addRows(data.rows);
        sheet.formatAsTable();
        return workbook.finalize();
    }
}
 
class CSVFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        const lines = [data.headers.join(',')];
        for (const row of data.rows) {
            lines.push(row.values.join(','));
        }
        return new CSVDocument(lines.join('\n'));
    }
}
 
// Generator now delegates to all strategies
class ReportGenerator {
    generate(data: ReportData, format: 'pdf' | 'excel' | 'csv'): Document {
        if (format === 'pdf') {
            return new PDFFormatter().format(data);
        } else if (format === 'excel') {
            return new ExcelFormatter().format(data);
        } else if (format === 'csv') {
            return new CSVFormatter().format(data);
        }
        throw new Error(`Unknown format: ${format}`);
    }
}
 
// Tests still pass - all logic extracted to strategies

step-4-introduce-registry.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
// STEP 4: Replace conditionals with strategy lookup
// This eliminates the if-else chain entirely
 
type FormatType = 'pdf' | 'excel' | 'csv' | 'html';
 
class ReportGenerator {
    private readonly formatters: Map<FormatType, ReportFormatter>;
    
    constructor() {
        this.formatters = new Map([
            ['pdf', new PDFFormatter()],
            ['excel', new ExcelFormatter()],
            ['csv', new CSVFormatter()],
        ]);
    }
    
    registerFormatter(type: FormatType, formatter: ReportFormatter): void {
        this.formatters.set(type, formatter);
    }
    
    generate(data: ReportData, format: FormatType): Document {
        const formatter = this.formatters.get(format);
        if (!formatter) {
            throw new Error(`Unknown format: ${format}`);
        }
        return formatter.format(data);
    }
}
 
// Tests still pass - same behavior, clean strategy pattern
 
// NOW adding HTML is trivial:
class HTMLFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        // HTML generation logic
    }
}
 
// Just register the new formatter
generator.registerFormatter('html', new HTMLFormatter());
 
// Total refactoring: ~45 minutes
// New format addition: ~15 minutes
// No existing code modified for new formats

Common Pattern Refactoring Recipes

Different patterns have different refactoring paths. Here are recipes for the most common pattern introductions:

Refactoring to Factory Method

When: You have new ConcreteClass() scattered through code, and you need to create different types based on context.

Factory Method Introduction Steps

•Create a factory method on the class that creates the objects
•Replace new ConcreteClass() calls with factory method calls
•Extract factory method to a Factory interface/abstract class
•Create concrete factory implementations for each type
•Inject the appropriate factory where needed

Refactoring to Observer

When: One object directly calls methods on multiple other objects to notify them of changes.

Observer Introduction Steps

•Define an Observer interface with the update/notification method
•Have the dependent objects implement the Observer interface
•Add a list of observers to the subject with add/remove methods
•Replace direct calls with iteration over observers
•Refactor registration to happen at composition time

Refactoring to Decorator

When: You have subclasses for every combination of features, or you need to add behavior to objects dynamically.

Decorator Introduction Steps

•Ensure the base class/interface exists for the objects to be decorated
•Create an abstract decorator that wraps and delegates to a component
•Extract each 'feature' into a concrete decorator class
•Decorators wrap the component and add their behavior
•Compose decorators at runtime as needed

Refactoring to State

When: Object behavior is conditional on internal state, with complex if-else chains checking state.

State Pattern Introduction Steps

•Identify all states the object can be in
•Create a State interface with methods for state-dependent behavior
•Create concrete state classes implementing the interface
•Add a current state field to the context class
•Delegate state-dependent methods to the current state
•Implement state transitions in state classes or context

Verifying the Refactoring

Refactoring success isn't just about code structure—it's about verified behavior preservation and improved design quality. Here's how to verify you've succeeded:

Refactoring Verification Checklist

•All tests pass: The most basic check. If characterization tests and unit tests pass, behavior is preserved.
•The trigger problem is solved: The friction that prompted refactoring should be gone. Adding the new variation (format, implementation, etc.) should now be easy.
•Open/Closed is respected: Adding new variations shouldn't require modifying existing code—only adding new classes.
•Code is more cohesive: Each class now has a single, clear purpose. Responsibilities are cleanly separated.
•Testability improved: Individual strategies/states/decorators should be testable in isolation.
•No behavior changes snuck in: Review the diff. Every change should be structural. If you changed what the code does (not just how it's organized), something is wrong.

The Smoke Test

After refactoring, perform the smoke test that triggered the refactoring in the first place:

Before refactoring: "Adding HTML format requires modifying the generate method and adding another if-else case."

After refactoring: "Adding HTML format requires creating HTMLFormatter and registering it. No existing code changes."

If the smoke test passes—if the new requirement is now easy—the refactoring succeeded.

Celebrate Small Wins

When refactoring to a pattern, the moment you add the new feature through the clean extension point feels satisfying. You've transformed friction into flow. This is the reward for proper timing—the pattern now earns its keep.

When Refactoring Is Too Costly

Sometimes the cost of refactoring to a pattern exceeds the benefit. Recognizing these situations prevents wasted effort:

Signs Refactoring May Not Be Worth It

•End-of-life code: If the code will be replaced soon, refactoring is wasted effort. Add the feature the hacky way; deprecate later.
•Insufficient test coverage: Without tests, safe refactoring is impossible. If writing tests is too expensive, the refactoring risk may be too high.
•Unstable requirements: If requirements are changing weekly, pattern structure may be wrong by the time you finish. Wait for stability.
•One-off addition: If this is truly the last variation you'll ever need, adding another if-else might be cheaper than refactoring. (But be honest about "truly the last.")
•Tight deadline: Pattern refactoring takes time. If the deadline is imminent, the quick fix followed by post-release refactoring may be pragmatic.

The Pragmatic Response

When refactoring is too costly now, document the design debt:

// TODO: Refactor to Strategy pattern when adding next format
// Current if-else chain is becoming unwieldy
// Deferred due to: [release deadline / insufficient tests / etc.]
if (format === 'pdf') {
    // PDF logic
} else if (format === 'excel') {
    // Excel logic
} else if (format === 'html') {
    // HTML logic - added under time pressure
}

This acknowledges the debt and leaves a trail for future engineers. When circumstances change, the refactoring can happen.

Technical Debt Registry

Some teams maintain a technical debt registry—a tracked list of design debts with reasons for deferral. This prevents debts from being forgotten and allows periodic debt reduction sprints.

The Complete Pattern Application Lifecycle

We can now summarize the complete lifecycle for responsible pattern application:

The Pattern Application Lifecycle

•Start simple: Write straightforward code that solves current requirements. No patterns for speculation.
•Maintain quality: Keep code clean, cohesive, and well-tested. This makes future refactoring possible.
•Watch for triggers: Notice when code resists change in pattern-recognizable ways. Friction is signal.
•Confirm the pattern need: Verify the trigger represents a genuine, recurring problem that a pattern addresses.
•Prepare for refactoring: Ensure test coverage, understand the target pattern, visualize the end state.
•Refactor incrementally: Transform structure in small, tested steps. Never break working code.
•Verify success: Tests pass, trigger problem is solved, new variations are easy to add.
•Enjoy the benefits: The pattern now earns its complexity through real flexibility and clarity.

This lifecycle treats patterns as destinations you refactor toward, not starting points you design down from. It respects YAGNI while enabling appropriate abstraction when justified.

Summary: Refactoring to Patterns

Refactoring to patterns completes the responsible pattern application lifecycle. With this skill, deferring patterns becomes safe—you can always introduce them when genuinely needed.

Key Takeaways

•Triggers signal the right time: Development friction—especially when adding variations—indicates pattern opportunity.
•Preparation enables safety: Tests, pattern understanding, and clear end-state vision are prerequisites for confident refactoring.
•Incremental transformation is key: Small steps, each leaving code working, prevent refactoring disasters.
•Each pattern has a refactoring recipe: Learn the step-by-step transformations for common patterns.
•Verify through tests and trials: Passing tests plus easy variation addition confirms refactoring success.
•Sometimes deferral is permanent: When refactoring is too costly, document the debt and move on pragmatically.
•The lifecycle is iterative: Start simple, watch for triggers, refactor when justified, verify success.

Module complete: You now have a complete framework for pattern application—from recognizing problems that merit patterns, through matching patterns to problems, to timing introduction correctly and executing the refactoring safely. This framework will serve you throughout your engineering career.

Module Complete

You've mastered the art of knowing when to use patterns. You understand that patterns are solutions to specific problems, can match problems to patterns systematically, know when to defer pattern application, and can refactor toward patterns safely when the need emerges. This is mature pattern usage—the mark of a senior engineer.

4 / 4

Loading learning content...

System Design (HLD)When to Use Patterns

When to Use Design Patterns

LevelIntermediate

Duration60 mins

TopicWhen to Use Patterns

4 / 4

Refactoring to Patterns

Patterns as Destinations, Not Starting Points

We've established that patterns should not be applied prematurely. But this raises a practical question: When the genuine need arrives, how do we introduce patterns into existing code?

This page teaches the mechanics of pattern-targeted refactoring: recognizing the trigger, preparing the codebase, executing incrementally, and verifying correctness throughout.

The Refactoring Mindset

Recognizing the Trigger

The trigger to refactor toward a pattern comes when code begins to resist change in ways a pattern would address. These trigger moments are specific and recognizable:

Pattern Refactoring Triggers
Trigger Situation	What You're Experiencing	Pattern to Consider
Second implementation needed	You need to support another way of doing something that was previously hardcoded	Strategy, Factory, Bridge
Switch statement on type growing	Adding new behaviors means adding more cases to switches/if-else chains	Strategy, State, Command
Configuration-based behavior	Behavior should change based on configuration without code changes	Strategy, Abstract Factory
Subclass explosion	You're creating subclasses for every combination of features	Decorator, Strategy + Factory
Tightly coupled notifications	Adding a new notification recipient requires modifying the sender	Observer
Complex object construction	Constructors have too many parameters or complex initialization logic	Builder, Factory
Interface mismatch with third party	External code doesn't match your expected interface	Adapter
Conditional on object state	Methods have complex conditionals checking object state	State

The "Feel" of a Trigger Moment

Triggers often feel like friction during development:

"Adding this new payment method requires changes in five places..." → Strategy/Factory
"Every time we add a report format, the export function grows..." → Strategy
"This class has become impossible to test because it creates its dependencies..." → Dependency Injection
"The notification code knows about every subscriber and needs updating for each new one..." → Observer

When you feel friction during development, pause and ask: "Is this friction because the code structure doesn't match the problem structure?" If yes, a pattern may help.

Friction Is Information

Preparing for Pattern Refactoring

Before restructuring code, ensure you have the safety nets and understanding needed for confident transformation:

Refactoring Prerequisites

•Test coverage: You need tests that verify current behavior. Without tests, you can't know if refactoring preserved correctness. If tests don't exist, write characterization tests first.
•Pattern understanding: Know the pattern you're moving toward—its structure, participants, and variations. Half-understood patterns lead to half-correct implementations.
•Clear end state vision: Visualize what the refactored code will look like. Which classes will exist? How will they interact? Sketch the target structure before coding.
•Incremental path: Plan small steps from current state to target. Each step should be committable with passing tests. Never make a "big bang" refactor.
•Rollback capability: Ensure you can abandon the refactoring if it goes wrong. Version control is essential; consider working on a branch.

Characterization Tests

If the code to be refactored lacks tests, write characterization tests first. These tests don't verify intended behavior—they document current behavior, whatever it is:

// Characterization test: Capture current behavior
test('processOrder with standard shipping (characterization)', () => {
    const order = createTestOrder({ shipping: 'standard' });
    const result = processOrder(order);
    
    // Whatever the current behavior is, lock it in
    expect(result.shippingCost).toBe(5.99);
    expect(result.estimatedDays).toBe(5);
    expect(result.carrier).toBe('USPS');
});

Characterization tests become guardrails during refactoring. If behavior accidentally changes, tests fail immediately.

No Tests, No Refactoring

The Incremental Approach

Pattern refactoring should happen in small, verified steps. Each step changes code structure while preserving behavior. This section demonstrates the incremental approach through a worked example:

Starting situation: A report generator that handles multiple formats through conditional logic.

before-refactoring.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
// BEFORE: Conditionals for each format
class ReportGenerator {
    generate(data: ReportData, format: 'pdf' | 'excel' | 'csv'): Document {
        if (format === 'pdf') {
            // PDF generation logic (~50 lines)
            const doc = new PDFDocument();
            doc.addTitle(data.title);
            doc.addTable(data.rows);
            doc.setPageSize('A4');
            return doc.finalize();
        } else if (format === 'excel') {
            // Excel generation logic (~50 lines)
            const workbook = new ExcelWorkbook();
            const sheet = workbook.addSheet(data.title);
            sheet.addRows(data.rows);
            sheet.formatAsTable();
            return workbook.finalize();
        } else if (format === 'csv') {
            // CSV generation logic (~30 lines)
            const lines = [data.headers.join(',')];
            for (const row of data.rows) {
                lines.push(row.values.join(','));
            }
            return new CSVDocument(lines.join('\n'));
        }
        throw new Error(`Unknown format: ${format}`);
    }
}
 
// TRIGGER: Business requests HTML format
// Adding another if-else block is the wrong direction
// Time to refactor to Strategy pattern

Step-by-Step Refactoring to Strategy

step-1-extract-interface.ts
TypeScript
1
2
3
4
5
6
7
8
// STEP 1: Define the strategy interface
// This captures the common operation all formats perform
 
interface ReportFormatter {
    format(data: ReportData): Document;
}
 
// Tests still pass - we've only added an interface, changed nothing

step-2-extract-first-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
// STEP 2: Extract first strategy (PDF)
// Move the PDF logic to its own class implementing the interface
 
class PDFFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        const doc = new PDFDocument();
        doc.addTitle(data.title);
        doc.addTable(data.rows);
        doc.setPageSize('A4');
        return doc.finalize();
    }
}
 
// Original class still has conditionals but calls new strategy for PDF
class ReportGenerator {
    generate(data: ReportData, format: 'pdf' | 'excel' | 'csv'): Document {
        if (format === 'pdf') {
            return new PDFFormatter().format(data);  // Delegated
        } else if (format === 'excel') {
            // Still inline
        } else if (format === 'csv') {
            // Still inline
        }
        throw new Error(`Unknown format: ${format}`);
    }
}
 
// Tests still pass - behavior identical, structure changing

step-3-extract-remaining.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
// STEP 3: Extract remaining strategies
class ExcelFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        const workbook = new ExcelWorkbook();
        const sheet = workbook.addSheet(data.title);
        sheet.addRows(data.rows);
        sheet.formatAsTable();
        return workbook.finalize();
    }
}
 
class CSVFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        const lines = [data.headers.join(',')];
        for (const row of data.rows) {
            lines.push(row.values.join(','));
        }
        return new CSVDocument(lines.join('\n'));
    }
}
 
// Generator now delegates to all strategies
class ReportGenerator {
    generate(data: ReportData, format: 'pdf' | 'excel' | 'csv'): Document {
        if (format === 'pdf') {
            return new PDFFormatter().format(data);
        } else if (format === 'excel') {
            return new ExcelFormatter().format(data);
        } else if (format === 'csv') {
            return new CSVFormatter().format(data);
        }
        throw new Error(`Unknown format: ${format}`);
    }
}
 
// Tests still pass - all logic extracted to strategies

step-4-introduce-registry.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
// STEP 4: Replace conditionals with strategy lookup
// This eliminates the if-else chain entirely
 
type FormatType = 'pdf' | 'excel' | 'csv' | 'html';
 
class ReportGenerator {
    private readonly formatters: Map<FormatType, ReportFormatter>;
    
    constructor() {
        this.formatters = new Map([
            ['pdf', new PDFFormatter()],
            ['excel', new ExcelFormatter()],
            ['csv', new CSVFormatter()],
        ]);
    }
    
    registerFormatter(type: FormatType, formatter: ReportFormatter): void {
        this.formatters.set(type, formatter);
    }
    
    generate(data: ReportData, format: FormatType): Document {
        const formatter = this.formatters.get(format);
        if (!formatter) {
            throw new Error(`Unknown format: ${format}`);
        }
        return formatter.format(data);
    }
}
 
// Tests still pass - same behavior, clean strategy pattern
 
// NOW adding HTML is trivial:
class HTMLFormatter implements ReportFormatter {
    format(data: ReportData): Document {
        // HTML generation logic
    }
}
 
// Just register the new formatter
generator.registerFormatter('html', new HTMLFormatter());
 
// Total refactoring: ~45 minutes
// New format addition: ~15 minutes
// No existing code modified for new formats

Common Pattern Refactoring Recipes

Different patterns have different refactoring paths. Here are recipes for the most common pattern introductions:

Refactoring to Factory Method

When: You have new ConcreteClass() scattered through code, and you need to create different types based on context.

Factory Method Introduction Steps

•Create a factory method on the class that creates the objects
•Replace new ConcreteClass() calls with factory method calls
•Extract factory method to a Factory interface/abstract class
•Create concrete factory implementations for each type
•Inject the appropriate factory where needed

Refactoring to Observer

When: One object directly calls methods on multiple other objects to notify them of changes.

Observer Introduction Steps

•Define an Observer interface with the update/notification method
•Have the dependent objects implement the Observer interface
•Add a list of observers to the subject with add/remove methods
•Replace direct calls with iteration over observers
•Refactor registration to happen at composition time

Refactoring to Decorator

When: You have subclasses for every combination of features, or you need to add behavior to objects dynamically.

Decorator Introduction Steps

•Ensure the base class/interface exists for the objects to be decorated
•Create an abstract decorator that wraps and delegates to a component
•Extract each 'feature' into a concrete decorator class
•Decorators wrap the component and add their behavior
•Compose decorators at runtime as needed

Refactoring to State

When: Object behavior is conditional on internal state, with complex if-else chains checking state.

State Pattern Introduction Steps

•Identify all states the object can be in
•Create a State interface with methods for state-dependent behavior
•Create concrete state classes implementing the interface
•Add a current state field to the context class
•Delegate state-dependent methods to the current state
•Implement state transitions in state classes or context

Verifying the Refactoring

Refactoring success isn't just about code structure—it's about verified behavior preservation and improved design quality. Here's how to verify you've succeeded:

Refactoring Verification Checklist

•All tests pass: The most basic check. If characterization tests and unit tests pass, behavior is preserved.
•The trigger problem is solved: The friction that prompted refactoring should be gone. Adding the new variation (format, implementation, etc.) should now be easy.
•Open/Closed is respected: Adding new variations shouldn't require modifying existing code—only adding new classes.
•Code is more cohesive: Each class now has a single, clear purpose. Responsibilities are cleanly separated.
•Testability improved: Individual strategies/states/decorators should be testable in isolation.
•No behavior changes snuck in: Review the diff. Every change should be structural. If you changed what the code does (not just how it's organized), something is wrong.

The Smoke Test

After refactoring, perform the smoke test that triggered the refactoring in the first place:

Before refactoring: "Adding HTML format requires modifying the generate method and adding another if-else case."

After refactoring: "Adding HTML format requires creating HTMLFormatter and registering it. No existing code changes."

If the smoke test passes—if the new requirement is now easy—the refactoring succeeded.

Celebrate Small Wins

When Refactoring Is Too Costly

Sometimes the cost of refactoring to a pattern exceeds the benefit. Recognizing these situations prevents wasted effort:

Signs Refactoring May Not Be Worth It

•End-of-life code: If the code will be replaced soon, refactoring is wasted effort. Add the feature the hacky way; deprecate later.
•Insufficient test coverage: Without tests, safe refactoring is impossible. If writing tests is too expensive, the refactoring risk may be too high.
•Unstable requirements: If requirements are changing weekly, pattern structure may be wrong by the time you finish. Wait for stability.
•One-off addition: If this is truly the last variation you'll ever need, adding another if-else might be cheaper than refactoring. (But be honest about "truly the last.")
•Tight deadline: Pattern refactoring takes time. If the deadline is imminent, the quick fix followed by post-release refactoring may be pragmatic.

The Pragmatic Response

When refactoring is too costly now, document the design debt:

// TODO: Refactor to Strategy pattern when adding next format
// Current if-else chain is becoming unwieldy
// Deferred due to: [release deadline / insufficient tests / etc.]
if (format === 'pdf') {
    // PDF logic
} else if (format === 'excel') {
    // Excel logic
} else if (format === 'html') {
    // HTML logic - added under time pressure
}

This acknowledges the debt and leaves a trail for future engineers. When circumstances change, the refactoring can happen.

Technical Debt Registry

Some teams maintain a technical debt registry—a tracked list of design debts with reasons for deferral. This prevents debts from being forgotten and allows periodic debt reduction sprints.

The Complete Pattern Application Lifecycle

We can now summarize the complete lifecycle for responsible pattern application:

The Pattern Application Lifecycle

•Start simple: Write straightforward code that solves current requirements. No patterns for speculation.
•Maintain quality: Keep code clean, cohesive, and well-tested. This makes future refactoring possible.
•Watch for triggers: Notice when code resists change in pattern-recognizable ways. Friction is signal.
•Confirm the pattern need: Verify the trigger represents a genuine, recurring problem that a pattern addresses.
•Prepare for refactoring: Ensure test coverage, understand the target pattern, visualize the end state.
•Refactor incrementally: Transform structure in small, tested steps. Never break working code.
•Verify success: Tests pass, trigger problem is solved, new variations are easy to add.
•Enjoy the benefits: The pattern now earns its complexity through real flexibility and clarity.

This lifecycle treats patterns as destinations you refactor toward, not starting points you design down from. It respects YAGNI while enabling appropriate abstraction when justified.

Summary: Refactoring to Patterns

Refactoring to patterns completes the responsible pattern application lifecycle. With this skill, deferring patterns becomes safe—you can always introduce them when genuinely needed.

Key Takeaways

•Triggers signal the right time: Development friction—especially when adding variations—indicates pattern opportunity.
•Preparation enables safety: Tests, pattern understanding, and clear end-state vision are prerequisites for confident refactoring.
•Incremental transformation is key: Small steps, each leaving code working, prevent refactoring disasters.
•Each pattern has a refactoring recipe: Learn the step-by-step transformations for common patterns.
•Verify through tests and trials: Passing tests plus easy variation addition confirms refactoring success.
•Sometimes deferral is permanent: When refactoring is too costly, document the debt and move on pragmatically.
•The lifecycle is iterative: Start simple, watch for triggers, refactor when justified, verify success.

Module Complete

4 / 4