Chapter 19 Memento

1. Chapter 19Memento 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 graphical visualization of a factory is shown at software 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 scenario under discussion is one of run-time functionality • The state that needs to be captured is a list of the locations of the machines that the user has placed in the application • One such list is a memento • A history of multiple states is stored in 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. What the Book Does Next • In keeping with the plan of previous chapters, the book develops the application step-by-step • It gives an initial solution • It then modifies that solution • The solutions illustrate a particular coding technique which isn’t part of the pattern but which deserves explanation

24. In general, this is what should happen 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

25. 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 • The application reacts to events by means of a mouse listener in the work area and listeners for the Add and Undo buttons

26. Notice how this problem description seems like it might be ripe for an MVC solution • In its solutions the book doesn’t use listener and observer like in full MVC • However, it does use listening in order to achieve its goal • (You could argue whether the implementation is “MVC in spirit”—which may be a dangerous oxymoron.)

27. The Book’s First Solution • On the next overhead, a UML diagram of the FactoryModelclass is shown with references to instances of the system supplied Stack and ArrayList classes • The stack holds the mementos • The instance of ArrayList holds the listeners for the graphical components of the application • This second point will merit discussion

29. The Book’s Coding Technique Applied to this Problem • Ultimately, it’s the stack of mementos that is of real interest • However, there is no escaping theArrayList of listeners in the design • Notice that the FactoryModel class also implements methods named addChangeListener() and notifyListeners()

30. It is neither inherently good or bad to gather listeners together in an ArrayList • We’re seeing something of how listeners are managed in system supplied classes only in programmer written code • From the perspective of the previous unit, the important point is that we have a GUI, but we are not using the Observer design pattern in order to an MVC application

31. The diagram hasn’t broken out the view yet • But from this initial diagram alone, it is apparent that the model and the controller functionality are intertwined • You might say the authors have implemented an “MVC design in spirit”, although that might be an oxymoron

32. In any case, the first task is to be clear about how the ArrayList of listeners and the addChangeListener() and notifyListeners() methods work • After that we’ll take a look at how the memento functionality works • Then we’ll move on from this example to the next, which should be a better solution

33. The ArrayList of Listeners • On the next overhead those parts of FactoryModel having to do directly with the ArrayList of listeners is shown

34. public class FactoryModel { • … • private ArrayList listeners = new ArrayList(); • … • public void addChangeListener(ChangeListener listener) { • listeners.add(listener); • } • … • public void notifyListeners() { • for (inti = 0; i < listeners.size(); i++) • ((ChangeListener) listeners.get(i)).stateChanged(new ChangeEvent(this)); • }

35. By way of introductory explanation, what they authors have done is make FactoryModel “listenable” • Making it observable would have been syntactically clear and better • The point is that there is no such thing as listenability except by “inventing” it

36. That’s what they’ve done here • You don’t extend a listenable class • You simply implement methods that make it possible to have a collection of listeners associated with FactoryModel • Then look at the notifyListeners() method • You explicitly call stateChanged() on each associate listener

37. In other words, you’re not relying on a callback sequence • You’re coding it yourself • The more I look at this the less I like it

38. I’m getting ahead of myself, because we haven’t discussed how the mementos actually work yet, but this is a call that changes the state by adding a memento • The point is, this is where a call to notifyListeners() is located • public void setLocations(ArrayList list) • { • mementos.push(list); • notifyListeners(); • }

39. In short, in an MVC design, when the model/state/mementos changed, you would observe that fact and the observers would “act” • Here, we’re short-circuiting this by notifying listeners to act when the state changes

40. The remaining question is, what is or are the actual listeners for this application? • What do they do when the state of the FactoryModel changes and they are notified? • We won’t arrive at the answer to this question until later…

41. Anyway, this is the general design for how the authors have implemented their example • In order to follow the rest of the explanation of the handling of mementos, it’s simply necessary to accept this and see what else they have done

42. Implementing Memento in the First Example • What is a memento? • It is an ArrayListwhich holds the points specifying the locations of the machines in the work area for a given application state • The stack in the FactoryModel potentially holds multiple instances of such ArrayLists

43. Here is the code at the beginning of the FactoryModelclass • It shows the declarations of the Stack of mementos and the ArrayList of listeners • It also shows the default constructor • In it the Stack is constructed and the initial, empty state is constructed and pushed onto it

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

45. 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

46. 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

47. Ordering of mementos • The identifying feature of states which is important to the application is where in the stack they occur, since a stack is an ordered data structure • In other words, going down the stack means going back in time

48. 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

49. Adding a Machine to the Representation • 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, the listeners are notified • Comments have been added to the code

50. 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(); • }