Memento Pattern
Hey there, today I am going to start a series of design pattern blogs. I will be posting design patterns with its implementation in Java language.
First of all, let’s understand what is design pattern and why we need them.
Design patterns are known solutions to a specific type of problem. For example, if we have to implement an undo feature in any software/editor we use Memento Pattern . A design pattern is not coupled with any language we can implement it in almost all the language but mostly they work on object-oriented programming principles.
Why do we need it?
Design patterns are proven solutions that help us to write reusable and extensible object-oriented software. It also provides a common terminology to communicate with other programmers.
In this series of design patterns, we are going to cover the design patterns from the famous book — Gangs of four
There are a total of 23 design patterns which are divided into three categories
- Creational patterns provide object creation mechanisms that increase flexibility and reuse of existing code.
- Structural patterns explain how to assemble objects and classes into larger structures while keeping these structures flexible and efficient.
- Behavioral patterns take care of effective communication and the assignment of responsibilities between objects.
Let’s start from Behavioural Design Patterns and see how objects communicate with each other …
- Memento Pattern
- State Pattern
- Iterator Pattern
- Strategy Pattern
- Template Pattern
- Command Pattern
- Observer Pattern
- Mediator Pattern
- Chain of Responsibility
- Visitor Pattern
Memento Pattern
Memento patterns are useful when we have to keep track of the history of an object. It is used to implement undo mechanisms in the software industry.
Problem:
Implement an editor which supports text writing, font size change, font name change, and also undo features. It should have a method that modifies the content of the editor and one method which takes you one step back. I should be able to undo it multiple times. It should record all the properties like current text, font size, and font name.
The document/originator class in the memento would be something like the below,
Responsibilities —
- Creation of document
- Creation of state
- Restore the previous state
Here by states, we meant document state which is also the memento in the pattern.
Note — here we are maintaining the creation and deletion of state inside the document class itself which is actually violating the Single Responsibilty Priniciple . It can be avoided by moving out the history maintenance to the driver code itself. We will resolve this issue at some later point in time after learning the required patterns, till then bear this with me.
Our document state or memento is just a record class nothing else. Let’s have a look -
It implements the memento interface which contains a minimal API to tell about the name and time of object creation. It provides an abstraction and hides the internal details from history class. History class shouldn’t have access to internal details of our document state which we are achieving by implementing the memento.
Now we will see the implementation of our history/caretaker class in the memento pattern.
Here, note that we are not storing the actual document state object here, instead, we are using the interface as the abstraction so tomorrow if we have to make any changes in the document it won’t affect the caretaker/history class.
Now, let’s see the driver code and the output of the above work.
Finally, we have implemented our first pattern. please do clap 👏 if you liked the content and if there is any suggestion let me know in the comments.
Keep coding ⌨️.
