Memento Pattern
Memento: start from the problem
See the responsibilities
An editor needs to return to an earlier local document state without exposing its internal representation to the history manager. Saving references to the current object does not preserve the old state.
This is a behavioral pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Memento addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Memento lets an originator produce and restore a state snapshot while a caretaker manages those snapshots. Encapsulation determines what the caretaker may inspect or alter. The snapshot must actually preserve the intended earlier values.
Our editor returns a cloned plain-data snapshot and clones again on restore. The history holder need not know the editor’s fields. This simple local version does not provide cross-user conflict resolution or a durable backup.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const editor = {
state: {text: 'first'},
save() { return structuredClone(this.state); },
restore(snapshot) { this.state = structuredClone(snapshot); }
};
const snapshot = editor.save();
editor.state.text = 'second';
editor.restore(snapshot);
console.log(editor.state.text);Expected output
firstChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it for bounded undo history or checkpoints of a locally owned object when snapshot restoration has a meaningful contract.
Snapshots consume memory and can include sensitive data. Deep cloning is not appropriate for every value. Restoring an old state can erase intervening changes; concurrent editing needs another coordination policy.
Distinguish the neighbouring patterns
Command records an action and may supply an inverse. Memento records state. Event Sourcing records authoritative events and rebuilds state under durable history rules.
Follow actions and inverse operations, authoritative event history, independent durable backups to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Memento, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside independent durable backups.
Reaching the recap and completing the quizzes are separate milestones.