Pattern Comparison - Choosing the Right Creational Pattern | OneNoughtOne

0/290

System Design (LLD)Choosing the Right Creational Pattern

Choosing the Right Creational Pattern

LevelAdvanced

Duration90 mins

TopicChoosing the Right Creational Pattern

1 / 4

Pattern Comparison

The Selection Dilemma

You've studied Factory Method, Abstract Factory, Builder, Prototype, Singleton, and Object Pool. You understand their structure, participants, and individual use cases. But now comes the truly challenging question—when faced with a real design problem, which pattern should you choose?

This isn't an academic exercise. In production systems, the wrong creational pattern choice leads to rigid architectures, excessive complexity, or inability to evolve. The right choice creates elegant, maintainable systems that adapt gracefully to changing requirements.

The patterns we've studied aren't interchangeable alternatives—they solve fundamentally different problems. Yet their superficial similarity (they all create objects) obscures their distinct purposes. This page provides a systematic framework for distinguishing these patterns and selecting the right one for each situation.

What You Will Learn

By the end of this page, you will understand the core distinctions between all six creational patterns, be able to compare them across multiple dimensions, and recognize the signature characteristics that indicate when each pattern applies. You'll move from knowing patterns individually to understanding them as a cohesive toolkit.

The Core Intent of Each Pattern

Before comparing patterns, we must crystalize the fundamental intent of each. Patterns often look similar in implementation, but their motivations differ profoundly. Understanding intent is the first filter in pattern selection.

Every creational pattern addresses a specific tension in object creation. Let's examine each pattern's essential purpose:

Core Intent of Creational Patterns
Pattern	Core Intent	One-Sentence Summary
Factory Method	Defer instantiation to subclasses	Let subclasses decide which class to instantiate, enabling framework-level hooks for object creation.
Abstract Factory	Create families of related objects	Produce consistent sets of objects that belong together without specifying their concrete classes.
Builder	Construct complex objects step-by-step	Separate the construction process from representation, allowing the same process to create different outcomes.
Prototype	Create objects by copying existing ones	Avoid the cost of creation from scratch by cloning pre-configured instances.
Singleton	Ensure exactly one instance exists	Provide a global point of access to a single instance that coordinates across the system.
Object Pool	Reuse expensive objects	Manage a pool of pre-created objects to eliminate repeated creation/destruction overhead.

Intent Is Your First Filter

When selecting a pattern, start by articulating the problem you're solving. Does it involve deferring instantiation decisions? Creating object families? Step-by-step construction? Cloning? Ensuring uniqueness? Reusing expensive resources? The answer immediately narrows your options.

The problem-to-pattern mapping:

The key insight is that each pattern answers a different question:

Factory Method: "How do I let subclasses customize which objects are created?"
Abstract Factory: "How do I ensure I create objects that work together?"
Builder: "How do I construct objects with many optional parts or configurations?"
Prototype: "How do I create objects when configuration is expensive but copying is cheap?"
Singleton: "How do I guarantee exactly one instance while providing global access?"
Object Pool: "How do I avoid the cost of repeatedly creating and destroying expensive objects?"

If you can phrase your problem as one of these questions, you've identified the pattern.

When Creation Variability Matters

Three of our patterns—Factory Method, Abstract Factory, and Builder—address situations where what gets created or how it's created varies. Understanding the nature of this variability is crucial for choosing between them.

Factory Method deals with variability in the type of object created. The creation logic is fixed, but the specific class instantiated depends on the subclass implementing the factory method.

Abstract Factory addresses variability in families of objects. When your system must work with sets of related objects (e.g., UI widgets for different platforms), Abstract Factory ensures you get a consistent family.

Builder handles variability in the construction process itself. When objects have many optional components or require complex assembly, Builder separates this complexity from the object's representation.

Factory Method: Type Variability

•Single object creation varies by type
•Framework provides creation hook
•Subclasses determine concrete class
•Uses inheritance to vary creation
•Example: Document editors where subclasses create different document types

Abstract Factory: Family Variability

•Multiple related objects created together
•Objects must be compatible (same family)
•Factory produces entire product line
•Uses composition over inheritance
•Example: Cross-platform UI where buttons, menus, and dialogs must match

Builder: Construction Process Variability

•Complex objects with many optional parts
•Same construction process produces different representations
•Step-by-step assembly required
•Separation of algorithm from representation
•Example: Meal builders that can create vegetarian, vegan, or regular meals using the same assembly process

Quick Distinction

If you're creating one object and the type varies, consider Factory Method. If you're creating multiple related objects that must be compatible, consider Abstract Factory. If construction is complex with many optional steps, consider Builder.

When Object Reuse Matters

Three patterns—Prototype, Singleton, and Object Pool—are fundamentally about reusing objects rather than creating new ones from scratch. However, they differ in what is reused and why.

Prototype reuses an existing object's configuration. When creating an object from scratch is expensive (due to complex initialization, resource loading, or extensive configuration), cloning a pre-configured prototype is faster.

