Understanding the Memento Design Pattern

Understanding the Memento Design Pattern

When persisting an object, you sometimes face the following problem: Some or all of the object's internal states are private. Therefore, there is no way to obtain the values of those states without violating encapsulation.

However, you might argue, the object serialization technique in the .NET Framework allows you to persist objects into a file stream or other device. Yes, that is true. Nonetheless, the classes of some objects do not implement the ISerializable interface or are not marked with the <Serializable> attribute. For example, you may want to persist an instance of a class that inherits from the System.Windows.Forms.Control class, as is the case in our drawing application. The System.Windows.Forms.Control class is not marked with the <Serializable> attribute, and it does not implement the ISerializable interface. Attempting to serialize an object of this class will throw an exception.

In addition, there are two other problems to solve. The first relates to efficiency. Suppose you have a large object that you want to persist, but only a small fraction of the states inside the objects need to be persisted. Serializing the whole object will require greater space than necessary, not to mention that it will take longer time to serialize it and later retrieve it.

The second problem has to do with security. You may want to protect some internal state of the object. In other words, you may want to persist some states but not some other states.

The aforementioned issues make the object serialization technique seem useless, doesn't it? Not really. You can still use the .NET Framework object serialization technique with the help of the Memento design pattern.

The idea of the Memento pattern is simple. In this pattern, the object whose state you want to persist is called the originator. To apply the pattern, you create another object called the memento. The memento object is an external object that will hold the states of the originator. Therefore, if you need to save the states of the variables a, b, c, and d from the originator, the Memento pattern will have the same variables a, b, c, and d. But, hold on a second. What if some of the states are private fields, which of course are not accessible from outside the originator? The solution to this problem is the beauty of this pattern. The originator will have two extra methods: One is called CreateMemento, and the other is SetMemento.

The CreateMemento method instantiates a memento object, copies all its states that need to be persisted to the memento object, and then returns the memento object. Therefore, to persist the originator, you call its CreateMemento to obtain a memento object and then serialize the memento object.

The SetMemento method gets the states back. After you deserialize the previously saved memento object, you call the SetMemento object of the originator by passing the memento object obtained from the deserialization.

Clever, isn't it?

In the project in this chapter, you will modify the Memento design pattern a bit. The CreateMemento is called GetMemento, and instead of providing the SetMemento method, you will use a constructor that accepts a memento object. You can then use this constructor to instantiate the object as well as to restore the previous states.

Exploring the UML Class Diagram

UML is the standard language for object-oriented software visualization, specification, construction, and documentation. Grady Booch, Ivar Jacobson, and Jim Rumbaugh at Rational Software Corporation developed UML, with contributions from other methodologists, software vendors, and users. UML is a combined methodology of the Booch, OMT, and Jacobson methods.


You can find various documents at http://www.rational.com/uml/index.jsp. A good tutorial book on UML is The Unified Modeling Language User Guide (Addison-Wesley, 1998).

There are three kinds of building blocks in the UML vocabulary:

  • Things

  • Relationships

  • Diagrams

You can group things in UML into four categories:

  • Structural things

  • Behavioral things

  • Grouping things

  • Annotational things

There are also four kinds of relationships in UML:

  • Dependency

  • Association

  • Generalization

  • Realization

The UML includes nine types of diagrams:

  • Class diagram

  • Object diagram

  • Use case diagram

  • Sequence diagram

  • Collaboration diagram

  • Statechart diagram

  • Activity diagram

  • Component diagram

  • Deployment diagram

As you can see, UML addresses all the views needed to build and deploy object-oriented applications and therefore is very extensive. As such, tools for manipulating all aspects of the UML are also large applications. Understandably, such applications are not cheap. The most popular UML tools are the various products from Rational Software Corporation (http://www.rational.com). Alternatives include the Poseidon for UML Professional Edition and the Poseidon for UML Community Edition from Gentleware (http://www.gentleware.com). The latter is freely downloadable from the Web site.


You can also use UML to model nonsoftware systems.

The project in this chapter addresses a tiny fraction of UML: the class diagram.