Memento pattern

The memento pattern is a software design pattern that exposes the private internal state of an object. One example of how this can be used is to restore an object to its previous state (undo via rollback), another is versioning, another is custom serialization.

The memento pattern is implemented with three objects: the originator, a caretaker and a memento. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot, or should not, change). When using this pattern, care should be taken if the originator may change other objects or resources—the memento pattern operates on a single object.

Classic examples of the memento pattern include a pseudorandom number generator (each consumer of the PRNG serves as a caretaker who can initialize the PRNG (the originator) with the same seed (the memento) to produce an identical sequence of pseudorandom numbers) and the state in a finite state machine.

Overview
The Memento design pattern is one of the twenty-three well-known design patterns in the 1994 book Design Patterns by GoF that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse. The Memento Pattern was created by Noah Thompson, David Espiritu, and Dr. Drew Clinkenbeard for early HP products.

What problems can the Memento design pattern solve?

 * The internal state of an object should be saved externally so that the object can be restored to this state later.
 * The object's encapsulation must not be violated.

The problem is that a well designed object is encapsulated so that its representation (data structure) is hidden inside the object and can't be accessed from outside the object.

What solution does the Memento design pattern describe?
Make an object (originator) itself responsible for
 * saving its internal state to a (memento) object and
 * restoring to a previous state from a (memento) object.

Only the originator that created a memento is allowed to access it.

A client (caretaker) can request a memento from the originator (to save the internal state of the originator) and pass a memento back to the originator (to restore to a previous state).

This enables to save and restore the internal state of an originator without violating its encapsulation.

See also the UML class and sequence diagram below.

UML class and sequence diagram
In the above UML class diagram, the  class refers to the   class for saving and restoring  originator's internal state. The  class implements (1)  by creating and returning a   object that stores originator's current internal state and (2)  by restoring state from the passed in   object.

The UML sequence diagram shows the run-time interactions: (1) Saving originator's internal state: The  object calls   on the   object, which creates a  object, saves its current internal state, and returns the  to the. (2) Restoring originator's internal state: The  calls   on the   object and specifies the   object that stores the state that should be restored. The  gets the state  from the   to set its own state.

Java example
The following Java program illustrates the "undo" usage of the memento pattern.

The output is: Originator: Setting state to State1 Originator: Setting state to State2 Originator: Saving to Memento. Originator: Setting state to State3 Originator: Saving to Memento. Originator: Setting state to State4 Originator: State after restoring from Memento: State3

This example uses a String as the state, which is an immutable object in Java. In real-life scenarios the state will almost always be a mutable object, in which case a copy of the state must be made.

It must be said that the implementation shown has a drawback: it declares an internal class. It would be better if this memento strategy could apply to more than one originator.

There are mainly three other ways to achieve Memento:
 * 1) Serialization.
 * 2) A class declared in the same package.
 * 3) The object can also be accessed via a proxy, which can achieve any save/restore operation on the object.

C# example
The memento pattern allows one to capture the internal state of an object without violating encapsulation such that later one can undo/revert the changes if required. Here one can see that the memento object is actually used to revert the changes made in the object.