Singleton reuses a single instance across the entire application. The goal isn't performance—it's ensuring that all parts of the system work with the same object, maintaining consistency.

Object Pool reuses multiple instances to amortize creation cost over time. Unlike Singleton (one instance, shared) or Prototype (many clones, independent), Object Pool maintains a bounded set of instances that are checked out, used, and returned.

Object Reuse Patterns Compared
Dimension	Prototype	Singleton	Object Pool
Number of instances	Unlimited (via cloning)	Exactly one	Bounded pool
Reuse mechanism	Clone configuration	Share single instance	Borrow and return
Primary motivation	Avoid expensive initialization	Ensure global consistency	Amortize creation/destruction cost
Client relationship	Each client owns their clone	All clients share one instance	Clients borrow temporarily
State isolation	Clones are independent	State is shared (careful!)	State reset between uses
Thread safety concern	Clones are isolated	High (shared mutable state)	Medium (pool access, reset)

Choosing between reuse patterns:

The selection criteria are clear once you understand the core differences:

Prototype: Use when initialization is expensive, but each client needs their own independent copy. Example: Game objects with complex texture/mesh loading.
Singleton: Use when there must be exactly one instance and all parts of the system need access to it. Example: Configuration manager, logging facade.
Object Pool: Use when creation/destruction is expensive and you don't need simultaneous unbounded instances. Example: Database connections, thread workers, socket connections.

Singleton Warning

Singleton is often overused. If your motivation is 'I want global access' rather than 'I need exactly one instance,' you're likely misusing the pattern. Consider dependency injection instead. Singleton creates hidden dependencies and makes testing difficult.

Complexity and Structure Comparison

Patterns differ significantly in their structural complexity and the number of participating classes. This matters for two reasons: simpler patterns are easier to implement and maintain, but more complex patterns handle more sophisticated scenarios. Choosing the simplest pattern that solves your problem is a key design principle.

Let's rank the patterns by structural complexity:

Structural Complexity Ranking (Low to High)

•Singleton: Minimal structure—just one class with private constructor and static accessor.
•Prototype: Simple—clone interface plus concrete prototypes. Add registry for more sophistication.
•Object Pool: Moderate—pool manager class plus pooled objects with lifecycle methods.
•Factory Method: Moderate—creator hierarchy parallel to product hierarchy.
•Builder: Moderate to complex—builder interface, concrete builders, optional director, product.
•Abstract Factory: Complex—factory interface, concrete factories, multiple product hierarchies.

Structure drives evolution cost:

The structural complexity of a pattern determines how much code changes when you extend it:

Pattern	To Add New Product Type
Factory Method	Add new creator subclass + product class
Abstract Factory	Add methods to all factories + new product classes
Builder	Add new builder + modify director (if used)
Prototype	Add new cloneable product to registry
Singleton	N/A (only one instance)
Object Pool	Modify pooled object class or pool configuration

Guideline: Choose the simplest pattern that meets your needs. Don't use Abstract Factory when Factory Method suffices. Don't use Builder when a simple constructor works.

YAGNI Applies to Patterns

Just because Abstract Factory is more powerful doesn't mean you should reach for it first. If you only have one product type that varies, Factory Method is sufficient. If construction is simple, skip Builder entirely. Pattern complexity should match problem complexity.

Composition vs Inheritance in Creational Patterns

A fundamental distinction among creational patterns is whether they rely primarily on inheritance (subclassing) or composition (object relationships). This significantly affects flexibility, testability, and evolution.

Inheritance-based patterns require you to create subclasses to vary behavior. This provides compile-time type safety but creates class hierarchies that can become rigid.

Composition-based patterns rely on delegating to helper objects. This provides runtime flexibility and is generally preferred for modern designs, but requires more careful interface design.

Inheritance vs Composition in Creational Patterns
Pattern	Primary Mechanism	Implications
Factory Method	Inheritance	Subclass per product type; parallel hierarchies can emerge
Abstract Factory	Composition	Inject factory; easy to swap families at runtime
Builder	Composition	Inject builder; director orchestrates without knowing builder type
Prototype	Composition (with delegation)	Clone existing object; no class hierarchy required
Singleton	Neither (structural)	Single class with controlled instantiation
Object Pool	Composition	Pool manages object lifecycle independently

Inheritance Limitations

•Creates tight coupling between classes
•Decisions frozen at compile time
•Class explosion with many variants
•Harder to test in isolation
•Violates 'favor composition' principle

Composition Benefits

•Loose coupling via interfaces
•Runtime flexibility
•Easier unit testing with mocks
•More modular design
•Aligns with dependency injection

Modern Preference

Modern software design strongly favors composition over inheritance. Factory Method (inheritance-based) is often evolved into Abstract Factory or simple parameterized factories in contemporary codebases. If you're choosing between patterns, prefer composition-based approaches unless inheritance provides clear benefits.

Pattern Relationships and Evolution

Creational patterns aren't isolated islands—they have relationships and evolutionary paths. Understanding these relationships helps you evolve designs gracefully as requirements change.

