Unit 31 Memento

1. Unit 31Memento Summary prepared by Kirk Scott

5. Design Patterns in JavaChapter 19Memento Summary prepared by Kirk Scott

6. The Introduction Before the Introduction • This is a succinct preview summary of the memento examples: • 1. You can save the state of a running application in a stack data structure • 2. You can also save the state of an application in secondary storage using serializability

7. It’s worth noting again that there is some utility in the authors’ emphasis on intent • Structurally, there is no close relationship between a stack and serializability • However, in their respective contexts, transient vs. persistent storage, they can both be used in order to accomplish the same thing

8. The book’s examples are based on adding an undo feature to the graphic visualization of a factory • Whenever a change is to be made to the state of the visualization, a copy of the current state is saved before the change is made • When the undo option is selected, the current state is replaced by the most recently saved state

9. Book definition: • The intent of the Memento pattern is to provide storage and restoration of an object’s state

10. A Classic Example: Using Memento for Undo • A memento may be as simple as a single object that holds an application’s state • It may also turn out that some collection of objects or some data structure (like a stack) is involved in implementing the memento pattern

11. From a practical point of view, these kinds of questions have to be answered: • How will state be captured in a memento? • When will the state be captured? • How will the previous state be restored based on the contents of the memento?

12. On the next overhead the visualization is shown at start up • Its state is currently empty—but it’s important to note that empty is a state • Since nothing has been done yet, the Undo button is disabled

14. The next overhead shows the application after a few machines have been added and dragged around the work area • Note that the Undo button is no longer disabled

16. The state that needs to be captured is a list of the locations of the machines that the user has placed in the application • The scenario under discussion is one of run-time functionality • The book suggests keeping a list of locations, each list being a memento, on a stack • Clicking the Undo button means popping the stack

17. In particular, the book outlines the functionality in this way: • 1. Each time the user takes an action like add or move, a memento will be created and pushed onto the stack • 2. Each time the user clicks Undo, the stack will be popped, removing the current state, and the state will be restored to the previous state, which is now at the top of the stack

18. At start-up time, a memento of the empty state will be pushed onto the stack • The visualization always has a state and the stack will never be empty • The Undo button will be disabled when the stack only has a single entry in it • It will not be possible to pop the empty state off of the stack

19. Comment mode on: • The book hasn’t stated how the list of machine locations will be saved yet, but strictly speaking, such a list is the literal memento in the application • The stack is used in order to manage a collection of potentially more than one memento

20. Comment mode, continued: • The book’s approach may not be elegant, but it’s straightforward • Notice that they aren’t trying to save a list of actions, for example • This means that it’s not necessary to figure out how to undo an action

21. Comment mode, continued: • Instead, complete states are saved • Then undoing simply means restoring the previous state • I would note that there seems to be a lot of redundancy in storing all of the previous states in this way

22. I suspect that it would be possible to model state as a sequential collection of machines and a sequence of actions taken on them • This might result in less redundancy among the mementos • The code for undoing would be considerably more complex than simply restoring the list of previous machine locations

23. The book suggests that overall the visualization can be structured using a model-view-controller type design • A UML diagram is given on the following overhead showing how the visualization and the factory model are implemented in separate classes • The meaning of the VisMediator class and the various relationships shown will be outlined afterwards

25. The UML diagram is supposed to illustrate what happens when the user interacts with the visualization: • When a machine is added or moved, the factory model should change accordingly, • The appearance of the visualization should be updated, • The state should be saved

26. When the user clicks Undo the previous state should be restored to the model • The appearance of the visualization should also be updated when this happens

27. The application reacts to events by means of a mouse listener in the work area and listeners for the Add and Undo buttons • Part of the role of the VisMediator class is to hold the functionality that responds to events • In other words, the VisMediator contains the controller functionality

28. On the next overhead, a UML diagram of the Factory Model class is shown with references to instances of the Stack and ArrayList classes • The stack holds the mementos • The instance of ArrayList holds the listeners for the graphical components of the application

30. Point number one about the diagram/design is the ArrayList of listeners • This neither good nor bad, but it’s probably unnecessary in an application this small • Unfortunately, it is also a potential source of confusion

