100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Software Design

Prototype Pattern

Creates new objects by cloning an existing, pre-configured instance instead of constructing from scratch.

Creational PatternsIntermediate8 min readJul 10, 2026
Analogies

What Is the Prototype Pattern?

Prototype is a creational pattern where new objects are produced by copying an existing instance, called the prototype, rather than instantiating a class from scratch. Each prototype implements a clone() method (often via a Prototype or Cloneable interface) that returns a new object with the same state as the original. This is especially valuable when object initialization is expensive — involving complex computation, a database read, or a network round-trip — because cloning an already-initialized object skips repeating that expensive work for every new instance.

🏏

Cricket analogy: Instead of a groundskeeper re-marking an entire cricket pitch from a blank field every match, they keep a template pitch layout and stamp a copy of its markings onto each new ground — cloning the prototype is far faster than remeasuring creases from scratch every time.

Cloning: Shallow vs Deep Copy

A shallow copy duplicates an object's top-level fields but, for any field that is a reference to a mutable object (like an array or nested object), the clone and the original end up pointing at the same underlying data. Mutating that shared nested object through the clone silently affects the original too. A deep copy avoids this by recursively cloning nested objects as well, so the clone is fully independent of the original — at the cost of more copying work and needing to handle cycles or shared references deliberately.

🏏

Cricket analogy: A shallow copy of a Squad object duplicates the squad's own fields like name and season, but if 'players' is a shared array reference, editing one cloned squad's batting order silently changes the original squad's order too — a deep copy would clone the players array itself so each squad's lineup is independent.

typescript
interface Prototype {
  clone(): Prototype;
}

class EnemyTemplate implements Prototype {
  constructor(public type: string, public stats: Stats) {}

  clone(): EnemyTemplate {
    return new EnemyTemplate(this.type, { ...this.stats });
  }
}

class PrototypeRegistry {
  private prototypes = new Map<string, Prototype>();

  register(key: string, proto: Prototype) {
    this.prototypes.set(key, proto);
  }

  create(key: string): Prototype {
    const proto = this.prototypes.get(key);
    if (!proto) throw new Error(`No prototype for ${key}`);
    return proto.clone();
  }
}

Prototype Registry

A prototype registry (sometimes called a prototype manager) maintains a cache of ready-to-clone template instances keyed by type. Instead of client code constructing a fresh instance from scratch every time, it looks up the appropriate prototype in the registry and calls clone() on it. This is especially common in game engines and other systems that need to spawn many similar objects quickly, turning what could be an expensive initialization routine into a cheap copy operation performed on demand.

🏏

Cricket analogy: A national academy keeps a registry of pre-configured 'ideal squad' prototypes keyed by format — one for Test, one for T20 — so a new tour's selectors clone the T20 prototype directly instead of re-deriving an entire squad profile's strengths and roles from scratch every series.

A prototype registry (sometimes called a prototype manager) stores a set of ready-to-clone template instances keyed by type, turning expensive from-scratch initialization into a cheap clone() call — commonly used in game engines for spawning many similar entities.

When to Use / Trade-offs

Prototype is a strong fit whenever constructing an object from scratch is expensive relative to copying it, or when you need many objects that are similar but slightly different (spawned entities, document templates, pre-configured pipelines). The main trade-off is that cloning needs careful handling: objects with circular references need cycle-aware copy logic, and objects holding live external resources — an open database connection, file handle, or network socket — should not be blindly deep-copied, since duplicating a live handle leaves two objects contending over one physical resource.

🏏

Cricket analogy: Cloning is a big win when re-deriving a squad's full statistical profile from years of match data is expensive, but cloning a MatchOfficial object that holds an open live radio-link connection to the stadium is dangerous — you'd end up with two officials sharing one live broadcast channel.

Never blindly deep-copy an object that holds a live external resource — an open database connection, file handle, or network socket. Cloning should typically null out or re-establish such resources rather than duplicating the live handle, or you'll get two objects contending for one connection.

  • Prototype creates new objects by cloning an existing pre-configured instance rather than constructing from scratch.
  • It's especially useful when object creation is computationally or resource expensive.
  • Shallow copy duplicates top-level fields but shares references to nested mutable objects.
  • Deep copy recursively duplicates nested objects too, avoiding accidental shared mutable state.
  • A prototype registry stores ready-to-clone template instances keyed by type for fast reuse.
  • Cloning objects holding live external resources (sockets, file handles, DB connections) requires special care.
  • Prototype pairs well with Abstract Factory or Builder when families of pre-configured templates are needed.

Practice what you learned

Was this page helpful?

Topics covered

#SoftwareDesign#DesignPatternsStudyNotes#SoftwareEngineering#PrototypePattern#Prototype#Pattern#Cloning#Shallow#StudyNotes#SkillVeris