Chapter 22 State

1. Chapter 22State Summary prepared by Kirk Scott

2. Kea • From Wikipedia, the free encyclopedia • Jump to: navigation, search • For other uses, see Kea (disambiguation).

3. The Kea (/ˈkiː.ə/; Māori: [kɛ.a]; Nestor notabilis) is a large species of parrot (superfamily Strigopoidea) found in forested and alpine regions of the South Island of New Zealand. About 48 cm (19 in) long, it is mostly olive-green with a brilliant orange under its wings and has a large, narrow, curved, grey-brown upper beak. The Kea is the world's only alpine parrot. Its omnivorous diet includes carrion,[2] but consists mainly of roots, leaves, berries, nectar, and insects. Now uncommon, the Kea was once killed for bounty due to concerns by the sheep-farming community that it attacked livestock, especially sheep.[3] It received full protection only in 1986.[4]

11. Design Patterns in JavaChapter 22State Summary prepared by Kirk Scott

12. In reference to an object, the term state can mean the particular set of values of its instance variables at a given time • More broadly, for a system, the term state can refer to the collective states of the objects existing in the system at a given time • In a more focused sense, state may refer to the value of a single, critical instance variable in an object (or system)

13. Not surprisingly, if the value of an instance variable is of interest, changes in the value are also of interest • In an object-oriented system, the state changes as a result of calls to methods—as a result of the logic of code in methods • The current state may be critical to how methods act

14. In other words, methods of a class with some critical state characteristic may contain if statements • If the state is x, the method does y; if the state is q, the method does r, and so on • If this kind of code appears in multiple methods, changes in the logic of state handling can lead to a maintenance burden

15. A possible solution, the topic of this chapter, is to model state separately • In other words, let state be represented by an object, not a single, simple instance variable or set of variables • The goal is to move the if/then/else logic out of multiple methods in the domain classes, and into a single method in the state class

16. Book definition: • The intent of the State pattern is to distribute state-specific logic across classes that represent an object’s state

17. Comment mode on: • Although the book uses the term “distribute”, keep in mind that the overall goal, and saving, is that the state-specific logic will occur fewer times in the new model than in the old model • Or particular bits of that logic will occur only once, in one state method, rather than many times, in several different domain methods

18. Modeling States • The book summarizes this idea with this nice, object-oriented sounding phrase: • The goal of the new model is to encapsulate state-specific logic in separate, state-related classes and methods • As with many of the patterns already, the book illustrates this by giving a software design without state classes and then refactoring it using the State design pattern

19. Example • The book’s example is based on a physical device that might occur in a fireworks factory setting • The device is known as a carousel • The carousel is a circulating storage rack which is enclosed and is accessed through a doorway • The doorway is controlled with a button • It is the doorway, and its state, and how the button works that are of particular interest

20. The functioning of the doorway and button can be summarized verbally as stated on the following overheads • (This is a slightly more complete verbal summary than that given in the book.) • Notice that this basically just describes a glorified garage door opener with additional functionality

21. 1. If the doorway is closed, touching the button once will cause it to start opening • 2. If the doorway is opening, touching the button (again) will cause it to start closing • 3. If the door is open, it will stay open for 2 seconds and then automatically start closing

22. 4. If the door is open and the button is touched during the 2 second interval, this will cause the doorway to stay open • 5. If the door is open and the button has been touched to keep it open, touching the button again will cause it to start closing • 6. If the doorway is closing, touching the button will cause it to start opening

23. If you analyze the situation, you find at least 4 states for the door: open, opening, closing, closed • It turns out that given the actions, in a complete analysis there will also be a fifth state: stay open • There are also transitions between states triggered by either touching the button or not touching the button

24. State (Transition) Diagram • In situations like this, it is usually easiest to understand what’s going on with a diagram rather than a verbal description • On the overhead following the next one a state transition diagram is given for the carousel • Incidentally, this kind of diagram is part of UML

25. States are given as boxes with rounded corners • Transitions are given as arrows, labeled with the action (or inaction) that triggers them

27. Challenge 22.1 • “Suppose that you open the door and place a material bin in the doorway. Is there a way to make the door begin closing without waiting for it to time out?”

