Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
Next let's take a look at the Memento Design Pattern. This is a way of managing change, basically a way to undo a change to an object, but doing it in a way that does not violate encapsulation, and the idea that an object should always manage itself. I am going to illustrate this one without code. This Memento Design Pattern requires three classes that take certain roles, and we'll call them the Originator, the Caretaker, and the Memento. So we have the Originator. This is the object that you want to be able to change, and then undo any changes to.
For you this could be a customer object, a spaceship object, whatever needs to be able to reverse out a change. But the question is who is changing it, who is affecting it? Well, then we have the object we refer to as the Caretaker. This object is going to deal with taking care of when and why the Originator needs to either save its state or to revert back to a previous state. Now, the Caretaker is often also the object that will actually be changing the Originator, so it's in a good position to know when it needs to save state.
So the Originator is in a particular state at the moment, and the Caretaker requests that the Originator save itself, and here is where the Memento object comes into play. The Originator creates a Memento object, which is a simple object that just details the important parts of the Originator, the information needed to return to a particular state. And it bundles that information up in the Memento and returns it to the Caretaker. And here's the thing. The Caretaker does nothing except store that Memento.
It doesn't look at the internal state of that object, it doesn't do anything with it, it just takes care of it. And then we issue a few calls to the Originator to change it. These calls could come from the Caretaker, they could come from elsewhere. And at any point the Caretaker could ask again for another Memento, if we wanted to keep multiple levels of undo. But the Originator is not encumbered by trying to keep track of multiple levels of state inside itself. And if we want to revert to a particular state, the Caretaker just hands back the Memento object to the Originator and asks it to restore itself.
So we're not breaking encapsulation, the Originator is still the object that takes care of its own internal state. We're not reaching in from the outside and starting to tweak all the different attributes. But neither does the Originator need to keep its own stack of changes to itself. As you can see, with this one, this could be implemented in virtually any Object-Oriented Design language, and this is the Memento Design Pattern. When you start to explore Design Patterns, particularly simple ones like Memento, it's common to occasionally think, well, I could have come up with that idea myself.
And really this is kind of the point, Design Patterns are situations that did arise naturally multiple times and they've been proven to work just worth putting down on paper so that they become common knowledge. And while it's true that most Design Patterns are more complicated than Memento, hopefully you now have a good idea of where they fit in the Object-Oriented Design process.
Get unlimited access to all courses for just $25/month.Become a member