The memento behavioral pattern allows you to save and later restore the state of an object even without full access to all properties.

You can use this pattern to save an object’s state so you can possibly restore the object at some later time back to what it was when the state was saved. You might wonder why you can’t just read the properties in your code and save everything you read. Because there could be either properties that are read-only or not exposed at all. You might be able to read a read-only property but you won’t be able to restore that property later.

Another option would be to just allow the object itself to save its own state and restore it. The problem with this is that the object then needs to manage the storage. What if your application wants to allow ten different saves or a hundred? That’s up to the rest of your application so it makes sense that your application should be the one to manage all this saved information.

This pattern describes a solution where you ask an originating object for its state in the form of another object called a memento. The code outside of the object, in other words, the rest of your application, has no access to the internal data in the memento object. All it can do is save the memento for possible use later. If the user does want to restore the state, then your application just passes the saved memento back to the original object. Since we’re back in the object that created the memento, it has full access to read the state and update it’s own properties so they match the memento.

This lets you restore an object without knowing about or even have access to all the data needed to put an object back into some previous state.


What's on your mind?
On a scale of 0 to 10, how likely are you to refer us to friends?