Problem: Creating Objects by Copying Existing Ones - Prototype Pattern | OneNoughtOne

0/246

System Design (LLD)Prototype Pattern

Prototype Pattern: Object Cloning for Efficient Creation

LevelIntermediate

Duration75 mins

TopicPrototype Pattern

1 / 4

Problem: Creating Objects by Copying Existing Ones

When Creating Objects the Normal Way Fails

In object-oriented programming, we typically create objects using constructors—invoking new with a class name and passing constructor arguments. This approach works well for most scenarios, but certain situations reveal its fundamental limitations:

What if you don't know the concrete class at compile time? What if object creation is prohibitively expensive and you need many similar copies? What if the object's configuration is complex and you want to preserve a pre-configured state as a template?

These scenarios point to a fundamentally different approach to object creation: copying existing objects rather than constructing new ones from scratch. This is the domain of the Prototype Pattern—one of the original Gang of Four creational patterns that remains surprisingly relevant in modern software development.

What You Will Learn

By the end of this page, you will understand the specific problems that make object cloning preferable to traditional instantiation. You'll recognize pattern signatures in your own code that suggest the Prototype Pattern, and you'll understand why this pattern exists as a first-class creational mechanism alongside factories and builders.

The Fundamental Tension in Object Creation

Every object-oriented system must address a fundamental question: How do we create objects in a way that maintains flexibility, encapsulation, and performance?

Traditional constructor-based creation has several inherent constraints that become problematic in specific scenarios:

Constraints of Constructor-Based Creation

•Static Binding — The new keyword binds to a specific class at compile time. This creates tight coupling between the creating code and the concrete class being instantiated.
•Repeated Initialization Cost — Each new invocation executes the full initialization sequence, even when creating many similar objects that share most of their configuration.
•Knowledge Requirements — The caller must know the exact class and all required constructor parameters. This exposes implementation details and violates encapsulation.
•Configuration Complexity — Objects with complex setup requirements force callers to understand intricate initialization sequences that should be hidden.
•Runtime Type Discovery — When the concrete type is determined at runtime (e.g., from configuration or user input), constructor-based creation requires explicit type-switching logic.

The core insight:

When you already have a valid, properly-configured instance of an object, that existing object itself becomes the best specification for creating similar objects. The object knows its own type, its own state, and its own structure—information that would otherwise need to be replicated in factory methods or complex constructor calls.

This realization leads to a different philosophy of object creation: let objects create copies of themselves.

Problem Domain: Expensive Object Creation

The most straightforward motivation for the Prototype Pattern emerges when object creation is expensive—when the cost of instantiating a new object from scratch significantly exceeds the cost of copying an existing one.

Consider what happens during object construction:

Expensive Operations During Object Construction
Operation Type	Example Scenario	Typical Cost	Avoidable Via Cloning?
Database Queries	Loading entity relationships from DB	50-500ms per object	Yes — clone pre-loaded state
Network Requests	Fetching configuration from remote service	100-2000ms latency	Yes — clone cached responses
File I/O	Reading template files, parsing XML/JSON	10-100ms depending on size	Yes — clone parsed structure
Complex Calculations	Generating cryptographic keys, computing layouts	Variable, potentially seconds	Yes — clone computed results
External Resource Allocation	Acquiring database connections, thread pools	Significant overhead	Partially — may require adjustments

A concrete example: Document Templates

Imagine a document management system where users create documents from templates. Each template contains:

Complex formatting rules (hundreds of style definitions)
Pre-configured sections with placeholder text
Embedded resources (logos, watermarks, fonts)
Validation schemas for different content types

Loading a template from the database involves multiple queries, parsing XML structures, and initializing internal caches. Without cloning, every new document requires this expensive initialization—even when users create dozens of similar documents in sequence.

expensive-creation-problem.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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// The Problem: Each document creation repeats expensive initialization
class DocumentTemplate {
    private readonly styles: Map<string, StyleDefinition>;
    private readonly sections: Section[];
    private readonly resources: EmbeddedResource[];
    private readonly validationSchema: ValidationSchema;
    
