Memento in Java

## The problem Memento solves Suppose you have an object that changes over time — a text editor's document, a game character, a drawing canvas — and you want an **undo** feature. To undo, you must be able to restore a *previous* state of that object. The naive approach is to let some external 'history manager' reach into the object, read all its fields, stash them, and later write them back. But that **breaks encapsulation**: the history manager now depends on the object's private structure, and the object can't change its internals freely. **Memento** (a behavioral pattern from the Gang of Four catalog) solves this: the object itself produces a snapshot of its own state as a separate object, and can later rebuild itself from such a snapshot — all without exposing its fields to the outside world. ## Definitions of the three roles - **Originator** — the object whose state we want to save and restore. It has two key operations: one that **creates** a memento capturing its current state (often called `save()` or `createMemento()`), and one that **restores** its state from a given memento (`restore(memento)`). Only the Originator knows what is inside a memento and how to interpret it. - **Memento** — the **snapshot object**. It is an immutable (ideally) value holder containing a *copy* of whatever state the Originator needs to reconstruct itself. Critically, the Memento is **opaque to everyone except the Originator**: outsiders may hold a reference to it and pass it around, but they cannot read or change its contents. - **Caretaker** — the code that *manages* mementos: it asks the Originator to produce one, stores it (commonly on a stack so the most recent state is restored first, enabling undo; a second stack gives redo), and later hands one back to the Originator to restore. The Caretaker treats each memento as a **black box** — it never looks inside. ## How encapsulation is preserved in Java The trick is a **narrow vs. wide interface**. The Caretaker sees only a *narrow* interface (often just a marker/empty type), while the Originator sees the *wide* interface (the actual fields). Java idioms to achieve this: 1. **Memento as a `private static` nested class of the Originator.** The Originator can access the nested class's private fields (Java lets an enclosing class see a nested class's privates and vice versa), but outside code only gets a reference typed as a public marker interface, so it can't read anything. 2. **`record` for the Memento.** A Java `record` makes a compact, immutable snapshot with value-based `equals`/`hashCode` — a natural fit for an opaque state holder. ## Two common Java ways to capture state - **Private field snapshot:** the Originator copies its current field values into the Memento. This is fast and explicit but must be kept in sync with the Originator's fields. Watch for **shallow vs deep copy** — if a field is a mutable object (e.g. a `List`), copying only the reference means a later mutation corrupts the saved snapshot, so you must defensively copy mutable state. - **Serialization-based memento:** serialize the whole Originator (e.g. `Serializable` + `ObjectOutputStream`, or a deep clone) into a byte array, and deserialize to restore. This automatically produces a **deep copy** and needs no manual field-by-field code, but it is slower, requires `Serializable`, and stores a lot of bytes. ## Memory cost Every saved state is a full (often deep) copy of the relevant data. An unbounded undo history therefore grows memory linearly with the number of saved states. Mitigations: **cap the history depth**, store **deltas** (only what changed) instead of full snapshots, or snapshot lazily. ## Contrast with related ideas - **Command pattern** also enables undo, but by storing the *operations* (and their inverses) rather than full state snapshots; the two are often combined (Command holds a Memento to undo). - **Prototype/clone** copies an object for general reuse; Memento copies specifically for later **restoration of the same object**, with the encapsulation guarantee. In the JDK itself there is no single canonical Memento class, but the idea shows up wherever state is snapshotted for rollback (e.g. transactional or 'savepoint' style APIs).