Skip to content
LLD Learn/Creational Patterns
Browsing as a guest. Sign in to save your progress and earn XP as you complete chapters.

Prototype

5 min read

You'll learn to

  • -Clone existing objects instead of rebuilding them from scratch, and implement deep vs. shallow copy correctly
  • -Identify the narrow set of interview problems where Prototype is actually the right call

Prototype creates new objects by copying an existing instance (the "prototype") rather than constructing one from scratch. It is the least frequently needed of the creational patterns in interviews, but it comes up cleanly whenever an object is expensive to construct and a similar, pre-configured instance already exists to clone from.

Shallow vs. Deep Copy - the Part That Actually Trips People Up

A shallow copy duplicates an object's top-level fields, but if any of those fields are themselves references to mutable objects (a list, another object), both the original and the copy end up pointing at the same nested object - mutating it through the copy silently mutates the original too. A deep copy recursively clones every referenced object, so the copy is fully independent.

Shallow copy shares nested mutable state; deep copy does not
import copy

class GameCharacter:
    def __init__(self, name: str, inventory: list[str]):
        self.name = name
        self.inventory = inventory   # a mutable list

original = GameCharacter("Knight", ["sword", "shield"])

shallow = copy.copy(original)
shallow.inventory.append("potion")
print(original.inventory)  # ['sword', 'shield', 'potion'] - the original changed too!

deep = copy.deepcopy(original)
deep.inventory.append("scroll")
print(original.inventory)  # unaffected - deep copy owns its own independent list

When Prototype Actually Earns Its Place

The pattern earns its place when object construction is genuinely expensive (a heavy computation, a database round-trip, an external API call to fully populate the object) and you have a pre-built instance close to what you need. Spawning 500 similar enemies in a game engine from one fully-configured prototype, or duplicating a complex, deeply-nested configuration object with one field tweaked, are the realistic interview-relevant use cases - most everyday object creation should just use a constructor or Builder instead.

If you reach for Prototype in an interview for a cheap-to-construct object, that is usually a sign you are pattern-matching rather than solving the actual problem - name the expense (construction cost, external calls) that justifies cloning over constructing.

Interview Signal is part of Pro

See a real weak answer next to a real strong one for this exact topic.

Quiz is part of Pro

Test what you just read with a short quiz, and bank the XP.

ScaleDojo Logo
Initializing ScaleDojo