    constructor(templateId: string) {
        // EXPENSIVE: Database query to load template definition
        const templateDef = this.loadFromDatabase(templateId);
        
        // EXPENSIVE: Parse complex XML structure
        this.styles = this.parseStyleDefinitions(templateDef.stylesXml);
        
        // EXPENSIVE: Initialize and validate sections
        this.sections = this.initializeSections(templateDef.sectionData);
        
        // EXPENSIVE: Load binary resources from storage
        this.resources = this.loadEmbeddedResources(templateDef.resourceIds);
        
        // EXPENSIVE: Compile validation schema
        this.validationSchema = this.compileSchema(templateDef.schemaDefinition);
    }
    
    private loadFromDatabase(templateId: string): TemplateDef {
        // 200ms database round-trip
        console.log(`Loading template ${templateId} from database...`);
        return {} as TemplateDef;
    }
    
    private parseStyleDefinitions(xml: string): Map<string, StyleDefinition> {
        // 50ms XML parsing
        console.log("Parsing style definitions...");
        return new Map();
    }
    
    private initializeSections(data: SectionData[]): Section[] {
        // 30ms per section
        console.log("Initializing sections...");
        return [];
    }
    
    private loadEmbeddedResources(ids: string[]): EmbeddedResource[] {
        // 100ms storage access per resource
        console.log("Loading embedded resources...");
        return [];
    }
    
    private compileSchema(def: SchemaDefinition): ValidationSchema {
        // 75ms schema compilation
        console.log("Compiling validation schema...");
        return {} as ValidationSchema;
    }
}
 
// Creating 10 documents from the same template = 10x initialization cost
// Total: ~4.5 seconds (10 × 450ms) for operations that could be instantaneous
for (let i = 0; i < 10; i++) {
    const doc = new DocumentTemplate("invoice-template");
    // Each iteration: 450ms+ of redundant initialization
}

The Hidden Cumulative Cost

In many systems, expensive object creation doesn't manifest as a single slow operation—it appears as cumulative latency across many 'small' creations. A 200ms initialization repeated 50 times in a request cycle becomes 10 seconds of blocked processing. Profiling often reveals these patterns only in production under realistic load.

Problem Domain: Unknown Concrete Types at Compile Time

A subtler but equally important motivation for the Prototype Pattern arises when you cannot know the concrete type of objects at compile time. This situation occurs frequently in plugin architectures, serialization systems, and user-customizable applications.

Consider the challenge: You need to create new instances of objects, but the specific classes are:

Loaded dynamically at runtime
Defined by plugins or extensions
Determined by user configuration
Selected based on external input

The type-switching antipattern:

Without cloning, handling unknown types typically devolves into explicit type-switching—checking the type of an existing object and manually constructing the corresponding concrete class:

type-switching-antipattern.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
// ANTIPATTERN: Type-switching to create copies
// This violates Open/Closed Principle and becomes unmaintainable
 
interface Shape {
    draw(): void;
    getColor(): string;
}
 
class Circle implements Shape {
    constructor(
        public readonly radius: number,
        public readonly color: string,
        public readonly lineWidth: number
    ) {}
    
    draw(): void { /* ... */ }
    getColor(): string { return this.color; }
}
 
class Rectangle implements Shape {
    constructor(
        public readonly width: number,
        public readonly height: number,
        public readonly color: string,
        public readonly lineWidth: number
    ) {}
    
    draw(): void { /* ... */ }
    getColor(): string { return this.color; }
}
 
class Triangle implements Shape {
    constructor(
        public readonly sideA: number,
        public readonly sideB: number,
        public readonly sideC: number,
        public readonly color: string,
        public readonly lineWidth: number
    ) {}
    
    draw(): void { /* ... */ }
    getColor(): string { return this.color; }
}
 
// The problem: creating a copy of an abstract Shape reference
function copyShape(shape: Shape): Shape {
    // We MUST know every concrete type!
    // Adding a new shape type requires modifying this function
    
    if (shape instanceof Circle) {
        return new Circle(shape.radius, shape.color, shape.lineWidth);
    } else if (shape instanceof Rectangle) {
        return new Rectangle(shape.width, shape.height, shape.color, shape.lineWidth);
    } else if (shape instanceof Triangle) {
        return new Triangle(shape.sideA, shape.sideB, shape.sideC, 
                           shape.color, shape.lineWidth);
    }
    // What about new shape types? This function must be updated!
    // What about shapes defined in plugins we haven't loaded yet?
    
    throw new Error(`Unknown shape type: ${shape.constructor.name}`);
}
 
