The Memento pattern claims to save an object's state 'without violating encapsulation'. Concretely, how is a memento kept opaque to the caretaker while still being fully readable by the originator?

## Encapsulation, briefly Encapsulation means an object keeps its internal representation private and exposes only operations that preserve its invariants (rules that must always hold — e.g. `selectionStart <= selectionEnd`). If external code can read and write the fields directly, the object can no longer guarantee those rules, and you can never change the representation without breaking callers. Memento's whole selling point is doing snapshot/restore *without* giving that up. The technique is **two interfaces to the same object**. ## Narrow vs wide interface - **Narrow interface** — what the caretaker sees. Ideally nothing at all: an empty marker type, or at most non-sensitive metadata such as a creation timestamp, a human-readable label ("before paste"), or an identifier used for a redo list. The caretaker can store, order, count, and evict mementos, and hand one back — nothing else. - **Wide interface** — what the originator sees: the actual captured fields. The caretaker is compiled against the narrow view, so it cannot become coupled to the originator's internals even by accident. ## How languages enforce it | Mechanism | How it works | Notes | |---|---|---| | Private/protected **nested class** | `Editor.Memento` is declared inside `Editor`; the outer class may read its private fields, outsiders only see a public marker interface it implements | Classic Java/C# formulation | | **Package-private / `internal`** visibility | Fields or accessors are visible only within the originator's package or module | Simple; leaks to anything else in the same package/module | | **`friend`** declarations | The originator is declared a friend of the memento class | C++ | | **Closure capture** | `save()` returns a closure/thunk that, when invoked by the originator, replays state | Works in dynamic and functional languages; state is unreachable except through the closure | | **Opaque handle / token** | Memento is stored in a private table inside the originator; the caretaker receives only an id | Adds lifetime management (you must evict entries) | | **Sealed/opaque type + module boundary** | Only the declaring module can construct or destructure it | Kotlin `internal`, Rust module privacy, TypeScript branded types (compile-time only) | ## Two rules people forget **Immutability.** If the memento holds mutable references to the same objects the originator still mutates, the "snapshot" changes underneath you and undo restores the *current* state. Copy defensively (deep enough for the mutable parts), or capture persistent/immutable data structures. Immutability also makes the memento safe to share across threads and safe to keep in a redo stack. **Provenance checking.** `restore(m)` receives a memento from the outside. If a caretaker hands back a memento from a *different* originator, or a hand-crafted one, restoring it could install a state that violates invariants. Defensive originators check the runtime type and, where relevant, an owner identity or version stamp, and reject mismatches. A version/schema stamp also matters if mementos are persisted across releases: old snapshots may no longer describe the current state shape. ## Where it is only a contract, not a wall Reflection, serialization frameworks, debuggers, and memory inspection can all read a memento's private fields. So can anything in the same package when you rely on package-private visibility. Treat opacity as a *design contract* enforced as strongly as the language cheaply allows — the value is that no ordinary code path can couple to the internals, and reviewers can spot violations. If a memento holds secrets (credentials, personal data), opacity is not a security control: you still need the usual protections (avoid logging, zero/clear buffers, encrypt if persisted, bound retention). ## Trade-off worth naming The stricter the enforcement, the more awkward the code (nested classes, extra interfaces, generics that thread the memento type through the caretaker). Some teams deliberately settle for an immutable data class in the same module plus a review rule. That is a legitimate engineering choice — say so explicitly in an interview rather than pretending the pattern demands maximal ceremony.