The Memento Design Pattern is a behavioral design pattern that lets you capture and store an object’s internal state so it can be restored later, without violating encapsulation.

It’s particularly useful in situations where:

• You need to implement undo/redo functionality.
• You want to support checkpointing or versioning of an object’s state.
• You want to separate the concerns of state storage from state management logic.

Let’s walk through a real-world example to see how we can apply the Memento Pattern to solve a real-world problem that involves implementing undo functionality in a text editor.

1. The Problem: Implementing Undo in a Text Editor

Imagine you’re building a simple text editor. The editor supports basic operations like:

• type(String text) – appends text to the current document
• getContent() – returns the current document text
• undo() – reverts to the previous version of the content

Implementing typing and reading is easy. The real challenge is undo.

Naive Implementation: Undo via Manual Snapshots

You might start with something like this:

Example Usage

What’s Wrong with This Design?

While this naive implementation works for very basic undo logic, it introduces several major issues:

1. Encapsulation is Broken

• The client must manually fetch and store internal state (getContent()) just to implement undo.
• This exposes implementation details and violates the principle of information hiding.

2. Manual Snapshot Management

• The client is responsible for managing previous versions of the content.
• This makes undo logic error-prone and tightly coupled to the editor’s internal structure.

3. Not Scalable

• What if you want to undo multiple actions (not just one)?
• Or restore cursor position, formatting, and selection along with content?You’d need to extend the snapshot logic, leaking even more of the editor’s internal state into the client.

What We Really Need

We need a solution that allows:

• The TextEditor to expose a safe way to capture and restore its state
• The client to manage these states (snapshots) without knowing or touching internal fields
• Undo/redo to be implemented in a way that is scalable, maintainable, and encapsulated

This is exactly what the Memento Pattern is designed to solve.

2. What is the Memento Pattern

The Memento Design Pattern allows an object to save and restore its state without exposing its internal structure. It achieves this by encapsulating the state in a special object called a Memento.

This pattern is ideal for implementing undo/redo, version history, or state rollback features.

Class Diagram

1. Originator (e.g., TextEditor)

The object whose internal state you want to capture and restore later. It is responsible for:

• Creating a memento that captures its current state
• Restoring its state from a memento when needed (e.g., during an undo operation)

It encapsulates the logic to decide what state to save, ensuring the client or caretaker never has access to its internals.

2. Memento

• A passive object that holds the snapshot of the Originator’s state at a given point in time.
• It does not expose any methods to modify its state.
• Only the Originator can access the internal state inside the memento.

3. ConcreteMemento (Optional)

• In more complex systems, the Memento might be defined via an interface or abstract class, and a ConcreteMemento provides the actual implementation.
• This allows for future extensibility or multiple types of mementos.
• In many simple use cases (like ours), the Memento itself acts as the concrete implementation.

4. Caretaker

• The Caretaker is responsible for storing, managing, and restoring mementos.
• It never examines or modifies the content of a memento, it just treats it as a black box.

3. Implementing Memento

Let’s refactor our naive text editor into a clean, maintainable design using the Memento Pattern.

Our goal is to enable undo functionality in a way that is:

• Encapsulated – the editor’s internal state remains private.
• Flexible – the editor can save and restore snapshots.
• Safe – the client doesn’t manipulate state directly.

1. Create the Memento Class - TextEditorMemento

The memento stores a snapshot of the TextEditor's internal state. It is usually:

• Immutable – fields are private final and not modifiable after creation.
• Minimal – it stores only the state required for restoration.
• Encapsulated – only the originator (the TextEditor) should know how to use it.

This class is passive and doesn’t contain any logic — just a snapshot of the editor’s state.

2. Create the Originator – TextEditor

The originator is the object whose state we want to save and restore. It provides:

• A method to create a memento representing its current state.
• A method to restore its state from a given memento.

3. Create the Caretaker – TextEditorUndoManager

This class manages the undo stack. It is responsible for:

• Managing the history of states (mementos).
• Calling the originator's save() and restore() methods at the right time.
• Not inspecting or modifying the internal state itself.

The TextEditorUndoManager allows us to perform undo operations cleanly, without the client managing snapshots directly.

4. Client Code – Using the Editor with Undo Support

Output

What We Achieved

• Encapsulation: Editor’s internal state is never exposed directly to the client
• Clean undo logic: The client doesn’t need to manage or interpret state — it just saves and restores
• Separation of concerns: The TextEditor handles state, and the TextEditorUndoManager handles history
• Scalability: Easy to extend with redo support, multi-level undo, or persistent versioning