Memento Design Pattern and its use cases

Memento design pattern is a design pattern which specifies the behaviour of an application. It is mainly used when there is a need to restore the state of an object to a previous state possibly set by the user. It might also be known to some as the snapshot patter.

You can imagine playing a game, where a user may save the games at certain points, and if the player dies or chooses to reset the game, the game is loaded from the last checkpoint. In fact, this analogy not only helps you understand the pattern better, but is in fact also a use case for this design pattern, neat isn’t it.

More formally, the memento design pattern allows the client to create points within the life cycle of an object where the client can choose to restore the state of the object to, and when needed, actually revert the state of the object to that particular state.

The above diagram represents the architecture and general execution flow of an application using this design pattern. As seen in the diagram, the architecture of such an application can be broken down mainly into 3 parts. The caretaker, which is similar to the manager of this application, it can use the originator to create mementos, or restore the state of the originator to the state of a particular memento. The caretaker also keeps track of all the mementos created. The Originator, which as the previous explanation suggests, provides functionality to create mementos, and revert its state to a particular memento. Lastly, the Memento itself, which is the actual saved state of an application. It is is created by the originator, and an originator can also get a application’s previous state from a memento. Formally speaking, it should be an immutable object to ensure that it will not be changed after its creation. Obviously if a memento can be mutated after its creation it could lead to a whole host of problems as a saved state is no longer guaranteed to be accurate.

Real world examples of this design pattern is all around us, and what could be more familiar to us than IDEs. The memento design pattern is clearly heavily used in any IDEs, as can be seen when you constantly use CTRL+ Z, to undo mistakes you have made either intentionally or unintentionally. You can imagine that the editor is the caretaker, while the code itself is the memento. As you edit, the editor constantly creates mementos, on a recent state, so that when you inevitably hit the undo button, you are able to precisely revert back to the state you want or at least the closest state. When you revert back to a state, the editor would also create a memento of the current state, so that you may switch back to it should you choose not to revert back to a previous state after all. The editor keeps track of all these different states of the code, and also has to provide garbage collection, as the oldest states are removed beyond a certain threshold.

Related posts:

moving out permanently the wind blowing over the sea green grass and greener hills too many times, and not enough. forgiveness comes in boxes of blue fly away for good, or just for tomorrow the…

Cryptocurrency has the illusion of being an investment. An investment has an underlying value. When you drill down Bitcoin, there is nothing at the bottom.

DataStructure With Swift, a Medium series by Divyanshu Sharma