Prototype

Prototype creates a new object by copying an existing one rather than constructing it from parameters. It is the least fashionable creational pattern and the one whose failure mode does the most damage, because a bad copy produces an object that looks correct and shares state with its original.

The pattern applies when an object is expensive to build, or when the configuration you want already exists as a live object rather than as a set of parameters.

The problem it addresses

A report template is assembled from a database read, a permissions check and a schema fetch — 200 ms of work. Every user who runs the report needs their own copy to modify.

// Rebuilds everything, per user, per run
const report = await buildReportTemplate(templateId);
report.filters.push({ field: 'region', value: user.region });

Constructing from parameters is not available: the parameters are no longer around, and reproducing them would mean re-reading the same three sources. What you have is a finished object that is nearly right.

const template = await buildReportTemplate(templateId);   // once, cached

// Per user
const report = template.clone();
report.filters.push({ field: 'region', value: user.region });

Shallow versus deep, and why it matters here more than anywhere

A shallow copy duplicates the object's own fields. Where a field is a reference, both objects now point at the same thing. Mutating the copy's filter list mutates the template's, and because the template is cached, every subsequent user inherits the previous user's filters.

This is a data-leak bug in the exact shape auditors care about: user A's region filter silently applied to user B's report. It passes every unit test that clones once.

Deep copying fixes it and brings its own problems:

• Cost. Copying a large graph per request may be slower than rebuilding the parts you actually need.
• Cycles. A naive recursive copy of a graph containing a back-reference never terminates.
• Things that must not be copied. A database connection, an open file, a mutex, a logger. Copying a connection handle gives you two objects that think they own one resource.

Making the decision explicit

The honest implementation states its policy for each field:

class ReportTemplate {
  constructor(title, filters, schema, connection) {
    this.title = title;            // immutable string — share
    this.filters = filters;        // mutable array — must copy
    this.schema = schema;          // frozen object — share
    this.connection = connection;  // resource — share deliberately, never copy
  }

  clone() {
    return new ReportTemplate(
      this.title,
      this.filters.map((f) => ({ ...f })),   // copy the array AND its elements
      this.schema,
      this.connection,
    );
  }
}

Note filters.map(f => ({...f})) rather than [...this.filters]. Copying the array alone still shares every filter object inside it — the one-level-too-shallow bug, and the most common way this goes wrong after someone has already been told to copy the array.

Where the pattern actually shows up

Cached templates and configurations — as above: an expensive-to-assemble object that many callers need a private variant of.

Prototype registries — a map from a name to a fully configured exemplar, cloned on request. This is a factory whose products are objects rather than classes, and it is how plug-in systems let third parties register new types without touching your switch statement.

Undo and snapshots — copying an object to keep its previous value. This is close enough to Memento to be worth naming; the difference is that Memento deliberately hides the copy's internals from everyone but the original.

Test fixtures — clone a valid baseline object and mutate one field, rather than rebuilding a valid object per test. A test data builder usually does this better, because it makes the mutation explicit.

When not to use it

When construction is cheap. Calling the constructor is clearer than copying, and it cannot share state by accident.

When the object owns resources. Anything holding a connection, a file handle, a lock or a thread should not be cloneable, and the clone method should not exist rather than silently do the wrong thing.

When the graph is deep and mutable. The copy is expensive, the cycle handling is fiddly, and every new field is a chance to forget a case. Prefer making the graph immutable, or rebuilding.

Check your understanding

Common mistakes

Relying on the language's default copy. It is shallow, and the "deep" alternative usually means serialising, which drops unserialisable fields silently.

Copying the container but not its elements. [...list] is one level. The objects inside are still shared.

Cloning objects that own resources. Two owners of one connection, file or lock is an ambiguity with no good resolution.

Deep-copying a graph with cycles naively. Recursion without a visited set does not terminate.

Using Prototype where a constructor would do. If the parameters are available, construct. Copying can share state; construction cannot.

Forgetting a new field in clone(). Every field added later is a chance for the copy to silently diverge. Keep the copy next to the constructor so they are read together.

Practice

Key takeaways

• Prototype creates by copying an existing object, for cases where construction is expensive or the parameters no longer exist.
• Shallow copies share references, and when the original is cached that turns into cross-request data leakage — the pattern's signature failure.
• Copying a container is not copying its contents. [...list] leaves every element shared.
• Write clone() by hand, field by field, so each field is a decision. Language defaults are shallow and serialisation-based deep copies drop things silently.
• Objects owning connections, files or locks should not be cloneable — two owners of one resource has no correct lifecycle.
• Immutability dissolves the problem: if the parts cannot change, sharing them is safe.
• Test with identity assertions, and always assert the original is unchanged.

Further reading

• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).
• Joshua Bloch, Effective Java, third edition (Addison-Wesley, 2018) — on the difficulties of clone and on defensive copying.
• Brian Goetz and others, Java Concurrency in Practice (Addison-Wesley, 2006) — safe publication and immutability.
• Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002).
• Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004).