// Real-world scenario: A graphics editor loads shape plugins dynamically
// The editor core cannot possibly know about user-installed shape types
// This approach fundamentally cannot work for extensible systems

Problems with Type-Switching

•Violates Open/Closed Principle — Every new type requires modifying the copy function
•Cannot handle unknown types — Plugins and extensions break this approach
•Exposes internal structure — Must access all constructor parameters
•Error-prone — Easy to miss a field when adding new types
•Maintenance nightmare — Copy logic scattered across the codebase

Cloning Solves These Problems

•Each type handles its own copying — Self-contained clone logic
•Works with unknown types — Objects copy themselves regardless of caller's knowledge
•Encapsulates internal structure — Private fields stay private
•Guaranteed completeness — Each class copies itself correctly
•Centralized copy logic — Clone method lives with its class

Problem Domain: Preserving Complex Configuration

Some objects reach their useful state through a complex sequence of configuration steps that involve multiple method calls, conditional setup, and interdependent options. These objects act as runtime configurations—templates that encode decisions made through user interaction, system defaults, and computed values.

Recreating this configuration for each new instance would require duplicating the entire setup sequence—a wasteful and error-prone approach. Cloning offers a much more elegant solution: capture the configuration once, replicate it freely.

complex-configuration-problem.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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
// The Problem: Complex configuration that's tedious to replicate
interface ReportConfiguration {
    title: string;
    columns: ColumnDefinition[];
    filters: FilterCriteria[];
    sorting: SortOrder[];
    grouping: GroupingConfig | null;
    aggregations: AggregationConfig[];
    formatting: FormattingOptions;
    exportSettings: ExportSettings;
    permissions: PermissionSet;
    scheduling: ScheduleConfig | null;
}
 
class ReportBuilder {
    private config: Partial<ReportConfiguration> = {};
    
    // Each user spends 10-20 clicks configuring a report
    setTitle(title: string): this { this.config.title = title; return this; }
    
    addColumn(column: ColumnDefinition): this {
        this.config.columns = [...(this.config.columns || []), column];
        return this;
    }
    
    addFilter(filter: FilterCriteria): this {
        this.config.filters = [...(this.config.filters || []), filter];
        return this;
    }
    
    setSorting(sorting: SortOrder[]): this {
        this.config.sorting = sorting;
        return this;
    }
    
    setGrouping(grouping: GroupingConfig): this {
        this.config.grouping = grouping;
        return this;
    }
    
    addAggregation(agg: AggregationConfig): this {
        this.config.aggregations = [...(this.config.aggregations || []), agg];
        return this;
    }
    
    setFormatting(options: FormattingOptions): this {
        this.config.formatting = options;
        return this;
    }
    
    setExportSettings(settings: ExportSettings): this {
        this.config.exportSettings = settings;
        return this;
    }
    
    setPermissions(permissions: PermissionSet): this {
        this.config.permissions = permissions;
        return this;
    }
    
    setSchedule(schedule: ScheduleConfig): this {
        this.config.scheduling = schedule;
        return this;
    }
    
    build(): Report {
        return new Report(this.config as ReportConfiguration);
    }
}
 
// User carefully configures a sales report through the UI
const salesReport = new ReportBuilder()
    .setTitle("Q4 Sales by Region")
    .addColumn({ name: "Region", type: "string" })
    .addColumn({ name: "Sales", type: "currency" })
    .addColumn({ name: "Growth", type: "percentage" })
    .addFilter({ field: "Year", operator: "eq", value: 2024 })
    .addFilter({ field: "Quarter", operator: "eq", value: "Q4" })
    .setSorting([{ field: "Sales", direction: "desc" }])
    .setGrouping({ field: "Region", aggregateChildren: true })
    .addAggregation({ field: "Sales", function: "sum" })
    .addAggregation({ field: "Growth", function: "avg" })
    .setFormatting({ currency: "USD", dateFormat: "MM/DD/YYYY" })
    .setExportSettings({ format: "xlsx", includeCharts: true })
    .setPermissions({ viewable: ["sales-team"], editable: ["managers"] })
    .setSchedule({ frequency: "weekly", day: "Monday", time: "08:00" })
    .build();
 
