Memento

Real-world analogy

A video game checkpoint or quick-save feature demonstrates the Memento pattern. Before facing a dangerous boss battle, a player presses the quick-save key (F5). The game engine packages your character's current health, ammunition, inventory, and exact coordinates into an opaque save-state file (the memento). The operating system or cloud save manager (the caretaker) stores this file in a folder without knowing how the game engine's internal physics or AI routines work. If your character perishes, you load the checkpoint, and the game engine (the originator) restores you to that exact moment in time.

The problem

You are building a graphics canvas editor. Users can draw shapes, change fill colors, move layers, and resize objects. You need to provide a multi-level Undo and Redo feature.

If you attempt to capture the canvas state externally without the Memento pattern, you face an architectural dilemma:

1. Violating Encapsulation: If you make the canvas's internal private state fields (vertex coordinates, selection caches, dirty layer flags) public so an UndoManager can copy them, you leak internal implementation details and violate encapsulation.
2. Brittle Coupling: If the UndoManager knows the exact fields of Canvas, every change to the internal drawing engine forces a rewrite of the undo system:

1 // Naive implementation: Breaching encapsulation to save state externally
2 class Canvas {
3   // Public exposure of private data structures breaks encapsulation!
4   layers = [];
5   selectedLayerId = null;
6   brushColor = "#000000";
7 }
8 
9 class UndoManager {
10   #history = [];
11 
12   save(canvas) {
13     // Caretaker reaches directly into internal private fields
14     const snapshot = {
15       layers: JSON.parse(JSON.stringify(canvas.layers)),
16       selectedLayerId: canvas.selectedLayerId,
17       brushColor: canvas.brushColor
18     };
19     this.#history.push(snapshot);
20   }
21 
22   restore(canvas) {
23     const last = this.#history.pop();
24     // Directly mutating external canvas fields
25     canvas.layers = last.layers;
26     canvas.selectedLayerId = last.selectedLayerId;
27     canvas.brushColor = last.brushColor;
28   }
29 }

1 public class Example {
2     static class Canvas {
3         public java.util.List<String> layers = new java.util.ArrayList<>();
4         public String brush = "#000000"; // Leaked public fields
5     }
6 
7     static class UndoManager {
8         public void save(Canvas canvas) {

Exposing private fields so an external history manager can serialize them breaks object encapsulation and makes it impossible to change internal representations without rewriting the history manager.

The solution

The Memento pattern allows an object (the Originator) to capture its own internal state into a dedicated snapshot object (the Memento). The snapshot is handed to an external Caretaker (such as an undo manager), which stores it safely without inspecting or modifying its contents. Later, the caretaker passes the memento back to the originator to restore its state.

• Originator (TextEditor): The object whose state needs to be saved and restored. Creates mementos and uses them to revert state.
• Memento (EditorSnapshot): An opaque value object storing the originator's state. Provides a narrow interface to the caretaker and a wide interface to the originator.
• Caretaker (HistoryManager): Stores and manages a history of mementos (undo/redo stacks), but never accesses or mutates the memento's payload.

Step-by-step implementation

Step 1: Define the opaque memento

The memento encapsulates the state snapshot. In languages with package-private access (like Java), internal getters are hidden from the caretaker.

Step 2: Implement the originator with save and restore

The originator creates mementos holding its private state and consumes them to restore itself.

Step 3: Implement the caretaker history manager

The caretaker stores mementos in an undo stack without reading their internal properties.

1 class HistoryManager {
2   #history = [];
3 
4   push(memento) {
5     this.#history.push(memento);
6   }
7 
8   pop() {
9     return this.#history.pop() ?? null;
10   }
11 }

The complete example

Here is the complete, runnable implementation demonstrating a stateful editor with multi-level undo snapshots.

1 --- Step 1: Initial Draft ---
2 Current Text: "Design patterns provide reusable solutions."
3 
4 --- Step 2: Second Sentence ---
5 Current Text: "Design patterns provide reusable solutions. The Memento pattern captures internal state."
6 
7 --- Step 3: Accidental Deletion ---
8 Current Text (after accident): ""
9 
10 --- Step 4: Reverting State via Memento ---
11 [History] Reverted to snapshot from 2026-10-19T12:00:00.000Z
12 Current Text: "Design patterns provide reusable solutions. The Memento pattern captures internal state."
13 
14 --- Step 5: Second Revert ---

Variations

Wide vs narrow interfaces

To maintain encapsulation, GoF specifies two interface views for a Memento:

1. Narrow Interface (Caretaker View): Exposes only metadata (e.g. getTimestamp(), getName()). The caretaker cannot inspect or modify the underlying state payload.
2. Wide Interface (Originator View): Exposes all internal fields. In Java, this is achieved by making the memento class or constructor package-private to the originator, or by nesting the memento as a private inner class inside the originator.

Memory limits and copy-on-write deltas

Storing complete deep snapshots on every modification exhausts memory rapidly:

• Bounded Ring Buffers: Caretakers should enforce a fixed capacity (e.g. max 50 snapshots), evicting the oldest snapshot when capacity is reached.
• Delta Compression: Instead of saving the full object graph, the memento records only the diff/delta of what changed since the previous snapshot (similar to Git commit trees).

Where you've already used it

• HTML5 History API: window.history.pushState(state, title, url) and window.onpopstate save and restore serializable page state objects.
• Database Savepoints: SAVEPOINT sp1 creates a transaction memento, and ROLLBACK TO SAVEPOINT sp1 reverts uncommitted queries back to that checkpoint.
• Redux DevTools Time Travel: Redux logs every state tree snapshot to an array, allowing developers to slide backward and replay actions interactively.
• Git Commit Trees: Each Git commit object acts as an immutable tree memento referencing blob hashes.

Pros and cons

When not to use it

Do not use Memento if the cost of cloning or capturing the object's state in memory exceeds your system's RAM budget. If memory is tight, prefer Command with inverse operations (cmd.undo()), which recalculates state dynamically rather than storing full memory snapshots.

Related patterns

Interview questions

How does Memento preserve encapsulation compared to saving state via getters and setters? Instead of forcing the Originator to expose private fields via public getters and setters (which leaks internals to the entire codebase), only the Memento holds the data, and only the Originator that produced the memento can read its contents.

How does Memento differ from Command in implementing Undo? Command achieves undo computationally by executing the inverse operation (e.g., executing delete to reverse an insert). Memento achieves undo by state restoration, replacing the entire current state with a saved snapshot.

How do you prevent Memento from consuming excessive RAM in production applications? Use a bounded ring buffer to cap history length (e.g. keeping only the last 30 snapshots), serialize inactive snapshots to disk, or record copy-on-write delta differences instead of full object graph clones.

Can a Memento be serialized and sent over a network? Yes. In distributed systems or long-running workflows, mementos are frequently serialized to JSON or Protobuf and stored in Redis or database tables to support resilient process recovery after service restarts.