Prototype

One method does all the work: clone()

The whole pattern is a single method — usually called clone() — that lives on the object and returns a copy of itself. The copy comes back with all the current field values already filled in, so the caller never runs the expensive setup and never has to know the concrete class. You ask the object, 'make me another one like you,' and it does.

class Enemy {
  constructor(
    public type: string,     // "Goblin"
    public color: string,    // "#5cc66f"
    public weapon: string,   // "Sword"
    public hp: number,       // 30
  ) {}

  clone(): Enemy {
    // copy every current field into a brand-new object
    return new Enemy(this.type, this.color, this.weapon, this.hp);
  }
}

const template = new Enemy("Goblin", "#5cc66f", "Sword", 30); // configured once
const a = template.clone();   // identical copy, one step
const b = template.clone();   // another one, instantly
b.hp = 45;                    // tweak just this copy

That's the entire idea. template.clone() reads the template's current values and stamps out a fresh object holding the same ones. You configured the template once; each clone is a one-liner. And because the caller just calls clone(), it doesn't matter whether the object is a Goblin, an Orc, or a Dragon — every one knows how to copy itself.

The one catch: shallow vs deep copy

There's one thing to watch for, and it's the classic Prototype gotcha. When an object holds a nested object inside it — say each enemy has an inventory list of items — a plain copy has a choice to make:

• Shallow copy — copies the top-level fields, but for the nested list it copies only the reference (the pointer), not the list itself. So the clone and the original end up sharing the same inventory. Add an item to the clone's inventory and it appears on the original too — they're the same list. Usually a surprise bug.
• Deep copy — copies the nested objects as well, so the clone gets its own inventory. Now editing the clone's list leaves the original untouched. The copies are truly independent.

Why not just call the constructor?

Sometimes you can — if building an object is cheap and simple, a plain new Enemy(...) is fine and you don't need this pattern. Prototype earns its keep when setup is expensive (loading data, heavy computation), when you need many similar objects, or when the code doing the copying doesn't know the concrete class — it only has some object and needs 'another like it.' In all those cases, clone() is faster and simpler than rebuilding from scratch.

Reach for Prototype when building fresh is wasteful or awkward

Prototype shines whenever copying an existing object is easier, faster, or more flexible than constructing a new one:

• Expensive-to-create objects — if setup means heavy computation, loading from disk, or a database round-trip, do it once and clone the result instead of paying that cost every time.
• Spawning many similar objects — games spawning enemies, a document with hundreds of similar shapes, rows in a spreadsheet. Configure one template, stamp out copies.
• Snapshotting current state — clone an object to freeze how it looks right now (for undo/redo, or a 'save point'), then keep editing the original.
• Avoiding a big parallel factory hierarchy — instead of a matching factory class for every product type, keep a registry of prototype objects and just clone the one you want.
• When the concrete class isn't known — code that only has 'some object' and needs 'another like it' can call clone() without knowing whether it's a Goblin, Orc, or Dragon.