Memento Pattern

At its core, the Memento Pattern is a behavioral design strategy designed to solve a common software engineering challen

At its core, the Memento Pattern is a behavioral design strategy designed to solve a common software engineering challenge: how to capture and restore an object's internal state without exposing its private data to the rest of the system. In simpler terms, it allows an application to "take a snapshot" of an object's current condition and revert to that exact state later, effectively providing an "Undo" mechanism while strictly adhering to the principle of encapsulation.

In many systems, implementing an undo feature naively would require the managing class to access the private fields of the target object. This violates the core tenets of Object-Oriented Programming (OOP) by leaking internal implementation details. The Memento pattern solves this by introducing a dedicated object to hold the state, ensuring that only the object that created the state can read or modify it.

Key Participants

The Memento pattern distributes responsibilities across four primary roles to maintain a clean separation of concerns:

  • The Originator: This is the object whose state we want to track. The Originator is responsible for creating a memento containing a snapshot of its current internal state and using that memento to restore itself to a previous state.
  • The Memento: A value object that acts as a storage container for the Originator's state. To maintain security, the Memento typically employs two interfaces:
    • Narrow Interface: Visible to the Caretaker; it provides no access to the state, treating the memento as an opaque object.
    • Wide Interface: Visible only to the Originator; it allows the Originator to extract the state for restoration.
  • The Caretaker: The custodian of the mementos. The Caretaker decides when a snapshot should be taken and when it should be restored. Crucially, the Caretaker never operates on or examines the contents of the memento.
  • The Client: The high-level component that triggers the interaction between the Originator and the Caretaker.

Implementation Workflow

Implementing the Memento pattern generally follows these architectural steps:

  1. Define the Memento: Create a class (often as a private inner class of the Originator) to hold the state. Ensure the state fields are immutable to prevent accidental modification.
  2. Equip the Originator: Add two key methods to the Originator: one to produce a new Memento instance and another to accept a Memento instance and overwrite its current state with the saved data.
  3. Establish the Caretaker: Implement a management system—typically using a Stack or Deque—to store the history of mementos. This enables the "Undo" (pop from stack) and "Redo" (push to a separate redo stack) functionality.
  4. Orchestrate via the Client: The client calls the Caretaker to save the state before a critical operation and requests a restoration when a rollback is needed.

Practical Example: Text Editor Undo/Redo

To illustrate this pattern, consider a simple text editor where a user can append text and undo their changes.

import java.util.*;

// 1. Originator: The TextEditor holds the actual state
public class TextEditor {
    private StringBuilder text = new StringBuilder();

    public void append(String str) {
        text.append(str);
    }

    public void deleteLast(int n) {
        int len = text.length();
        if (n > len) n = len;
        text.delete(len - n, len);
    }

    public String getText() {
        return text.toString();
    }

    // Creates a snapshot of the current state
    public Memento createMemento() {
        return new Memento(text.toString());
    }

    // Restores state from a snapshot
    public void restoreMemento(Memento m) {
        this.text = new StringBuilder(m.getState());
    }

    // 2. Memento: Static inner class to ensure encapsulation
    public static class Memento {
        private final String state;

        private Memento(String state) {
            this.state = state;
        }

        // Only accessible to the Originator (TextEditor)
        private String getState() {
            return state;
        }
    }
}

// 3. Caretaker: Manages the history of snapshots
class History {
    private final Deque<TextEditor.Memento> undoStack = new ArrayDeque<>();
    private final Deque<TextEditor.Memento> redoStack = new ArrayDeque<>();

    public void save(TextEditor editor) {
        undoStack.push(editor.createMemento());
        redoStack.clear(); // New action invalidates the redo history
    }

    public void undo(TextEditor editor) {
        if (!undoStack.isEmpty()) {
            redoStack.push(editor.createMemento()); 
            editor.restoreMemento(undoStack.pop());
        }
    }

    public void redo(TextEditor editor) {
        if (!redoStack.isEmpty()) {
            undoStack.push(editor.createMemento());
            editor.restoreMemento(redoStack.pop());
        }
    }
}

// 4. Client: Orchestrates the process
public class MementoDemo {
    public static void main(String[] args) {
        TextEditor editor = new TextEditor();
        History history = new History();

        editor.append("Hello ");
        history.save(editor);

        editor.append("World!");
        history.save(editor);

        System.out.println("Current: " + editor.getText()); // Hello World!

        history.undo(editor);
        System.out.println("After Undo: " + editor.getText()); // Hello 

        history.redo(editor);
        System.out.println("After Redo: " + editor.getText()); // Hello World!
    }
}

When to Use the Memento Pattern

The Memento pattern is particularly effective in the following scenarios:

  • Undo/Redo Functionality: Essential for productivity software like IDEs, graphic design tools (Photoshop), or document editors.
  • Game Save Systems: Capturing the entire state of a game world (player position, inventory, quest progress) to allow players to reload from a checkpoint.
  • Transaction Rollbacks: In complex business logic, saving a "known good" state before attempting a series of risky operations, allowing the system to revert if an error occurs.
  • Version Control: Maintaining a history of object states for auditing or comparison purposes.

Critical Considerations and Trade-offs

While powerful, the Memento pattern is not without its drawbacks. Developers should keep the following in mind:

1. Memory Overhead
Since each memento captures the full state of the object, storing a long history of snapshots can consume significant RAM. If the object is large, consider using incremental mementos (saving only the changes/deltas) or implementing a limit on the history stack size.

2. Immutability
Mementos must be immutable. If a Caretaker or another external class could modify the state inside a memento, the integrity of the restoration process would be compromised.

3. Thread Safety
In multi-threaded environments, the process of capturing and restoring state must be synchronized. If the Originator's state changes while a memento is being created, the snapshot may be inconsistent.

4. Avoiding Overuse
The Memento pattern adds complexity by introducing new classes. For very simple state changes, a Command Pattern (which stores the inverse operation rather than the full state) might be a more lightweight and efficient alternative.

Summary

The Memento pattern provides a sophisticated way to implement state recovery while preserving the sanctity of an object's internal encapsulation. By separating the Originator (the state owner), the Memento (the state container), and the Caretaker (the state manager), it ensures that the logic for "remembering" does not interfere with the logic for "doing." When implemented with a focus on immutability and memory management, it is an indispensable tool for creating resilient, user-friendly applications.