Memento Pattern

Overview

Every non-trivial editing tool needs an undo button. Every wizard-style form needs a "go back" option. Every game needs a save-and-load mechanism. All of these share a common need: preserve a snapshot of some object's state at a point in time, and restore it later.

The Memento pattern is a behavioral design pattern that addresses this need. It lets you capture an object's full internal state into a separate "memento" object, store that memento outside the originating object, and later feed it back to restore the original state — all without exposing the object's private fields to the outside world.

The central insight is that only the originating object should know how to pack and unpack its own state. Mementos are opaque to everyone else — they carry data but expose no structure.

Problem & Motivation

Imagine building a text editor. The editor holds a document object that tracks the current text content, cursor position, and selected range. You want to support unlimited undo.

The naive approach is to save a copy of the entire document state into a list on every keystroke. That works, but it means the undo manager must know the internal layout of document — what fields exist, which are serializable, which can be safely deep-copied. Now the undo manager is tightly coupled to the document's internals. When you add a new field to document, you must also update the undo manager.

Alternatively, you could expose all fields via getters so the undo manager can read and replay them. But now every internal detail is part of the public API, making future refactors painful.

The Memento pattern resolves this by giving the document the responsibility to create and consume its own snapshots. The undo manager holds a stack of opaque memento objects — it cannot read them, it can only pass them back to the document on request.

Class Diagram

The three roles are:

• Originator — the object whose state needs to be saved. It creates mementos and restores its state from them.
• Memento — the snapshot. It stores a copy of the originator's internal state. It is opaque to everyone except the originator.
• Caretaker — manages the memento stack (the undo history). It knows when to save and when to restore, but never inspects the contents of a memento.

Implementation

The implementations below model a TextEditor that supports save-and-undo of its content and cursor position. All four versions produce the same behavior: typing, saving checkpoints, and restoring a previous state.

// Memento — opaque to the Caretaker
class EditorMemento {
  private readonly content: string;
  private readonly cursor: number;

  constructor(content: string, cursor: number) {
    this.content = content;
    this.cursor = cursor;
  }

  // Only the Originator should call these
  getContent(): string { return this.content; }
  getCursor(): number { return this.cursor; }
}

// Originator
class TextEditor {
  private content: string = "";
  private cursor: number = 0;

  type(text: string): void {
    this.content += text;
    this.cursor = this.content.length;
  }

  save(): EditorMemento {
    return new EditorMemento(this.content, this.cursor);
  }

  restore(memento: EditorMemento): void {
    this.content = memento.getContent();
    this.cursor = memento.getCursor();
  }

  toString(): string {
    return `"${this.content}" (cursor: ${this.cursor})`;
  }
}

// Caretaker
class History {
  private stack: EditorMemento[] = [];
  private editor: TextEditor;

  constructor(editor: TextEditor) {
    this.editor = editor;
  }

  backup(): void {
    this.stack.push(this.editor.save());
  }

  undo(): void {
    const memento = this.stack.pop();
    if (memento) {
      this.editor.restore(memento);
    }
  }
}

// Usage
const editor = new TextEditor();
const history = new History(editor);

history.backup();
editor.type("Hello");
history.backup();
editor.type(", World");

console.log(editor.toString()); // "Hello, World" (cursor: 13)

history.undo();
console.log(editor.toString()); // "Hello" (cursor: 5)

history.undo();
console.log(editor.toString()); // "" (cursor: 0)

Real-World Examples

Text editors and IDEs — Every editor from VS Code to Vim implements undo/redo on top of a state-snapshot mechanism. The editor buffer is the originator, each keystroke checkpoints a memento, and the undo stack is the caretaker. Some editors use a richer variant (operation-based undo / CRDT), but the conceptual role of Memento is identical.

Game save systems — A role-playing game saves the player's position, inventory, health, and quest flags as a serialized snapshot. The save-file manager holds a list of save slots (caretakers) without parsing what is inside them. Loading a slot feeds the snapshot back to the game engine (the originator), which unpacks it.

Form wizards and multi-step UIs — Web wizards that let users navigate back and forth between steps often snapshot the form state at each step boundary. Each step's data is stored in a memento so navigating backward restores the exact values the user entered, rather than forcing them to re-enter data.

Database transaction rollback — Relational databases use a write-ahead log (WAL) that captures the before-image of each changed row before a transaction modifies it. If the transaction is rolled back, the engine replays the before-images — essentially restoring from mementos. This is Memento applied at infrastructure scale.

Pros and Cons

When to Use / When to Avoid

Use Memento when:

• You need undo/redo and want to keep the originator's internals private.
• State snapshots are reasonably small or checkpoints are infrequent (on explicit user actions rather than every change).
• The originator's state can be fully represented as a plain value (no open handles, no live network connections).
• You want a clean separation: the originator owns serialization logic, the caretaker owns history management.

Avoid Memento when:

• The originator's state is very large and changes frequently — consider command-based undo (storing inverse operations) instead.
• The state graph contains circular references or live resources that cannot be deep-copied.
• You only need undo for a subset of fields — expose only those fields via a dedicated snapshot type rather than capturing everything.
• The language or framework already provides change-tracking (e.g., database ORM dirty-tracking, reactive state frameworks with built-in time travel) — don't re-implement what the platform gives you.

Related Patterns

Command — the most common alternative for undo/redo. Instead of saving the full state before each change, Command records the operation and its inverse. Command is more memory-efficient when changes are incremental; Memento is simpler when the full state is small. Many systems combine both: commands for fine-grained changes, periodic Memento checkpoints as recovery points.

Prototype — cloning an object is the simplest way to create a memento. If your originator implements clone() / copy(), you can use that as the save() mechanism directly. The distinction is intent: Prototype is about object creation, Memento is about state history.

Iterator — when you want to replay a sequence of past states rather than just restore the most recent one, you can wrap the memento stack in an iterator. Stepping forward and backward through history is exactly what an iterator provides.

Serializer / Snapshot — in distributed systems, the Memento concept maps to event sourcing and CQRS snapshots. An aggregate's state is periodically snapshotted (a Memento) and the event log is truncated. The aggregate (originator) owns how to produce and consume the snapshot; the event store (caretaker) owns where it lives.