76: Design Patterns: Memento.

What is the memento design pattern? The memento behavioral pattern allows you to save and later restore the state of an object even without full access to all properties. This lets you avoid using internal knowledge that could break later or weaken your designs. 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. If you’d like to read the book that describes this pattern along with diagrams and sample code, then you can find Design Patterns at the Resources page. You can find all my favorite books and resources at this page to help you create better software designs. Listen to the full episode about this pattern or you can also read the full transcript below. Transcript The basic description says that this pattern lets you obtain an object’s internal state to an external object without violating encapsulation and then use the external object to restore the state back to what it was. This is one of those scenarios where it’s not immediately obvious why it’s needed. I’m going to use an example of a car engine to explain this design pattern. What methods and properties would a car engine class need? The methods start and stop come to mind as well as a property for how much fuel is being provided. This should be good enough to get started. Start and stop are simple and don’t need any parameters. We can say that even if no fuel is being provided, that the engine will still draw a certain minimum amount. Otherwise, if you call start, the engine would die right away without fuel. Sure, we could work around this but I’m going to keep this simple. The fuel property can be a number from 0 to 100 representing a percentage from no additional fuel beyond the minimum to some maximum rate. We should be able to get and set this property. As it is now, it seems like we have everything we need. We could even add another property called isRunning that would be read only just so we don’t have to remember ourselves if start was called or not. With these methods and properties we should have enough to be able to save the current state of the engine so we can put it back at some point, right? Episode 72 described the command pattern that lets you implement a undo/redo feature. Maybe we have commands for manipulating the engine state and want the commands to be able to be undone. We start out with a command to start the engine. No problem here. Then the user decides to read an emai