1 / 120

Chapter 22 State

Chapter 22 State. Summary prepared by Kirk Scott. Kea. From Wikipedia, the free encyclopedia Jump to: navigation , search For other uses, see Kea (disambiguation) .

dora
Download Presentation

Chapter 22 State

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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]

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

  5. 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

  19. 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?”

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

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

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

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

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

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

  26. 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; • … • }

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

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

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

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

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

  32. 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. */

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

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

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

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

  37. 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()

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

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

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

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

More Related