31. The diagram doesn’t show it, but we will also be interested in what kinds of things will be stored on the stack • In other words, what is a memento • It will turn out that a memento is an ArrayList of which holds the points specifying the locations of the machines in the work area for a given application state • The mementos shouldn’t be confused with the ArrayList of listeners

32. Next the book shows some partial code to give an idea of how the FactoryModel class works • The beginning declarations and the default constructor are shown on the following overhead

33. public class FactoryModel • { • private Stack mementos; • private ArrayList listeners = new ArrayList(); • public FactoryModel() • { • mementos = new Stack(); • mementos.push(new ArrayList()); • } • …

34. Most of the code shown is unremarkable • The most important thing to notice is this line of code: • mementos.push(new ArrayList()); • A memento is an instance of ArrayList • When the model is constructed, the empty state is put onto the stack • The default constructor is used to create an empty ArrayList and push it onto the stack

35. Notice that in general, there is no need for a state to be named • The states are not named instances of objects • They are simply instances of ArrayList constructed at the moment • Their identifying feature which is important to the application is where in the stack they occur, since a stack is an ordered data structure

36. The book summarizes the rest of the methods in the FactoryModel class as follows: • They maintain the stack of mementos • They deal with events that make changes

37. Code for the FactoryModel add() method is shown on the following overhead, for example • Adding a machine to the visualization means adding a point to the list of machine locations • When this change occurs, any listeners have to be notified • Comments have been added to the code

38. public void add(Point location) • { • /* Get a copy of the old state by peeking at the top of the stack of mementos. */ • List oldLocs = (List) mementos.peek(); • /* Create a new state, the same as the old. */ • List newLocs = new ArrayList(oldLocs); • /* Add the new location to the new state. */ • newLocs.add(0, location); • /* Push the new state onto the stack. */ • mementos.push(newLocs); • /* Notify the listeners of changes to the state. */ • notifyListeners(); • }

39. It is possible to iterate over lists without worrying about the order of their contents • It is also possible to refer to elements of the list by index • In the previous method, a location was added to a memento list at position 0 • The idea here is that if things overlap in the visualization, those things most recently added will be displayed on top

40. The code for the getLocations() method is given on the following overhead • Responding to events and repainting the work area will require access to all of the current machine locations • The method returns the list of current machine locations—the list at the top of the memento stack • Notice that peek() is not the same as popping the stack

41. public List getLocations() • { • return (List) mementos.peek(); • }

42. Next the book considers the undo() method in the FactoryModel class • This is the method that triggers a change in state back to the previous one • Like the add() method given above, the undo() method will have to notify any listeners • The book deals with this method as a challenge

43. Challenge 19.1 • Write the code for the FactoryModel class’s undo() method.

44. Solution 19.1 • Here is one implementation of undo() for FactoryModel • [See the code on the following overhead] • Comment mode on: • It is not clear to me why the authors have broken the implementation into two tiny methods • It’s clear how it works • It’s also clear how the two could easily be merged

45. public booleancanUndo() • { • return mementos.size() > 1; • } • public void undo() • { • if(!canUndo()) return; • mementos.pop(); • notifyListeners(); • }

46. Solution 19.1, continued: • This code is careful to ignore undo() requests if the stack is down to its initial state with a single memento. • The top of the stack is always the current state, so the undo() code has to pop the stack to expose the previous memento.

47. Solution 19.1, continued: • When you write a createMemento() method, you should convince yourself or your colleagues that the method returns all the information necessary to reconstruct the receiving object. • In this example, a machine simulator can reconstruct itself from a clone, and a factory simulator can reconstruct itself from a list of machine simulator clones.

48. Solution 19.1 • Comment mode on • What the authors are trying to say in the previous paragraph is not clear • They have claimed that the only memento you need for this application is a list of machine locations • Presumably, the picture of each machine in the visualization is just a stock image • Why they’re now babbling about clones and lists of clones is not clear

49. Back to the material in the text: • The previous UML diagram and code examples gave some idea of the FactoryModel class • It contains methods that change the state of the model • It also contains methods to register listeners and notify them when the state changes

50. An expanded UML diagram showing the relationships between the FactoryModel, Visualization, and VisMediator classes will be shown shortly • The Visualization class has methods related to creating the GUI of the application • It can respond to changes in the factory model in order to update the graphical representation