System Design (HLD)Creational Patterns

Factory Method Pattern

LevelIntermediate

Duration60 mins

TopicCreational Patterns

3 / 4

Participants and Structure

The Anatomy of Factory Method

Understanding a design pattern requires more than knowing what it does—you need to understand its structure: the participants, their roles, their relationships, and how they collaborate to achieve the pattern's goals.

The Factory Method pattern involves four key participants working together in a carefully designed relationship. In this page, we'll dissect each participant, understand why it exists, what responsibilities it carries, and how it interacts with the others. This structural understanding is essential for applying the pattern correctly in your own designs.

What You Will Learn

By the end of this page, you'll have a complete mental model of Factory Method's structure. You'll understand the Creator hierarchy, the Product hierarchy, how they connect through the factory method, and the collaboration dynamics that make the pattern work.

The Four Participants

The Factory Method pattern consists of four participants that work together:

Product — The interface for objects the factory method creates
ConcreteProduct — Implements the Product interface
Creator — Declares the factory method; may provide a default implementation
ConcreteCreator — Overrides the factory method to return a ConcreteProduct

Let's examine each in detail.

Converting Mermaid diagram...

This class diagram shows the fundamental structure. Notice the two parallel hierarchies:

Creator hierarchy (left): Creator → ConcreteCreatorA, ConcreteCreatorB
Product hierarchy (right): Product → ConcreteProductA, ConcreteProductB

The factory method in Creator returns Product. Each ConcreteCreator overrides it to return its matching ConcreteProduct.

Product: The Creation Target

The Product defines the interface for the objects that the factory method creates. This is the abstraction that both the Creator and client code depend upon.

product-interface.ts
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
// Product: The interface for objects the factory method creates
// Can be an interface or abstract class
 
// Example 1: Interface-based Product
interface Document {
    // Core operations all documents must support
    parse(): void;
    validate(): boolean;
    render(): string;
    
    // Properties
    readonly path: string;
    readonly format: DocumentFormat;
}
 
// Example 2: Abstract class-based Product (with shared behavior)
abstract class Transport {
    protected passengers: number = 0;
    
    // Abstract methods - subclasses must implement
    abstract deliver(cargo: Cargo): void;
    abstract getCapacity(): number;
    
    // Concrete methods - shared behavior
    loadPassengers(count: number): void {
        if (count > this.getCapacity()) {
            throw new Error('Exceeds capacity');
        }
        this.passengers = count;
    }
    
    getPassengerCount(): number {
        return this.passengers;
    }
}

Product Responsibilities

•Define the contract — Declare all operations that ConcreteProducts must implement.
•Enable polymorphism — Allow Creator to work with any ConcreteProduct through the common interface.
•Support substitutability — Any ConcreteProduct should be substitutable where Product is expected (Liskov Substitution Principle).
•Optionally share behavior — If an abstract class, can provide default implementations of common operations.

Interface vs Abstract Class

