Memento

The three participants

The pattern splits the undo problem across three roles, and the split is the pattern — each role knows exactly as much as it needs and no more:

• Originator — the object with the precious private state (the game). It has two extra methods: save() packs its current state into a memento, and restore(m) unpacks a memento back into itself. It is the only thing that ever reads a memento's contents.
• Memento — the sealed snapshot (the save file). It's a dumb, opaque box: ideally immutable (built once in save(), never changed — see [[immutability-and-value-objects]]) and unreadable from outside. It exposes nothing useful to anyone but its originator.
• Caretaker — the history keeper (the save-slot menu). It asks the originator to save(), stores the mementos in slots or a stack, and later hands one back for restore(m). It stores and organises — it never looks inside.

Why not just copy the fields from outside?

Imagine the save menu doing the job itself: snapshot = { level: game.getLevel(), hp: game.getHp(), x: game.getX(), ... } and later game.setLevel(...), game.setHp(...). To pull that off, the game must grow a public getter and setter for every single field — its internals become everyone's business, any code can now half-restore it or set nonsense values, and each time the game adds a field, every snapshot site silently goes stale. That's [[encapsulation]] destroyed for the sake of undo. Memento flips the responsibility: the object snapshots itself, so its fields can stay private and the snapshot format is its own internal secret.

class Game {
  private level = 1;            // 🔒 all private — no getters/setters needed
  private hp = 100;
  private pos = 0;

  save(): SaveFile {            // originator packs its OWN state
    return new SaveFile(this.level, this.hp, this.pos);
  }
  restore(s: SaveFile): void {  // and is the ONLY reader of a save
    this.level = s["level"]; this.hp = s["hp"]; this.pos = s["pos"];
  }
}

class SaveFile {                // memento: built once, then sealed
  constructor(
    private readonly level: number,
    private readonly hp: number,
    private readonly pos: number,
  ) {}
}

class SaveSlots {               // caretaker: stores boxes, never opens them
  private slots: SaveFile[] = [];
  store(s: SaveFile) { this.slots.push(s); }
  pick(i: number): SaveFile { return this.slots[i]; }
}

Memento + Command: the classic undo duo

Memento pairs beautifully with [[command]]. A command object, right before it executes, asks the originator for a memento and tucks it away; undo() is then just originator.restore(saved). The command doesn't need to know how to reverse the operation — it just rewinds to the checkpoint. This is how many real editors implement undo stacks.

The cost: snapshots aren't free

Every save copies state. If the state is large (a big document) or you snapshot on every keystroke, memory climbs fast — the prototype's three fixed slots that recycle the oldest is a miniature of the real answer: cap the history. Other real-world tactics: snapshot only every N operations, store diffs (deltas) between snapshots instead of full copies, or share unchanged parts between snapshots (persistent data structures). You'll meet the same idea in the wild as editor undo history limits, database savepoints inside transactions, and games keeping only your last few autosaves.

• Editor undo — each undo step is (conceptually) a memento of document state; real editors mix in diffs to keep memory sane.
• Database transactions & savepoints — SAVEPOINT marks a sealed checkpoint you can ROLLBACK TO without the client ever seeing internal page state.
• Game saves — the pattern's poster child: sealed files the menu lists but only the engine can interpret.
• Form draft restore — snapshot the form state before a risky action (navigation, autofill) and offer 'restore draft'.

Reach for Memento when rollback matters and privacy matters

The pattern earns its keep when both halves of its promise are needed — you want to rewind, and you don't want to expose internals to do it:

• Undo / rollback of rich private state — editors, drawing apps, game state, wizards with multi-step forms: anything where 'take me back to how it was' must be exact and the state isn't public.
• Checkpoints before risky operations — snapshot before applying a migration, running an irreversible command, or letting the user try a destructive action; restore if it goes wrong (the database SAVEPOINT idea).
• Pairing with [[command]] — each command stores a memento before executing, making undo trivial and uniform across wildly different operations.

When NOT to use it

• The state is tiny or already public — a single number, a plain settings struct: just copy the value. Wrapping int score in an originator/memento/caretaker trio is ceremony, not design.
• History would blow memory — thousands of snapshots of a large object is a leak with a design pattern's name on it. If you can't cap, diff, or share structure between snapshots, reconsider (event sourcing or reversible operations may fit better).
• *You need to inspect history, not just restore it* — a memento is deliberately opaque. If the UI must show 'what changed', you want an explicit change log, not sealed boxes.