// Now the user wants a similar report for Q3
// WITHOUT cloning, they must repeat the entire 15-step configuration
// WITH cloning, they copy the report and change only what differs
 
// What we need:
// const q3Report = salesReport.clone()
//     .setTitle("Q3 Sales by Region")
//     .updateFilter("Quarter", "Q3");

Prototypes as Templates

When users create complex configurations interactively, those configurations become valuable artifacts. The Prototype Pattern transforms any configured object into a reusable template—allowing users to 'save' their setup and create variations without starting from scratch.

Problem Domain: Avoiding Subclass Explosion

Factory patterns typically require one factory or factory method for each concrete product type. When the number of product variations is large or grows dynamically, this leads to subclass explosion—a proliferation of factory classes that mirror the product hierarchy.

The Prototype Pattern offers an alternative: instead of subclassing factories, register prototype instances and clone them on demand. The registry holds one instance of each variation, and creating new objects becomes a matter of looking up and cloning the appropriate prototype.

Comparison: Factory Subclassing vs Prototype Registry
Aspect	Factory Subclasses	Prototype Registry
For N product types:	N factory classes or methods	N prototype instances
Adding new type:	Create new factory class/method	Register new prototype instance
Runtime extensibility:	Difficult — requires code changes	Easy — just register new prototype
Memory overhead:	Minimal — factories are stateless	Higher — must keep prototype instances
Configuration flexibility:	Fixed at compile time	Can adjust prototype state at runtime
Plugin support:	Requires factory plugin interface	Plugins register their own prototypes

subclass-explosion-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// The Problem: Factory Method leads to subclass explosion
// Each new button style requires a new factory class
 
// Product interface
interface Button {
    render(): void;
}
 
// Concrete products - and there could be many more
class PrimaryButton implements Button {
    render(): void { console.log("Rendering primary button"); }
}
 
class SecondaryButton implements Button {
    render(): void { console.log("Rendering secondary button"); }
}
 
class DangerButton implements Button {
    render(): void { console.log("Rendering danger button"); }
}
 
class GhostButton implements Button {
    render(): void { console.log("Rendering ghost button"); }
}
 
class LinkButton implements Button {
    render(): void { console.log("Rendering link button"); }
}
 
// PROBLEM: Factory Method requires parallel factory hierarchy
abstract class ButtonFactory {
    abstract createButton(): Button;
}
 
// Each product type needs a corresponding factory class!
class PrimaryButtonFactory extends ButtonFactory {
    createButton(): Button { return new PrimaryButton(); }
}
 
class SecondaryButtonFactory extends ButtonFactory {
    createButton(): Button { return new SecondaryButton(); }
}
 
class DangerButtonFactory extends ButtonFactory {
    createButton(): Button { return new DangerButton(); }
}
 
class GhostButtonFactory extends ButtonFactory {
    createButton(): Button { return new GhostButton(); }
}
 
class LinkButtonFactory extends ButtonFactory {
    createButton(): Button { return new LinkButton(); }
}
 
// With 20 button variants: 20 product classes + 20 factory classes = 40 classes
// With 50 button variants: 50 product classes + 50 factory classes = 100 classes
 
// And this doesn't even account for variations like:
// - PrimarySmallButton, PrimaryLargeButton
// - DangerRoundedButton, DangerSquareButton
// - Each combination would traditionally require its own factory
 
// The Prototype Pattern eliminates the parallel factory hierarchy entirely
// by letting objects clone themselves

When Subclass Explosion Becomes Critical

Subclass explosion is particularly painful in UI component libraries, document template systems, game entity frameworks, and any domain where variations multiply combinatorially. If you find yourself creating factory classes that differ only in which constructor they call, the Prototype Pattern may be a better fit.

