state

Document Sample
state Powered By Docstoc
					                           The State Design Pattern
                                      Aamir Siddiqui
                                   University of Scranton
                                      SE 516 – Dr Bi



Contents

    1.   Classification
    2.   Intent
    3.   In 30 Seconds
    4.   Motivation
    5.   Use
    6.   Structure
    7.   CODE example
    8.   Conclusions
    9.   Extra Help


Classification
There is one of three classifications that all design patterns fall into:

    1. Creational
    2. Structural and
    3. Behavioral.

The State Pattern is classified as a behavioral design pattern.

                                                     PURPOSE
                         Creational             Structural                  Behavioral
 Scope      Class    Factory Method          Adapter (class)         Interpreter
                                                                     Template Method
           Object Abstract Factory           Adapter (object)        Chain of Responsibility
                  Builder                    Bridge                  Command
                  Prototype                  Composite               Iterator
                  Singleton                  Decorator               Mediator
                                             Façade                  Mermento
                                             Flyweight               Observer
                                             Proxy                   State
                                                                     Strategy
                                                                     Visitor
Intent
Allow an object to alter its behavior when its internal State changes. The object will
appear to change its class.

OR

The main intention here is to manage sequence of events of same type.

ALSO

If you understand finite state machine then you already know this pattern.

In 30 Seconds
The catch here is „Implementing discrete object states using explicit classes‟. Many a
times we deal with objects, which have a number of discrete states and the object‟s
behavior depends on the flow of State transitions. It is a run time pattern meaning that it
can change its state at anytime, if the user wants to.

Motivation
The main objective of this design pattern is to efficiently handle scenarios where message
collection is involved. This involves counting the received messages and recognizing the
point where collection has been completed.

Structure




Structure of State

“Context” class:
      Represents the interface to the outside world.

“State” abstract class:
       Base class, which defines the different states of      the “state machine”.

“Derived” classes from the State class:
        Defines the true nature of the state that the state machine can be in. Context class
        maintains a pointer to the current state. To change the state of the state machine,
        the pointer needs to be changed.


Motivation
The main objective of this design pattern is to efficiently handle scenarios where message
collection is involved. This involves counting the received messages and recognizing the
point where collection has been completed.

Use

       Digit collection
       Collecting periodic sanity punch from a hardware unit.
       Collecting message segments to form a complete message. This technique is used
        in several segmentation and reassembly protocols.

CODE example

An object's getColor() method is different if the "color" property of the given object is set
to "blue" instead of "red" because getColor() returns a different value in the two
situations.

Furthermore, the object may make decisions at run time as to exactly what to do
dependent upon the values its properties possess. For instance, if the sky is blue
(sky.setColor(Color.blue)), then the sun should be visible.
public boolean sunIsVisible()
{
   if(getColor()==Color.blue)
   {
      return true;
   }
   else
   {
      return false;
   }
}


One issue with the above solution is that it is a hard-coded logic solution, not an architect
solution. The sky does not intrinsically behave a certain way if it is blue, but rather it
should figure out what to do in that situation. Wouldn't it be better if the sky intrinsically
acted properly if it were blue? One could imagine two objects: a SkyBlue and a
SkyNonBlue.
The SkyBlue class' sunIsVisible() method would always return true while the
SkyNonBlue version would always return false.

What one needs now is the ability for a sky object to dynamically (i.e. at run time)
change its class to/from SkyBlue and SkyNonBlue. What we'd like to accomplish is
called "dynamic reclassification".

We've seen code that does change its specific behavior depending on what particular
strategy was installed. So, the setColor() method could install a strategy that would
always return true if its sunIsVisible() method were to be called.


Conclusions

The State pattern is a solution to the problem of how to make behavior depend on state.

      Define a "context" class to present a single interface to the outside world.
      Define a State abstract base class.
      Represent the different "states" of the state machine as derived classes of the State
       base class.
      Define state-specific behavior in the appropriate State derived classes.
      Maintain a pointer to the current "state" in the "context" class.
      To change the state of the state machine, change the current "state" pointer.

Extra Help

                      http://ootips.org/state-pattern.html

				
DOCUMENT INFO