The Memento Pattern: Saving State Without Breaking Encapsulation

Summary

The video explains the Memento pattern, a way to save and restore an object’s state without implementing separate reverse logic for every operation. Instead of writing “undo rename,” “undo add step,” and “undo move step,” a program records a snapshot and later restores it.

Example: Workflow editor

The example uses a workflow with a name and a list of steps. A user can rename the workflow or add steps. The presenter shows how to:

• Define a frozen dataclass to represent a workflow snapshot, or memento. It stores the workflow’s name and steps as a tuple, making the snapshot immutable.
• Add a snapshot method to the workflow so it can capture its current state.
• Add a restore method so the workflow can load that state back, converting the steps to a list again if needed.
• Save a snapshot before making changes, then restore it to return to the earlier workflow without writing operation-specific undo code.

The workflow is the originator: it owns the state and knows how to save and restore it. The snapshot is the memento: it holds the saved state. A caretaker manages saved snapshots without needing to understand the workflow’s internals.

A modern Python implementation

Rather than reproducing the classic pattern’s class structure literally, the video uses Python abstractions:

• A generic protocol describes an object that can create and restore snapshots.
• A generic history class stores snapshots and provides an undo operation.
• The history class depends only on the snapshot-and-restore capability, so it can work with different objects that satisfy the protocol.

This illustrates a broader design lesson: adapt classic patterns to the features of the language instead of copying their original diagrams and class hierarchies.

Choosing what to save

A snapshot should contain the state needed for a particular restoration purpose—not necessarily every attribute on the object. For example, restoring an editable workflow configuration may not require restoring execution counts or the last-run time.

Snapshots should also avoid unrelated or difficult-to-copy resources such as database connections, locks, services, caches, and file handles. Making the snapshot’s boundaries explicit helps clarify what restoring it actually means.

Undo, redo, and other uses

Redo can be added by maintaining separate undo and redo stacks. When undoing, the current state is saved to the redo stack; when redoing, the current state is saved to the undo stack. This keeps the two histories synchronized.

Memento can also be useful for checkpoints, drafts, simulations, or restoring local application state after a failed multi-step process. However, restoring an object does not reverse external side effects: it cannot unsend an email, undo an API call, or reverse a payment. Those cases may require transactions, compensating actions, or other architectural mechanisms.

Memento versus Command

• Memento preserves state. It is a good fit when snapshots are inexpensive, there are many kinds of changes, and restoring a prior state is easier than reversing each change.
• Command preserves operations. It can be preferable when snapshots would be large, individual changes are small, or the operations themselves matter—for example, as domain concepts or audit records.
• The patterns can be combined: commands can record operations, while mementos provide periodic checkpoints.

When not to use Memento

Avoid the pattern when a small object can simply be copied or when keeping many large snapshots would cause memory problems. The key design principle is to let the object that owns the state define how that state is captured and restored, while keeping history management separate.

Speakers and sources

• Presenter: ArjanCodes presenter; no other speaker is identified in the subtitles.
• Source referenced: Design Patterns (1994), by the Gang of Four, credited in the video as the source of the Memento pattern.