Choose an interface when products only share a contract (method signatures). Choose an abstract class when products share implementation (code). In languages supporting multiple inheritance of interfaces (like Java, C#, TypeScript), prefer interfaces for maximum flexibility.

ConcreteProduct: The Actual Objects

ConcreteProduct classes implement the Product interface. These are the actual objects that get created and used. Each ConcreteProduct provides its own implementation of the Product operations.

concrete-products.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
// ConcreteProducts implement the Product interface
 
// ConcreteProduct 1: PDF Document
class PdfDocument implements Document {
    readonly format = DocumentFormat.PDF;
    private content: PdfContent | null = null;
    
    constructor(readonly path: string) {}
    
    parse(): void {
        // PDF-specific parsing using pdf.js or similar
        const buffer = readFileSync(this.path);
        this.content = PdfParser.parse(buffer);
    }
    
    validate(): boolean {
        if (!this.content) return false;
        return this.content.isValid() && this.content.hasRequiredMetadata();
    }
    
    render(): string {
        if (!this.content) throw new Error('Document not parsed');
        return this.content.toHtml();
    }
}
 
// ConcreteProduct 2: Word Document
class WordDocument implements Document {
    readonly format = DocumentFormat.WORD;
    private doc: WordContent | null = null;
    
    constructor(readonly path: string) {}
    
    parse(): void {
        // Word-specific parsing using docx library
        const zip = readWordFile(this.path);
        this.doc = WordParser.parse(zip);
    }
    
    validate(): boolean {
        if (!this.doc) return false;
        return this.doc.hasValidStructure();
    }
    
    render(): string {
        if (!this.doc) throw new Error('Document not parsed');
        return this.doc.toHtml();
    }
}
 
// ConcreteProduct 3: Markdown Document
class MarkdownDocument implements Document {
    readonly format = DocumentFormat.MARKDOWN;
    private text: string = '';
    
    constructor(readonly path: string) {}
    
    parse(): void {
        // Simple text reading for markdown
        this.text = readFileSync(this.path, 'utf-8');
    }
    
    validate(): boolean {
        // Markdown is always valid text
        return this.text.length > 0;
    }
    
    render(): string {
        // Convert markdown to HTML
        return marked(this.text);
    }
}

ConcreteProduct Responsibilities

•Implement Product interface — Provide concrete implementations of all declared operations.
•Encapsulate specifics — Hide implementation details behind the Product interface.
•Be self-contained — Should work independently once created; don't rely on Creator.
•Handle type-specific logic — All format/type-specific behavior belongs in ConcreteProduct.

The Separation of Concerns

Notice how each ConcreteProduct is completely independent. PdfDocument knows about PDF parsing, WordDocument knows about Word parsing, but they share no code. The common behavior is defined by the interface, not by copying implementations. This is the essence of polymorphism.

Creator: The Factory Method Holder

The Creator is the class that declares the factory method. It may also define a default implementation of the factory method that returns a default ConcreteProduct type. The Creator's primary operations use the factory method to create Product objects.

creator.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// Creator: Declares the factory method and uses it
 
abstract class DocumentProcessor {
    // ==========================================
    // THE FACTORY METHOD
    // ==========================================
    // - Return type is the Product interface
    // - Can be abstract (must override) or virtual (optional override)
    // - Usually protected (only subclasses use it)
    // - Named descriptively: createX, makeX, buildX
    protected abstract createDocument(path: string): Document;
    
    // ==========================================
    // OPERATIONS THAT USE THE FACTORY METHOD
    // ==========================================
    // These methods call the factory method to get products
    // They work with the Product interface, not concrete classes
    
    processDocument(path: string): ProcessingResult {
        // Step 1: Create document via factory method
        const document = this.createDocument(path);
        
        // Step 2: Use the document through its interface
        document.parse();
        
        if (!document.validate()) {
            return { success: false, error: 'Validation failed' };
        }
        
        const rendered = document.render();
        return { success: true, content: rendered };
    }
    
    batchProcess(paths: string[]): ProcessingResult[] {
        return paths.map(path => this.processDocument(path));
    }
    
    compareDocuments(path1: string, path2: string): Comparison {
        // Factory method called multiple times
        const doc1 = this.createDocument(path1);
        const doc2 = this.createDocument(path2);
        
        doc1.parse();
        doc2.parse();
        
        return new Comparison(doc1.render(), doc2.render());
    }
}
 
// Creator with default implementation
abstract class LoggingApplication {
    private logger: Logger | null = null;
    
    // Virtual factory method with default
    protected createLogger(): Logger {
        return new ConsoleLogger();  // Default implementation
    }
    
    protected getLogger(): Logger {
        if (!this.logger) {
            this.logger = this.createLogger();
        }
        return this.logger;
    }
    
    log(message: string): void {
        this.getLogger().log(message);
    }
}

The Creator has two core aspects:

The Factory Method

•Declares return type as Product interface
•Abstract forces subclass implementation
•Virtual allows optional override
•Protected limits access to hierarchy
•Naming convention: create*, make*, build*

Operations Using Factory Method

•Call factory method, not new
•Work with Product interface only
•Never reference ConcreteProducts
•Contain business logic
•Unchanged when new products added

Common Mistake: Creator Knowing ConcreteProducts

The Creator should NEVER reference ConcreteProduct classes. If you see imports of PdfDocument, WordDocument, etc., in the Creator, something is wrong. The Creator only knows about the Product interface. Only ConcreteCreators know about their matching ConcreteProducts.

ConcreteCreator: The Decision Maker

ConcreteCreator classes override the factory method to return an instance of a ConcreteProduct. This is where the actual new call lives. Each ConcreteCreator is paired with a ConcreteProduct.

concrete-creators.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
// ConcreteCreators override the factory method
 
// ConcreteCreator for PDF documents
class PdfDocumentProcessor extends DocumentProcessor {
    protected createDocument(path: string): Document {
        return new PdfDocument(path);
    }
}
 
// ConcreteCreator for Word documents
class WordDocumentProcessor extends DocumentProcessor {
    protected createDocument(path: string): Document {
        return new WordDocument(path);
    }
}
 
// ConcreteCreator for Markdown documents
class MarkdownDocumentProcessor extends DocumentProcessor {
    protected createDocument(path: string): Document {
        return new MarkdownDocument(path);
    }
}
 
// ConcreteCreator with complex construction logic
class ConfiguredPdfProcessor extends DocumentProcessor {
    constructor(
        private readonly config: PdfConfig,
        private readonly plugins: PdfPlugin[]
    ) {
        super();
    }
    
    protected createDocument(path: string): Document {
        // Factory method can contain complex creation logic
        const doc = new PdfDocument(path);
        
        // Apply configuration
        doc.setRenderingMode(this.config.renderingMode);
        doc.setDpi(this.config.dpi);
        
        // Install plugins
        for (const plugin of this.plugins) {
            doc.installPlugin(plugin);
        }
        
        return doc;
    }
}
 
// ConcreteCreator for testing
class TestDocumentProcessor extends DocumentProcessor {
    private createdDocuments: MockDocument[] = [];
    
    protected createDocument(path: string): Document {
        const mock = new MockDocument(path);
        this.createdDocuments.push(mock);
        return mock;
    }
    
    // Test helper methods
    getCreatedDocuments(): MockDocument[] {
        return this.createdDocuments;
    }
    
    getDocumentAt(index: number): MockDocument {
        return this.createdDocuments[index];
    }
}

ConcreteCreator Responsibilities

•Override factory method — Provide the specific implementation that creates ConcreteProduct.
•Call new — This is the only place in the pattern where new ConcreteProduct() appears.
•Encapsulate creation logic — Complex construction (configuration, plugins, initialization) belongs here.
•Enable substitution — Different ConcreteCreators can be swapped to change product types.

The Pairing Pattern

Notice the pairing: PdfDocumentProcessor creates PdfDocument. WordDocumentProcessor creates WordDocument. This one-to-one correspondence is typical, though not required. A ConcreteCreator could create different ConcreteProducts based on parameters or could even have a hierarchy of its own.

How Participants Collaborate

Understanding how these participants interact at runtime is crucial. Let's trace through a complete execution.

collaboration-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
// Step 1: Client instantiates a ConcreteCreator
const processor: DocumentProcessor = new PdfDocumentProcessor();
 
// Step 2: Client calls operation on Creator (polymorphically)
const result = processor.processDocument('/docs/report.pdf');
 
// What happens inside processDocument():
// 
// processDocument() {
//     // Step 3: Creator calls factory method
//     const document = this.createDocument(path);
//     
//     // At runtime, 'this' is PdfDocumentProcessor
//     // So createDocument() returns new PdfDocument(path)
//     
//     // Step 4: Creator uses Product through interface
//     document.parse();      // Calls PdfDocument.parse()
//     document.validate();   // Calls PdfDocument.validate()
//     document.render();     // Calls PdfDocument.render()
// }
 
// The key insight: Creator code never changes,
// but different ConcreteCreators produce different behavior

The collaboration sequence:

Converting Mermaid diagram...

Collaboration Highlights

•Client creates ConcreteCreator — This is the configuration point where product type is determined.
•Client calls inherited method — The client uses the Creator interface, calling methods like processDocument().
•Creator calls factory method — Inside the inherited method, this.createDocument() is called.
•Polymorphism kicks in — Even though the method is in Creator, this is ConcreteCreator, so the overridden factory method runs.
•ConcreteCreator creates ConcreteProduct — The new call happens in the overridden factory method.
•Creator uses Product — The Creator continues using the returned object through the Product interface.

Structural Variations

The basic Factory Method structure admits several variations depending on your needs.

Creator and Product in one hierarchy:

Sometimes the Creator and Product are the same class—the Creator creates instances of its own type.

single-hierarchy.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
// The Creator IS the Product
abstract class Component {
    protected children: Component[] = [];
    
    // Factory method returns same type
    abstract clone(): Component;
    
    addChild(child: Component): void {
        this.children.push(child);
    }
    
    deepClone(): Component {
        const cloned = this.clone();
        for (const child of this.children) {
            cloned.addChild(child.deepClone());
        }
        return cloned;
    }
}
 
class Button extends Component {
    constructor(private label: string) { super(); }
    
    clone(): Component {
        return new Button(this.label);
    }
}
 
class Panel extends Component {
    constructor(private title: string) { super(); }
    
    clone(): Component {
        return new Panel(this.title);
    }
}

This is common in Prototype-like scenarios where objects need to create copies of themselves.

The Parallel Hierarchies Pattern

A distinctive characteristic of Factory Method is the creation of parallel hierarchies: one for Creators and one for Products. These hierarchies mirror each other.

parallel-hierarchies.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
// PRODUCT HIERARCHY                    // CREATOR HIERARCHY
// ---------------------                 // ---------------------
// 
// Transport (interface)                 // Logistics (abstract)
//   ├── Truck                           //   ├── RoadLogistics
//   ├── Ship                            //   ├── SeaLogistics
//   └── Plane                           //   └── AirLogistics
 
// The hierarchies are parallel:
// RoadLogistics creates Truck
// SeaLogistics creates Ship
// AirLogistics creates Plane
 
interface Transport {
    deliver(cargo: Cargo): Delivery;
}
 
abstract class Logistics {
    planDelivery(cargo: Cargo): DeliveryPlan {
        const transport = this.createTransport();
        return {
            transport: transport,
            route: this.calculateRoute(cargo),
            estimatedTime: transport.estimateTime(cargo),
        };
    }
    
    protected abstract createTransport(): Transport;
    protected abstract calculateRoute(cargo: Cargo): Route;
}
 
// Parallel implementation pairs
class Truck implements Transport { /* ... */ }
class RoadLogistics extends Logistics {
    protected createTransport(): Transport {
        return new Truck();
    }
}
 
class Ship implements Transport { /* ... */ }
class SeaLogistics extends Logistics {
    protected createTransport(): Transport {
        return new Ship();
    }
}
 
class Plane implements Transport { /* ... */ }
class AirLogistics extends Logistics {
    protected createTransport(): Transport {
        return new Plane();
    }
}

Why Parallel Hierarchies?

Parallel hierarchies emerge naturally from the Factory Method pattern. Each ConcreteCreator needs to create a specific ConcreteProduct, so they pair up. This parallelism makes the pattern predictable and easy to extend—add a new product, add a corresponding creator.

Trade-off awareness:

Parallel hierarchies can become a maintenance burden if they grow large. Every new product requires a new creator. Some developers consider this a downside, but the benefit is that each pair is self-contained and independently testable.

Summary: Participants and Their Roles

Let's consolidate our understanding of Factory Method's structure:

Factory Method Participants Summary
Participant	Type	Primary Responsibility
Product	Interface/Abstract	Define interface for created objects
ConcreteProduct	Class	Implement Product interface with specific behavior
Creator	Abstract Class	Declare factory method; use it in operations
ConcreteCreator	Class	Override factory method to return ConcreteProduct

Key Structural Insights

•Two parallel hierarchies — Creator hierarchy and Product hierarchy mirror each other.
•Factory method bridges hierarchies — The factory method in Creator returns Product; override in ConcreteCreator returns ConcreteProduct.
•Creator doesn't know ConcreteProducts — Only works with Product interface, ensuring decoupling.
•new lives in ConcreteCreator — This is the only place concrete instantiation occurs.
•Polymorphism enables substitution — Different ConcreteCreators can be swapped without changing client code.

In the next page, we'll explore real-world use cases and examples of Factory Method—seeing how this structural pattern applies to document processing, UI frameworks, database connections, and more.

Page Complete

You now have a complete structural understanding of Factory Method. You can identify the four participants, understand their responsibilities, and see how they collaborate through the factory method to achieve polymorphic object creation.

3 / 4

Loading learning content...

System Design (HLD)Creational Patterns

Factory Method Pattern

LevelIntermediate

Duration60 mins

TopicCreational Patterns

3 / 4

Participants and Structure

The Anatomy of Factory Method

What You Will Learn

The Four Participants

The Factory Method pattern consists of four participants that work together:

Product — The interface for objects the factory method creates
ConcreteProduct — Implements the Product interface
Creator — Declares the factory method; may provide a default implementation
ConcreteCreator — Overrides the factory method to return a ConcreteProduct

Let's examine each in detail.

Converting Mermaid diagram...

This class diagram shows the fundamental structure. Notice the two parallel hierarchies:

Creator hierarchy (left): Creator → ConcreteCreatorA, ConcreteCreatorB
Product hierarchy (right): Product → ConcreteProductA, ConcreteProductB

The factory method in Creator returns Product. Each ConcreteCreator overrides it to return its matching ConcreteProduct.

Product: The Creation Target

The Product defines the interface for the objects that the factory method creates. This is the abstraction that both the Creator and client code depend upon.

product-interface.ts
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
// Product: The interface for objects the factory method creates
// Can be an interface or abstract class
 
// Example 1: Interface-based Product
interface Document {
    // Core operations all documents must support
    parse(): void;
    validate(): boolean;
    render(): string;
    
    // Properties
    readonly path: string;
    readonly format: DocumentFormat;
}
 
// Example 2: Abstract class-based Product (with shared behavior)
abstract class Transport {
    protected passengers: number = 0;
    
    // Abstract methods - subclasses must implement
    abstract deliver(cargo: Cargo): void;
    abstract getCapacity(): number;
    
    // Concrete methods - shared behavior
    loadPassengers(count: number): void {
        if (count > this.getCapacity()) {
            throw new Error('Exceeds capacity');
        }
        this.passengers = count;
    }
    
    getPassengerCount(): number {
        return this.passengers;
    }
}

Product Responsibilities

•Define the contract — Declare all operations that ConcreteProducts must implement.
•Enable polymorphism — Allow Creator to work with any ConcreteProduct through the common interface.
•Support substitutability — Any ConcreteProduct should be substitutable where Product is expected (Liskov Substitution Principle).
•Optionally share behavior — If an abstract class, can provide default implementations of common operations.

Interface vs Abstract Class

ConcreteProduct: The Actual Objects

ConcreteProduct classes implement the Product interface. These are the actual objects that get created and used. Each ConcreteProduct provides its own implementation of the Product operations.

concrete-products.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
// ConcreteProducts implement the Product interface
 
// ConcreteProduct 1: PDF Document
class PdfDocument implements Document {
    readonly format = DocumentFormat.PDF;
    private content: PdfContent | null = null;
    
    constructor(readonly path: string) {}
    
    parse(): void {
        // PDF-specific parsing using pdf.js or similar
        const buffer = readFileSync(this.path);
        this.content = PdfParser.parse(buffer);
    }
    
    validate(): boolean {
        if (!this.content) return false;
        return this.content.isValid() && this.content.hasRequiredMetadata();
    }
    
    render(): string {
        if (!this.content) throw new Error('Document not parsed');
        return this.content.toHtml();
    }
}
 
// ConcreteProduct 2: Word Document
class WordDocument implements Document {
    readonly format = DocumentFormat.WORD;
    private doc: WordContent | null = null;
    
    constructor(readonly path: string) {}
    
    parse(): void {
        // Word-specific parsing using docx library
        const zip = readWordFile(this.path);
        this.doc = WordParser.parse(zip);
    }
    
    validate(): boolean {
        if (!this.doc) return false;
        return this.doc.hasValidStructure();
    }
    
    render(): string {
        if (!this.doc) throw new Error('Document not parsed');
        return this.doc.toHtml();
    }
}
 
// ConcreteProduct 3: Markdown Document
class MarkdownDocument implements Document {
    readonly format = DocumentFormat.MARKDOWN;
    private text: string = '';
    
    constructor(readonly path: string) {}
    
    parse(): void {
        // Simple text reading for markdown
        this.text = readFileSync(this.path, 'utf-8');
    }
    
    validate(): boolean {
        // Markdown is always valid text
        return this.text.length > 0;
    }
    
    render(): string {
        // Convert markdown to HTML
        return marked(this.text);
    }
}

ConcreteProduct Responsibilities

•Implement Product interface — Provide concrete implementations of all declared operations.
•Encapsulate specifics — Hide implementation details behind the Product interface.
•Be self-contained — Should work independently once created; don't rely on Creator.
•Handle type-specific logic — All format/type-specific behavior belongs in ConcreteProduct.

The Separation of Concerns

Creator: The Factory Method Holder

creator.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// Creator: Declares the factory method and uses it
 
abstract class DocumentProcessor {
    // ==========================================
    // THE FACTORY METHOD
    // ==========================================
    // - Return type is the Product interface
    // - Can be abstract (must override) or virtual (optional override)
    // - Usually protected (only subclasses use it)
    // - Named descriptively: createX, makeX, buildX
    protected abstract createDocument(path: string): Document;
    
    // ==========================================
    // OPERATIONS THAT USE THE FACTORY METHOD
    // ==========================================
    // These methods call the factory method to get products
    // They work with the Product interface, not concrete classes
    
    processDocument(path: string): ProcessingResult {
        // Step 1: Create document via factory method
        const document = this.createDocument(path);
        
        // Step 2: Use the document through its interface
        document.parse();
        
        if (!document.validate()) {
            return { success: false, error: 'Validation failed' };
        }
        
        const rendered = document.render();
        return { success: true, content: rendered };
    }
    
    batchProcess(paths: string[]): ProcessingResult[] {
        return paths.map(path => this.processDocument(path));
    }
    
    compareDocuments(path1: string, path2: string): Comparison {
        // Factory method called multiple times
        const doc1 = this.createDocument(path1);
        const doc2 = this.createDocument(path2);
        
        doc1.parse();
        doc2.parse();
        
        return new Comparison(doc1.render(), doc2.render());
    }
}
 
// Creator with default implementation
abstract class LoggingApplication {
    private logger: Logger | null = null;
    
    // Virtual factory method with default
    protected createLogger(): Logger {
        return new ConsoleLogger();  // Default implementation
    }
    
    protected getLogger(): Logger {
        if (!this.logger) {
            this.logger = this.createLogger();
        }
        return this.logger;
    }
    
    log(message: string): void {
        this.getLogger().log(message);
    }
}

The Creator has two core aspects:

The Factory Method

•Declares return type as Product interface
•Abstract forces subclass implementation
•Virtual allows optional override
•Protected limits access to hierarchy
•Naming convention: create*, make*, build*

Operations Using Factory Method

•Call factory method, not new
•Work with Product interface only
•Never reference ConcreteProducts
•Contain business logic
•Unchanged when new products added

Common Mistake: Creator Knowing ConcreteProducts

ConcreteCreator: The Decision Maker

ConcreteCreator classes override the factory method to return an instance of a ConcreteProduct. This is where the actual new call lives. Each ConcreteCreator is paired with a ConcreteProduct.

concrete-creators.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
// ConcreteCreators override the factory method
 
// ConcreteCreator for PDF documents
class PdfDocumentProcessor extends DocumentProcessor {
    protected createDocument(path: string): Document {
        return new PdfDocument(path);
    }
}
 
// ConcreteCreator for Word documents
class WordDocumentProcessor extends DocumentProcessor {
    protected createDocument(path: string): Document {
        return new WordDocument(path);
    }
}
 
// ConcreteCreator for Markdown documents
class MarkdownDocumentProcessor extends DocumentProcessor {
    protected createDocument(path: string): Document {
        return new MarkdownDocument(path);
    }
}
 
// ConcreteCreator with complex construction logic
class ConfiguredPdfProcessor extends DocumentProcessor {
    constructor(
        private readonly config: PdfConfig,
        private readonly plugins: PdfPlugin[]
    ) {
        super();
    }
    
    protected createDocument(path: string): Document {
        // Factory method can contain complex creation logic
        const doc = new PdfDocument(path);
        
        // Apply configuration
        doc.setRenderingMode(this.config.renderingMode);
        doc.setDpi(this.config.dpi);
        
        // Install plugins
        for (const plugin of this.plugins) {
            doc.installPlugin(plugin);
        }
        
        return doc;
    }
}
 
// ConcreteCreator for testing
class TestDocumentProcessor extends DocumentProcessor {
    private createdDocuments: MockDocument[] = [];
    
    protected createDocument(path: string): Document {
        const mock = new MockDocument(path);
        this.createdDocuments.push(mock);
        return mock;
    }
    
    // Test helper methods
    getCreatedDocuments(): MockDocument[] {
        return this.createdDocuments;
    }
    
    getDocumentAt(index: number): MockDocument {
        return this.createdDocuments[index];
    }
}

ConcreteCreator Responsibilities

•Override factory method — Provide the specific implementation that creates ConcreteProduct.
•Call new — This is the only place in the pattern where new ConcreteProduct() appears.
•Encapsulate creation logic — Complex construction (configuration, plugins, initialization) belongs here.
•Enable substitution — Different ConcreteCreators can be swapped to change product types.

The Pairing Pattern

How Participants Collaborate

Understanding how these participants interact at runtime is crucial. Let's trace through a complete execution.

collaboration-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
// Step 1: Client instantiates a ConcreteCreator
const processor: DocumentProcessor = new PdfDocumentProcessor();
 
// Step 2: Client calls operation on Creator (polymorphically)
const result = processor.processDocument('/docs/report.pdf');
 
// What happens inside processDocument():
// 
// processDocument() {
//     // Step 3: Creator calls factory method
//     const document = this.createDocument(path);
//     
//     // At runtime, 'this' is PdfDocumentProcessor
//     // So createDocument() returns new PdfDocument(path)
//     
//     // Step 4: Creator uses Product through interface
//     document.parse();      // Calls PdfDocument.parse()
//     document.validate();   // Calls PdfDocument.validate()
//     document.render();     // Calls PdfDocument.render()
// }
 
// The key insight: Creator code never changes,
// but different ConcreteCreators produce different behavior

The collaboration sequence:

Converting Mermaid diagram...

Collaboration Highlights

•Client creates ConcreteCreator — This is the configuration point where product type is determined.
•Client calls inherited method — The client uses the Creator interface, calling methods like processDocument().
•Creator calls factory method — Inside the inherited method, this.createDocument() is called.
•Polymorphism kicks in — Even though the method is in Creator, this is ConcreteCreator, so the overridden factory method runs.
•ConcreteCreator creates ConcreteProduct — The new call happens in the overridden factory method.
•Creator uses Product — The Creator continues using the returned object through the Product interface.

Structural Variations

The basic Factory Method structure admits several variations depending on your needs.

Creator and Product in one hierarchy:

Sometimes the Creator and Product are the same class—the Creator creates instances of its own type.

single-hierarchy.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
// The Creator IS the Product
abstract class Component {
    protected children: Component[] = [];
    
    // Factory method returns same type
    abstract clone(): Component;
    
    addChild(child: Component): void {
        this.children.push(child);
    }
    
    deepClone(): Component {
        const cloned = this.clone();
        for (const child of this.children) {
            cloned.addChild(child.deepClone());
        }
        return cloned;
    }
}
 
class Button extends Component {
    constructor(private label: string) { super(); }
    
    clone(): Component {
        return new Button(this.label);
    }
}
 
class Panel extends Component {
    constructor(private title: string) { super(); }
    
    clone(): Component {
        return new Panel(this.title);
    }
}

This is common in Prototype-like scenarios where objects need to create copies of themselves.

The Parallel Hierarchies Pattern

A distinctive characteristic of Factory Method is the creation of parallel hierarchies: one for Creators and one for Products. These hierarchies mirror each other.

parallel-hierarchies.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
// PRODUCT HIERARCHY                    // CREATOR HIERARCHY
// ---------------------                 // ---------------------
// 
// Transport (interface)                 // Logistics (abstract)
//   ├── Truck                           //   ├── RoadLogistics
//   ├── Ship                            //   ├── SeaLogistics
//   └── Plane                           //   └── AirLogistics
 
// The hierarchies are parallel:
// RoadLogistics creates Truck
// SeaLogistics creates Ship
// AirLogistics creates Plane
 
interface Transport {
    deliver(cargo: Cargo): Delivery;
}
 
abstract class Logistics {
    planDelivery(cargo: Cargo): DeliveryPlan {
        const transport = this.createTransport();
        return {
            transport: transport,
            route: this.calculateRoute(cargo),
            estimatedTime: transport.estimateTime(cargo),
        };
    }
    
    protected abstract createTransport(): Transport;
    protected abstract calculateRoute(cargo: Cargo): Route;
}
 
// Parallel implementation pairs
class Truck implements Transport { /* ... */ }
class RoadLogistics extends Logistics {
    protected createTransport(): Transport {
        return new Truck();
    }
}
 
class Ship implements Transport { /* ... */ }
class SeaLogistics extends Logistics {
    protected createTransport(): Transport {
        return new Ship();
    }
}
 
class Plane implements Transport { /* ... */ }
class AirLogistics extends Logistics {
    protected createTransport(): Transport {
        return new Plane();
    }
}

Why Parallel Hierarchies?

Trade-off awareness:

Summary: Participants and Their Roles

Let's consolidate our understanding of Factory Method's structure:

Factory Method Participants Summary
Participant	Type	Primary Responsibility
Product	Interface/Abstract	Define interface for created objects
ConcreteProduct	Class	Implement Product interface with specific behavior
Creator	Abstract Class	Declare factory method; use it in operations
ConcreteCreator	Class	Override factory method to return ConcreteProduct

Key Structural Insights

•Two parallel hierarchies — Creator hierarchy and Product hierarchy mirror each other.
•Factory method bridges hierarchies — The factory method in Creator returns Product; override in ConcreteCreator returns ConcreteProduct.
•Creator doesn't know ConcreteProducts — Only works with Product interface, ensuring decoupling.
•new lives in ConcreteCreator — This is the only place concrete instantiation occurs.
•Polymorphism enables substitution — Different ConcreteCreators can be swapped without changing client code.

Page Complete

3 / 4