A Picture Is Worth A Thousand Words - Memento Design Pattern

The word Memento means - an object kept as a reminder of a person or event.

Memento is a behavioral design pattern that lets you save and restore the previous state of an object without revealing the details of its implementation. The below image depicts the players. The Class whose lifecycle is to be tracked and a repository (in-memory) of the snapshots of the object of this class which holds the data at a particular spot on the timeline. One invisible player in the below image is the one who will control and decide when to take these snapshots and restore them.

A Picture Is Worth A Thousand Words - Memento Design Pattern

You may have read numerous articles and explanations on Memento Design Pattern. Here, I am trying to explain it by using more pictures and fewer words. Let's say I have a paint editor canvas application where I am trying to draw the following image,

Now, I have used a number of geometric figures to create this image.

Underlying each shape, there is the number of properties of the shapes that hold their 'state'. The word 'state' here means all details related to the shape - its coordinates, color, size, border color, etc.

Now let's explore my expectation from the application,

I should be able to add any shape to the canvas.
I should be able to change its size and move it around.
I should be able to UNDO if I feel that I don't like what I added or changed.
The system should keep saving my changes so that I can restore them.

Here is the overall expectation in the form of a picture.

Whenever the user (you / I ), make any change on the canvas, the Editor tells that event to the caretaker. The caretaker / Manager then immediately takes a backup (snapshot) of the current state of the editor and stores it in the snapshot buckets. The Bucket List is maintained by the Caretaker only. When and which bucket to restore or delete, it is managed by the Caretaker.

Few points to understand the function of each of the players here - The Editor, the Caretaker, and the Snapshot Buckets.

The Caretaker does not know what is inside the snapshot - what attributes, how many attributes, etc. Only the Editor knows, what it is saving in the bucket. Thus the details are completely 'encapsulated' between Editor and Bucket. The Caretaker only controls when to take a backup and when to restore it, that's it. This allows the programmer to implement different capabilities of the Caretaker without burdening it with inner details.

In terms of OOPS, the class structure for these players would typically be,

The actions would work like this,

Finally, if you wish you have the classes in the form of code, here is the snippet,

using System.Collections.Generic;
using System.Linq;
namespace MementoExample {
public class Color {
//Properties of R,G,B values
}
public class EndPointCoordinates {
//Properties of X, Y
}
public class SnapShot {
public string ShapeName {
get;
set;
}
/// All the end point cursors collection, dependending on
/// how many corners the shape has.
public List < EndPointCoordinates > Cursors {
get;
set;
}
public Color FillColor {
get;
set;
}
public Color BorderColor {
get;
set;
}
/// Constructor
public SnapShot(Color fill, Color border, List < EndPointCoordinates > coordinates) {}
}
// The originator holds some important data that may change over
// time. It also defines a method for saving its state inside a
// memento and another method for restoring the state from it.
public class Originator {
public List < EndPointCoordinates > CurrentCoordinates {
private get;
set;
}
public Color FillColor {
private get;
set;
}
public Color BorderColor {
private get;
set;
}
// Saves the current state inside a memento.
public SnapShot CreateSnapshot() {
return new SnapShot(fill: FillColor, border: BorderColor, coordinates: CurrentCoordinates);
}
public void RestoreSnapshot(SnapShot snapshot) {
CurrentCoordinates = snapshot.Cursors;
FillColor = snapshot.FillColor;
BorderColor = snapshot.BorderColor;
}
}
public class CareTaker {
readonly Originator editor = new Originator(); // clean slate
readonly List < SnapShot > backupStack = new List < SnapShot > (); // the snapshot collection
public void makeBackup() {
backupStack.Add(editor.CreateSnapshot());
}
public void Undo() {
editor.RestoreSnapshot(backupStack.Last()); //restore the last added snapshot
backupStack.RemoveAt(backupStack.Count - 1);
//delete the snapshot after restoring it
//however this is optional. You can retain this snapshot if you wish to implement REDO
}
}
}

Now some real-world, programming tip.

Conclusion

The Originator class can produce snapshots of its own state, as well as restore its state from snapshots when needed.
The Memento is a value object that acts as a snapshot of the originator’s state. It’s a common practice to make the memento immutable and pass it the data only once, via the constructor.
The Caretaker knows not only “when” and “why” to capture the originator’s state, but also when the state should be restored.
Though I have shown here as a public class, in the practical implementation, the memento (Snapshot) class is nested inside the originator (C# allows nested classes). This lets the originator access the fields and methods of the memento, even though they’re declared private. On the other hand, the caretaker has very limited access to the memento’s fields and methods, which lets it store mementos in a stack but not tamper with their state. Since the memento class doesn’t declare any public fields, getters, or setters. Therefore no object can alter its contents. Mementos are linked to the Originator object that created them. This lets a memento restore the linked Originator’s state bypassing the data via setters on the Originator object. Since mementos are linked to specific Originator objects, you can make your app support several independent Originator types with a centralized Caretaker stack.

Watch out for,

Determine what class will play the role of the originator. It’s important to know whether the program uses one central object of this type or multiple smaller ones.
Make the memento class immutable. A memento should accept the data just once, via the constructor. The class should have no setters.
The app might consume lots of RAM if clients create mementos too often.
Caretakers should track the originator’s lifecycle to be able to destroy obsolete mementos. The caretaker, whether it represents a command object, a history, or something entirely different, should know when to request new mementos from the originator, how to store them and when to restore the originator with a particular memento.