Patterns often start simple and evolve to more complex forms:

Factory Method → Abstract Factory: You start with Factory Method for one product type. As you add more related products that must be consistent, you evolve to Abstract Factory.

Simple Constructor → Builder: You start with a constructor. As optional parameters multiply, you add telescoping constructors, then finally evolve to Builder.

new() Calls → Prototype: You start creating objects directly. When initialization becomes expensive or configuration-heavy, you introduce Prototype.

Static Instance → Singleton → Dependency Injection: You start with a global instance. You formalize it as Singleton. You eventually recognize the problems and evolve toward DI.

evolution-examples.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
36
37
38
39
// Evolution: Constructor → Telescoping → Builder
 
// Stage 1: Simple constructor
class Pizza {
    constructor(size: string, cheese: boolean, pepperoni: boolean,
                mushrooms: boolean, onions: boolean, bacon: boolean) {
        // Painful for callers: new Pizza("large", true, false, true, false, true)
    }
}
 
// Stage 2: Telescoping constructors (still awkward)
class PizzaV2 {
    constructor(size: string, cheese?: boolean, pepperoni?: boolean,
                mushrooms?: boolean, onions?: boolean, bacon?: boolean) {
        // Slightly better, but order still matters
    }
}
 
// Stage 3: Builder pattern
class PizzaBuilder {
    private size: string = "medium";
    private toppings: Set<string> = new Set();
 
    setSize(size: string): this {
        this.size = size;
        return this;
    }
 
    addTopping(topping: string): this {
        this.toppings.add(topping);
        return this;
    }
 
    build(): Pizza {
        return new Pizza(/* ... */);
    }
}
 
// Clean: new PizzaBuilder().setSize("large").addTopping("cheese").build()

Pattern substitution relationships:

Some patterns can substitute for others in specific contexts:

Instead of...	You might use...	When?
Factory Method	Simple factory function	When inheritance hierarchy is overkill
Abstract Factory	Dependency injection	When you want even looser coupling
Prototype	Factory with configuration	When cloning semantics aren't needed
Singleton	Scoped instance via DI	When global access isn't required
Object Pool	On-demand creation	When objects aren't actually expensive

Design Is Iteration

Don't over-engineer upfront. Start with the simplest solution (maybe just constructor calls or factory functions). Evolve to formal patterns when complexity genuinely warrants it. The evolutionary paths above are natural progressions—use them when needed, not preemptively.

Comprehensive Comparison Matrix

Let's consolidate everything into a comprehensive comparison matrix. This serves as a reference when evaluating which pattern fits your situation.

Complete Creational Pattern Comparison
Criterion	Factory Method	Abstract Factory	Builder	Prototype	Singleton	Object Pool
Primary purpose	Defer type to subclass	Create product families	Step-by-step construction	Clone existing objects	Single global instance	Reuse expensive objects
When to use	Type varies by subclass	Need compatible object sets	Complex construction	Expensive initialization	Exactly one instance	Creation/destruction cost
Mechanism	Inheritance	Composition	Composition	Composition	Static access	Composition
Flexibility	Medium	High	High	High	Low	Medium
Testability	Medium	High	High	High	Low	Medium
Complexity	Low-Medium	Medium-High	Medium	Low	Low	Medium
Instance count	New per call	New per call	New per build	Clone per request	Exactly one	Pooled/bounded
Common misuse	Over-subclassing	Used for single product	Simple objects	Ignoring deep copy	Overuse for global state	Non-expensive objects

Use This Matrix as a Reference

Bookmark this comparison. When facing a creational design decision, review the matrix to quickly narrow down candidates based on your specific criteria—primary purpose, flexibility needs, testability requirements, and acceptable complexity.

Summary: Pattern Comparison

We've systematically compared all six creational patterns across multiple dimensions. Let's consolidate the key insights:

Key Takeaways

•Intent is the first filter — Each pattern answers a distinct question about object creation. Start by articulating your problem.
•Variability-focused patterns — Factory Method (type), Abstract Factory (family), Builder (construction) address different kinds of creation variability.
•Reuse-focused patterns — Prototype (clone configuration), Singleton (single instance), Object Pool (amortize cost) serve different reuse goals.
•Prefer composition over inheritance — Modern design favors Abstract Factory, Builder, and Prototype over Factory Method's inheritance approach.
•Match complexity to problem — Choose the simplest pattern that solves your problem. Don't over-engineer.
•Patterns evolve — Designs naturally progress from simple constructors to formal patterns as complexity grows. Embrace this evolution.

What's next:

With a solid understanding of how patterns compare, the next page presents a decision tree—a systematic flowchart for selecting the right creational pattern. You'll learn to navigate from problem characteristics to pattern choice through a series of decisive questions.

Page Complete

You now understand how creational patterns compare across intent, variability, reuse, complexity, and mechanism. You can distinguish between similar-looking patterns and understand their evolutionary relationships. Next, we'll build a decision framework for pattern selection.