Real-World Scenarios Requiring Object Cloning

The problems we've discussed manifest across many real-world domains. Understanding where cloning naturally fits helps you recognize the pattern in your own work:

Domain-Specific Applications

•Graphics Editors — Users create a shape, configure its properties (color, line width, shadow, effects), then duplicate it to create similar shapes. Cloning preserves all configuration without reimplementing the property-assignment workflow.
•Game Development — Game entities (enemies, projectiles, power-ups) often spawn as variations of base prototypes. An 'archer enemy' prototype might be cloned 100 times per level, each clone maintaining the base configuration while allowing individual state changes.
•Configuration Management — Environment configurations (dev, staging, production) share most settings but differ in specific values. Cloning a base configuration and modifying only the differences is cleaner than rebuilding each configuration from scratch.
•Document Processing — Templates for invoices, reports, or contracts are prototypes that get cloned and filled with specific data. The template structure (formatting, sections, styles) is expensive to construct but free to clone.
•Caching and Pooling — Object pools maintain pre-initialized prototypes that are cloned when objects are 'borrowed.' This avoids repeated initialization for frequently-requested object types.
•Undo/Redo Systems — Saving object state for undo often involves cloning the object's state at each checkpoint. The pattern enables efficient state preservation without custom serialization logic.
•A/B Testing Frameworks — Experiment configurations are created as variations of baseline prototypes. Cloning the baseline and adjusting specific parameters ensures consistent comparison conditions.

Recognizing the Prototype Pattern Opportunity

Pattern recognition is a critical skill for software design. Here are the key signals that suggest the Prototype Pattern may be appropriate for your situation:

Signs You May Need the Prototype Pattern

•You're writing type-switching code to copy objects — If you find yourself checking instanceof to determine how to copy an object, cloning would eliminate this branching.
•Object initialization is measurably expensive — Profile your application. If object creation shows up in performance traces, especially for repeatedly-created objects, cloning may help.
•Users configure objects interactively — When users spend effort configuring objects (through dialogs, wizards, or direct manipulation), those configurations should be preservable as prototypes.
•You need variations of a base configuration — Creating many objects that differ only slightly from a common template is a classic prototype scenario.
•Factory hierarchies are exploding — If your factory class count mirrors your product class count, prototypes may offer a simpler alternative.
•The system supports plugins or extensions — When third-party code can define new types, prototypes allow creation without the core system knowing the concrete classes.
•You're implementing copy/paste functionality — This is fundamentally object cloning. The Prototype Pattern provides the structured approach.

When NOT to Use Prototype

The Prototype Pattern adds complexity. Don't use it when: (1) Object creation is already fast and simple, (2) Objects have complex circular references that make cloning difficult, (3) Objects hold external resources (file handles, connections) that shouldn't be duplicated, or (4) The 'deep vs shallow copy' question has no clear answer for your domain.

Summary: The Problem Space for Prototypes

We've explored the fundamental problems that motivate the Prototype Pattern—situations where traditional constructor-based object creation falls short:

Key Takeaways

•Expensive initialization becomes cumulative debt — When creating many similar objects, repeated initialization costs compound. Cloning amortizes the setup cost across all copies.
•Type-switching is an antipattern — Checking types to determine how to copy objects violates OOP principles and breaks extensibility. Cloning moves copy logic to where it belongs—in each class.
•Complex configurations deserve preservation — Objects that reach their useful state through elaborate setup become templates worth cloning rather than recreating.
•Factory proliferation has limits — When factory hierarchies parallel product hierarchies, prototype registries offer a flatter alternative.
•Runtime extensibility requires runtime solution — Plugins and dynamic types can't be handled by compile-time factory methods. Prototypes work with types unknown at compile time.

What's next:

Now that we understand the problems that the Prototype Pattern addresses, we'll examine its solution in detail. The next page explores the clone method—the mechanism that enables objects to create copies of themselves. We'll examine interface design, implementation strategies, and the trade-offs between different cloning approaches.

Page Complete

You now understand the problem domain for the Prototype Pattern—when object cloning is preferable to traditional instantiation. Next, we'll explore how to implement the clone method that makes this pattern work.