Memento
Memento captures an object's internal state in an opaque snapshot so it can be restored later without breaking encapsulation. A caretaker manages the snapshots while only the originator interprets them, enabling undo and rollback.
Memento is a behavioral pattern that lets you save and restore the previous state of an object without exposing the details of its implementation. It solves the tension between needing a snapshot of an object's state and wanting to keep that object's internals private. The snapshot is stored in an opaque object that only the originator can read.
How It Works
Three roles collaborate. The originator is the object whose state must be saved; it creates a memento holding a copy of its state and can later restore itself from one. The memento is a value object that is opaque to everyone except the originator, exposing no setters to outsiders. A caretaker keeps mementos, typically in a history stack, and asks the originator to save or restore, but never inspects or modifies the contents.
This division preserves encapsulation: the caretaker manages when snapshots happen, while only the originator knows what state means. Implementations vary in how strictly they hide the memento's fields, from nested classes to serialized blobs.
When to Use It
Use Memento when you need to produce snapshots of an object's state to support undo or rollback, and when direct access to that state would break encapsulation or be too brittle. It fits editors, form wizards, game save points, transaction rollback, and any feature that must return to an earlier checkpoint.
Trade-offs
Snapshots can be expensive in memory and time if the state is large or saved frequently, so strategies like incremental diffs or limiting history depth are common. Capturing a true copy is subtle when state contains references; a shallow copy may share mutable data and corrupt the snapshot. Languages without strong access control make it hard to keep the memento genuinely opaque. The caretaker must also manage the lifecycle of stored mementos to avoid unbounded growth.
Related Patterns
Command frequently uses Memento to implement reversible operations, the command stores a memento before executing so it can roll back. State represents behavior tied to current state, while Memento preserves past states. Prototype also copies objects, but for cloning rather than restoration. Event Sourcing is the prominent alternative at the architecture scale: instead of storing periodic full snapshots, it records every change as an event and reconstructs state by replaying the log, often combining periodic snapshots with Memento-like checkpoints to speed up replay. Database transaction logs and version-control systems embody the same idea of being able to return to an earlier consistent point.
Example
A drawing app captures the canvas as a memento before each operation. The caretaker pushes mementos onto an undo stack and a redo stack. When the user presses undo, the app pops the latest memento and asks the canvas to restore from it. The canvas internals stay private, and the undo machinery never touches pixel data directly. To keep memory bounded, the app caps the history depth and stores incremental diffs rather than full copies for large documents, restoring by replaying diffs from the nearest full snapshot. The same pattern backs save points in games, transactional rollback in editors and form wizards, and the ability of a long-running calculation to checkpoint its progress so it can resume after an interruption rather than starting over.