Memento Pattern

The core idea of the Memento Pattern is to take a snapshot of the current state before making a change, and to restore the object directly to that snapshot state when an undo is needed.

The Memento Pattern has three classic roles: the Originator, the Memento, and the Caretaker.

An object that owns state should be responsible for snapshotting and restoring itself; the mechanism that manages history does not need to know how the object works internally, only that it can snapshot and restore.

The book "Design Patterns" catalogues 23 classic design patterns, of which the Memento Pattern is one.

The fundamental difference between the Memento Pattern and the Command Pattern is: the Memento stores state, while the Command stores operations.

The Memento is suitable when the cost of copying state is low, there are many different types of mutations, and restoring old state is simpler than reversing each operation; the Command Pattern is often better when snapshots are large, individual changes are small, or the operations themselves are meaningful domain concepts that need to enter an audit log.

Restoring an object's state is not the same as undoing side effects; it is impossible to unsend a sent email, reverse an API call, or refund money to someone else's account — external systems require more complex architectural mechanisms such as transactions and compensating operations.

A snapshot should not automatically serialize every attribute, but should only capture state relevant to the purpose of restoration; runtime information such as last_run_at and execution counts should generally not be rolled back during an undo.

Adding redo functionality only requires maintaining two stacks in History — undo and redo: when performing an undo, push the snapshot onto the redo stack; when performing a redo, push it back onto the undo stack.