28. Solution 22.1 • [This is not the way the book answers it.] • In a state transition diagram you can easily look for a path from one state to another • Find the sequence of actions necessary to follow that path • In this case, click the button twice

29. Non-State Pattern Design • The book first gives a design that doesn’t use the State design pattern • Implicit in this design is a carousel machine • The carousel will have an instance of a Door class • Even though the design doesn’t use the pattern, by its nature, the door has a state

30. The Door class will have an int instance variable holding state • The class will have methods that affect the state • The code for the carousel class would contain calls to the door methods

31. Incidentally, the Door class will extend the Observable class • This makes it suitable for use in a graphical application with listeners • This graphical aspect of the example is not central to the state design pattern • The Observer pattern is covered in a different unit

32. A simple UML diagram of the Door and Observer classes is shown on the following overhead • Note this about the example: • It is like many of the preceding examples • In essence, we are being given a monolithic design • The redesign will involve separating state logic out of the one class shown, Door

34. State Definition Code for the Door Class • On the next overhead the beginning part of the Door class is given • The different states are defined as integer constants • The state of a door is recorded by assigning a value to its integer instance variable, state • Notice this evil fact: • The authors have declared the state instance variable public

35. public class Door extends Observable • { • public final int CLOSED = -1; • public final int OPENING = -2; • public final int OPEN = -3; • public final int CLOSING = -4; • public final int STAYOPEN = -5; • public int state = CLOSED; • … • }

36. status() Method Code for the Door Class • The Door class will have a status() method • This is sort of a combination get/toString() method • It doesn’t take an input parameter • It returns the current state of a door • However, it doesn’t return a numerical value

37. The status() method returns a String which describes the current state • This requires the use of conditional logic • The book uses a switch statement for this • I would prefer nested ifs • The code for this is given on the next overhead

38. public String status() • { • switch(state) • { • case OPENING: • return “Opening”; • case OPEN: • return “Open”; • case CLOSING: • return “Closing”; • case STAYOPEN: • return “StayOpen”; • default: • return “Closed”; • } • }

39. touch() Method Code for the Door Class • The Door class will have a touch() method • This contains some of the fundamental logic for the class • The method doesn’t take an input parameter • Calling the touch() method causes the state of the door to change

40. What state the door transitions to depends on what state the door is currently in • This is the classic situation for a transition • This requires the use of conditional logic • Once again, the book uses a switch statement, which I do not prefer • The code is given on the next overhead

41. public void touch() • { • switch(state) • { • case OPENING: • case STAYOPEN: • setState(CLOSING); • break; • case CLOSING: • case CLOSED: • setState(OPENING); • break; • case OPEN: • setState(STAYOPEN); • break; • default: • throw new Error(“Can’t happen.”); • } • } • /* Whoops! The book forgot to declare at the top that the method throws an exception. */

42. Consider the cases in the statement • A simpler implementation would contain assignments of this form: • state = SOME STATE VALUE • Instead, this implementation calls the setState() method • The explanation follows

43. setState() Method Code for the Door Class • The setState() method does two things: • It updates the value of state • It also makes calls to these methods: • setChanged() and notifyObservers() • These methods are inherited from the Observable class, which the Door class extends

44. The calls to the observable methods are needed to support the fact that the door is observable • The book’s example doesn’t include client code, like a Carousel class, so observability is simply a sideshow in this example • We don’t actually get to see how it is used • The code for the setState() method is given on the next overhead

45. private void setState(int state) • { • this.state = state; • setChanged(); • notifyObservers(); • }

46. Code for Other Methods in the Door Class • The foregoing overheads described the infrastructure in the Door class • They also covered one of the methods containing fundamental state transition logic, the touch() method • There are two other methods that do state transitions, complete() and timeout()

47. Challenge 22.2 • Write the code for the complete() and timeout() methods of the Door class

48. Solution 22.2 • Your code should look something like: • [See following overhead]

49. public void complete() • { • if(state == OPENING) • setState(OPEN); • else if(state == CLOSING) • setState(CLOSED); • } • public void timeout() • { • setState(CLOSING); • }

50. Refactoring to State • Strictly speaking, the original design isn’t bad • The state is accessible to all of the methods of the Door class by virtue of the fact that it is implemented as an instance variable • In effect, state serves as a global variable within the Door class