Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2013/oss E805 kkn

2013-10-31T04:29:15Z

Pshegde: /* Problem Inference and Motivation */

== Introduction ==
Expertiza<ref name="expertiza>''Expertiza'' Retrieved from http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. The Expertiza project is software to create reusable learning objects through peer review. It also supports team projects, and the submission of almost any document type, including URLs and wiki pages. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

This wiki provides an insight into our contributions to the Open Source Software project Expertiza with main focus on the UI changes for reporting scores. Reporting score functionality is handled by controllers/grades_controller.rb and rendered by views/grades/_view_my_score.html.erb. Improved User Interface using JQuery is our contribution to Expertiza. This new elegant UI uses tabs instead of tables which makes it look elegant and renders faster. Subtle code and design challenges, changes and the motivation to implement this design have been explained further.

== Project Description ==
The view_my_scores html.erb page is being slow-rendered. The page displays all the scores in a tabular form with reviews, metareviews, author feedback below each other. Everything is merged into one big html page, and this makes the view rendering a slow process. Also, the user interface is not aesthetically pleasing. The challenge here is to make appropriate changes to the views so that the rendering time becomes less as well as to improve the over-all look and feel of the score report page.

Classes: grades_controller.rb (241 lines), and probably other classes used by this
What it does: This class is responsible for displaying grades to students (via view_my_scores) and
instructors (via the view method).

===What needs to be done:===
* This code is very slow, due to many factors. Two of the most prominent are the fact that separate
db queries are used for each rubric that has been filled out by anyone associated with the
assignment; these queries are made sequentially while the HTML page is being written; and the
fact that HTML for the whole page is generated, largely by controller methods, before anything is
displayed. This project deals with the second of these concerns.

* Move as much html as possible from the controllers into the views. Logic should be handled by
the controllers/models, and the views should simply access those variables set by the controller.
HTML should be in html.erb files, not written by controller files.

* Rather than write HTML for displaying all of the reviews on a single page, only the summary
information for each student and team should be written. This should work more like the Review
Report that an instructor can view (see review_mapping_controller.rb). This shows each review
in a popup when the user clicks on a particular review. You don’t need to use a popup; the
review could be populated on the current page when a user clicks on “Show reviews”.

===Problem Inference and Motivation===
*Currently the view_my_scores html.erb page displays all the scores in a tabular form with reviews,metareviews,author feedback below each other. Everything is merged into one big html page, and thus makes the view rendering a slow process. Also it’s a very bad user interface design.
[[File:scr1.png]]

*When a user clicks on show reviews/metareviews,etc the reviews gets rendered below each other which is too taxing for a student to scroll all the way down to read a particular review.
[[File:scr2.png]]

*This bad User Interface design along with very slow view rendering process motivated us to design an elegant interface which is user friendly and well as fast. This prompted us to use JQuery tabs.

== Design ==
We have implemented partial rendering for the HTML page. The tabs are created using JQuery. The advantage of using JQuery is that it enables a sleeker and cleaner interface on pages without requiring the page to be loaded all at once. The new view page is visually aesthetic as it separates the scoring tabs as well as the review tabs and each review is rendered only when the tab for that review is clicked on. Thereby this approach overcomes the previous issue of the entire page being rendered at once.

==Initial User Interface to view scores==
Previously,the view_my_scores html.erb page displayed all the scores in a tabular form with reviews, metareviews, author feedback below each other. Everything is merged into one big html page, and thus makes the view rendering a slow process. Also it’s a very bad user interface
design.

When a user clicks on show reviews/metareviews,etc the reviews gets rendered below each other

==Modified User Interface to view scores and reviews in tabs==

The new user interface separates the code into various tabs for reporting the scores and also a tab format for displaying reviews.
==Code Changes==
Score for <%= @assignment.name%>
<TABLE class="grades">
<%= render :partial => 'grades/participant_title', :locals => {:prefix => nil} %>
<%= render :partial => 'grades/participant', :locals => {:prefix => 'user', :team => false, :pscore=>@participant.get_scores(@questions)} %>
</TABLE>

We have now refactored the code such that the _participant.html.erb partial includes other partials.Each of these partials corresponds to a tab in the view-my-scores page.

<div id="tabs">
<ul>
<li id="tab1"><a href="#tabs-11">Submitted Work</a></li>
<li id="tab2"><a href="#tabs-12">Reviewing</a></li>
<li id="tab3"><a href="#tabs-13">Author Feedback</a></li>
<li id="tab4"><a href="#tabs-14">TeamMate Review</a></li>
</ul>
<div id="tabs-11">
<%= render :partial => 'grades/submittedwork', :locals => {:prefix => 'user', :team => false, :pscore => @participant.get_scores(@questions)} %> 
</div>
<div id="tabs-12">
<%= render :partial => 'grades/meta', :locals => {:prefix => 'user', :team => false, :pscore => @participant.get_scores(@questions)} %>
</div>
<div id="tabs-13">
<%= render :partial => 'grades/author',:locals => {:prefix => 'user', :team => false, :pscore => @participant.get_scores(@questions)} %>
</div>
<div id="tabs-14">
<%= render :partial => 'grades/teammate',:locals => {:prefix => 'user', :team => false, :pscore => @participant.get_scores(@questions)} %>
</div>
</div>
<script>
jQuery(document).ready(function () {
jQuery("#tabs").tabs();
});
</script>

==Testing the new User Interface==
Rails makes it super easy to write your tests. It starts by producing skeleton test code while you are creating your models and controllers. By simply running your Rails tests you can ensure your code adheres to the desired functionality even after some major code refactoring. Rails tests can also simulate browser requests and thus you can test your application's response without having to test it through your browser.

===Testing with Cucumber===
Cucumber<ref name="cucumber">''Cucumber'' Retrieved from https://github.com/cucumber/cucumber-rails</ref> is a high-level testing framework. It is used commonly to perform various integration tests. We used Cucumber to test our new tabbed user interface. Cucumber is used extensively in Expertiza. It constitutes some of the main test cases. All cucumber test scenarios are under Features.

===View My Score Test===
To test the improved user interface, we had to modify already existing test scenario with the following modifications.

Feature: View scores for an assignment
In order to view resulting scores
As a student

@wip
Scenario: View my submitted work scores
Given I am logged in as a student
And I move to the "Assignments" page
And I click the "test_Metareview" link
And I click the "Your scores" link
And I have a work review with score of "85"
And I have a work review with score of "66"
And I have a work review with score of "99"
When I click the "show reviews" link
Then I should see the three reviews for my submitted work with corresponding scores

@wip
Scenario: View my author feedback scores
Given I am logged in as a student
And I move to the "Assignments" page
And I click the "test_Metareview" link
And I click the "Your scores" link
And I have a feedback review with score of "93"
When I click the "show author feedbacks" link
Then I should see the author feedback review with corresponding score

@wip
Scenario: View my teammate review scores
Given I am logged in as a student
And I move to the "Assignments" page
And I click the "test_Metareview" link
And I click the "Your scores" link
And I have a teammate review with score of "100"
And I have a teammate review with score of "100"
When I click the "show teammate reviews" link
Then I should see the two teammate reviews with corresponding scores

==Future Work==
In the current implementation of the model separate DB queries are made sequentially while the HTML page is being written. This increases the loading time of the page. Hence to make views faster, models and methods should be re-factored too.

* Merge this project with [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/oss_E804_spb e804] which deals with an efficient way to query DB models to return scores,without UI changes. This will make the review rendering process fast.
* View_my_Score method in the controller saves the questionnaire in a hashmap. It needs re-factoring to make it optimal.
* Total score tab needs to be displayed either to the right or left or remaining tabs.

==References==
<references/>

File:Scr1.png

2013-10-31T04:25:54Z

Pshegde: New file

New file

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-11-03T20:14:16Z

Pshegde: /* Structure */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.
We can use state pattern to implement this example with two states state ZERO and state ONE. There are two input signals input_zero and input_one.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concrete states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==
The State Pattern implementation using Ruby for the same bulb scenario mentioned above is seen below.

#Module State contains methods to initialize states, delete states, check whether a state exists and a method for transitions of the states.
#This module is included by Context class which acts as finite state machine for this example.
#Input signal for each state is the 'turnswitch' method. For each state, turnswitch method is defined in the Context class.
#When the turnswitch method for any context is called, turnswitch method for the current state is executed.
#Context class also includes a method reset which resets the current context into Off state.

[http://rightfootin.blogspot.com/2006/08/implementing-state-pattern-in-ruby.html]

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is as seen below.

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
offstate 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://rightfootin.blogspot.com/2006/08/implementing-state-pattern-in-ruby.html Ruby Implementation of Bulb Example]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-11-01T00:09:15Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.
We can use state pattern to implement this example with two states state ZERO and state ONE. There are two input signals input_zero and input_one.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==
The State Pattern implementation using Ruby for the same bulb scenario mentioned above is seen below.

#Module State contains methods to initialize states, delete states, check whether a state exists and a method for transitions of the states.
#This module is included by Context class which acts as finite state machine for this example.
#Input signal for each state is the 'turnswitch' method. For each state, turnswitch method is defined in the Context class.
#When the turnswitch method for any context is called, turnswitch method for the current state is executed.
#Context class also includes a method reset which resets the current context into Off state.

[http://rightfootin.blogspot.com/2006/08/implementing-state-pattern-in-ruby.html]

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is as seen below.

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
offstate 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://rightfootin.blogspot.com/2006/08/implementing-state-pattern-in-ruby.html Ruby Implementation of Bulb Example]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:18:56Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is as seen below.

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
offstate 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:18:37Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
offstate 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:18:23Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
: offstate 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:18:02Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
<ignore>:offstate</ignore> 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:12:56Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
\:offstate 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:12:34Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # start the bulb state:dimstate
c.turnswitch # change to state:normalstate
c.turnswitch # change to state:offstate
c.reset # reseting outside a state changes to state:offstate
p c.state # print current state

The output for the above is

starting the bulb 
turning to normal 
switch off the bulb 
resetting outside a state 
:offstate 

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:10:41Z

Pshegde: /* A Possible Java Implementation */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Inefficient Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected
c.reset # reseting outside a state
p c.state # print current state

The output for the above is

starting the bulb
turning to normal
switch off the bulb
resetting outside a state
:offstate

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

File:Fsm correct.png

2012-10-31T23:09:12Z

Pshegde:

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:09:00Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected
c.reset # reseting outside a state
p c.state # print current state

The output for the above is

starting the bulb
turning to normal
switch off the bulb
resetting outside a state
:offstate

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ONE. 

2. If system is initially in state ONE: 
-If the input message is 0, state does not change. 
-If the input message is 1, system goes into state ZERO. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("New state : ONE");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper){
System.out.println("New state : ZERO");
wrapper.set_state(new Zero());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
New state : One

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

File:Fsm xor correct.png

2012-10-31T23:07:26Z

Pshegde: uploaded a new version of "File:Fsm xor correct.png"

File:Fsm xor correct.png

2012-10-31T23:06:48Z

Pshegde: uploaded a new version of "File:Fsm xor correct.png"

File:Fsm xor correct.png

2012-10-31T23:01:33Z

Pshegde:

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T23:01:19Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected
c.reset # reseting outside a state
p c.state # print current state

The output for the above is

starting the bulb
turning to normal
switch off the bulb
resetting outside a state
:offstate

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_correct.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("current state is zero");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("changing the state to one");
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("changing the state to zero");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
System.out.println("current state is one");
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
changing the state to one

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:53:18Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end
########
class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}
state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}
state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}
end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end
c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected
c.reset # reseting outside a state
p c.state # print current state

The output for the above is

starting the bulb
turning to normal
switch off the bulb
resetting outside a state
:offstate

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
System.out.println("current state is zero");
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
System.out.println("changing the state to one");
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
System.out.println("changing the state to zero");
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
System.out.println("current state is one");
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 1; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

The output for the above program is,
changing the state to one

Thus from the initial state zero on the action input_one, the current state changes to one.

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:46:25Z

Pshegde: /* Java Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state. 
change to normal state. 
change to bright state. 
change to off state. 

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end

########

class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}

state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}

state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}

end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end

c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected

c.reset # reseting outside a state
p c.state # print current state

The output for the above is

starting the bulb
turning to normal
switch off the bulb
resetting outside a state
:offstate

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:46:06Z

Pshegde: /* Java Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

The output for the above program is:

change to dim state.
change to normal state.
change to bright state.
change to off state.

and so on till the program terminates.

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end

########

class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}

state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}

state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}

end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end

c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected

c.reset # reseting outside a state
p c.state # print current state

The output for the above is

starting the bulb
turning to normal
switch off the bulb
resetting outside a state
:offstate

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:43:39Z

Pshegde: /* Ruby Implementation Using State Pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end

########

class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}

state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}

state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}

end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end

c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected

c.reset # reseting outside a state
p c.state # print current state

The output for the above is

starting the bulb
turning to normal
switch off the bulb
resetting outside a state
:offstate

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:39:21Z

Pshegde:

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

==Ruby Implementation Using State Pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end

########

class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}

state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}

state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}

end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end

c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected

c.reset # reseting outside a state
p c.state # print current state

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:38:32Z

Pshegde:

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

==Ruby Implementation using the state pattern==

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end

########

class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}

state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}

state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}

end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end

c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected

c.reset # reseting outside a state
p c.state # print current state

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:37:58Z

Pshegde:

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Ruby Implementation using the state pattern=

module State
class StateInitError < Exception; end
class StateSetError < Exception; end
def with_key(key, ex, &b)
if (@s_states.has_key?(key))
yield b
else
raise(ex, "No such state `#{key}'", caller)
end
end
def accept_states(*states)
@s_states = {}
@s_initial = @s_current = states[0]
states.each { |s| @s_states[s] = nil }
end
def reject_states(*states)
states.each { |s|
@s_states.delete(s)
if (@s_current == s)
if (@s_initial == s)
@s_current = nil
else
@s_current = @s_initial
end
end
}
end
def transition_to(s)
with_key(s, StateSetError) {
if (@s_states[s])
@s_states[s].call
end
@s_current = s
}
end
def state(s=nil, &b)
return @s_current if (s.nil?)
with_key(s, StateInitError) {
if (block_given?)
@s_states[s] = b
if (@s_initial == s)
transition_to(s)
end
else
transition_to(s)
end
}
end
end

########

class Context
include(State)
def initialize()
accept_states(:offstate, :dimstate, :normalstate)
state(:offstate) {
def turnswitch
puts("starting the bulb")
transition_to(:dimstate)
end
}

state(:dimstate) {
def turnswitch
puts("turning to normal")
transition_to(:normalstate)
end
}

state(:normalstate) {
def turnswitch
puts("switch off the bulb")
transition_to(:offstate)
end
}

end
def reset()
puts("resetting outside a state")
transition_to(:offstate)
end
end

c = Context.new
c.turnswitch # not connected yet
c.turnswitch # connected
c.turnswitch # already connected

c.reset # reseting outside a state
p c.state # print current state

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:10:19Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 

1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:10:11Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 
1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 

2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:10:01Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE. 
1. If the system is initially in state ZERO: 
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change. 
2. If system is initially in state ONE: 
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change. 

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:09:32Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
1. If the system is initially in state ZERO:
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change.
2. If system is initially in state ONE:
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change.

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:09:13Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
#If the system is initially in state ZERO:
-If the input message is 0, system goes into state ONE. 
-If the input message is 1, state does not change.
#If system is initially in state ONE:
-If the input message is 0, system goes into state ZERO. 
-If the input message is 1, state of the system does not change.

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:08:48Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
#If the system is initially in state ZERO:
-If the input message is 0, system goes into state ONE.
-If the input message is 1, state does not change.

#If system is initially in state ONE:
-If the input message is 0, system goes into state ZERO.
-If the input message is 1, state of the system does not change.

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

The code for implementing this scenario using the state pattern is seen below.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

File:Fsm xor resize.png

2012-10-31T22:07:25Z

Pshegde:

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:07:13Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
If the system is initially in state ZERO:
if the input message is 0, system goes into state ONE.
If the input message is 1, state does not change.

If system is initially in state ONE:
if the input message is 0, system goes into state ZERO.
If the input message is 1, state of the system does not change.

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor_resize.png]]

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

File:Fsm xor.png

2012-10-31T22:05:59Z

Pshegde:

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T22:05:37Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
If the system is initially in state ZERO:
if the input message is 0, system goes into state ONE.
If the input message is 1, state does not change.

If system is initially in state ONE:
if the input message is 0, system goes into state ZERO.
If the input message is 1, state of the system does not change.

The finite state machine below describes the state transitions on performing the various actions.

[[File:fsm_xor.png]]

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}
public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}
//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}
//class for state ZERO
class Zero implements State {
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}
@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}
//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}
@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}
public class XorStateDemo {
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#[http://sourcemaking.com/behavioral_patterns Behavioural Patterns]
#[http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm Behavioural Patterns Description]
#[http://sourcemaking.com/design_patterns/state State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Bank Account]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf State Pattern Example-Post Office Protocol]
#[http://sourcemaking.com/design_patterns/state State Pattern Class Diagram]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Advantages of State Pattern]
#[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1 Limitations of State Pattern]
#[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf Strategy Pattern Description]

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:45:09Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
If the system is initially in state ZERO:
if the input message is 0, system goes into state ONE.
If the input message is 1, state does not change.

If system is initially in state ONE:
if the input message is 0, system goes into state ZERO.
If the input message is 1, state of the system does not change.

<Work in progress>
package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}

public void set_state(State s){
current_state = s;
}

public void input_zero(){
current_state.input_zero(this);
}

public void input_one(){
current_state.input_one(this);
}
}

//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}

//class for state ZERO
class Zero implements State
{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}

@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}

//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}

@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}

public class XorStateDemo
{
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:44:34Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
If the system is initially in state ZERO:
if the input message is 0, system goes into state ONE.
If the input message is 1, state does not change.

If system is initially in state ONE:
if the input message is 0, system goes into state ZERO.
If the input message is 1, state of the system does not change.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}

public void set_state(State s){
current_state = s;
}

public void input_zero(){
current_state.input_zero(this);
}

public void input_one(){
current_state.input_one(this);
}
}

//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}

//class for state ZERO
class Zero implements State
{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}

@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}

//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}

@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}

public class XorStateDemo
{
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:43:44Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
If the system is initially in state ZERO:
if the input message is 0, system goes into state ONE.
If the input message is 1, state does not change.

If system is initially in state ONE:
if the input message is 0, system goes into state ZERO.
If the input message is 1, state of the system does not change.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}

public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}

//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}

//class for state ZERO
class Zero implements State
{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}

@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}

//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}

@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}

public class XorStateDemo
{
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:43:11Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
If the system is initially in state ZERO:
if the input message is 0, system goes into state ONE.
If the input message is 1, state does not change.

If system is initially in state ONE:
if the input message is 0, system goes into state ZERO.
If the input message is 1, state of the system does not change.

package patterns;
class XOR{
private State current_state;
public XOR(){
current_state = new Zero();
}

public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}

//State base interface.
interface State{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}

//class for state ZERO
class Zero implements State
{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}

@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}

//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}

@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}

public class XorStateDemo
{
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:42:00Z

Pshegde: /* Another example in Java using the state pattern */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.

Application of the state pattern for XOR gate is as follows.

Consider two states, ZERO and ONE.
If the system is initially in state ZERO:
if the input message is 0, system goes into state ONE.
If the input message is 1, state does not change.

If system is initially in state ONE:
if the input message is 0, system goes into state ZERO.
If the input message is 1, state of the system does not change.

package patterns;

class XOR
{
private State current_state;
public XOR(){
current_state = new Zero();
}

public void set_state(State s){
current_state = s;
}
public void input_zero(){
current_state.input_zero(this);
}
public void input_one(){
current_state.input_one(this);
}
}

//State base interface.
interface State
{
void input_zero(XOR wrapper);
void input_one(XOR wrapper);
}

//class for state ZERO
class Zero implements State
{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new One());
}

@Override
public void input_one(XOR wrapper) {
wrapper.set_state(new Zero());
}
}

//class for state ONE
class One implements State{
@Override
public void input_zero(XOR wrapper){
wrapper.set_state(new Zero());
}

@Override
public void input_one(XOR wrapper){
wrapper.set_state(new One());
}
}

public class XorStateDemo
{
public static void main(String args[]){
XOR gate = new XOR();
int num = 0; //get input from user
if (num == 0)
gate.input_zero();
if (num == 1)
gate.input_one();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:27:27Z

Pshegde:

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Another example in Java using the state pattern=

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:17:26Z

Pshegde:

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=Conclusion=
The State pattern can be used to replace to replace many ifs or switch statements. Thus inconsistent states can be avoided since state changes occur using just the one state object. Code becomes more understandable and maintainable. There are a few disadvantages of using the state pattern but the advantages outweigh the disadvantages.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

File:Class resize.png

2012-10-31T05:09:21Z

Pshegde:

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:09:08Z

Pshegde: /* A Better Solution */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:class_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:04:22Z

Pshegde: /* Advantages */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:classdiagram.jpeg]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Advantages=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

File:After resize.png

2012-10-31T05:02:03Z

Pshegde:

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T05:01:52Z

Pshegde: /* Advantages */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:classdiagram.jpeg]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Advantages=
[[File:fsm_newstate.png|thumb|FSM Adding new state]]
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:after_resize.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T04:53:37Z

Pshegde: /* Advantages */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:classdiagram.jpeg]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Advantages=
[[File:fsm_newstate.png|thumb|FSM Adding new state]]
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

The finite state machine that depicts this requirement by adding a new state is as seen below.

[[File:fsm_newstate.png]]

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T04:52:00Z

Pshegde: /* A Better Solution */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==

A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

The class diagram for the way in which this scenario can be implemented using the state pattern is as seen below. 

[[File:classdiagram.jpeg]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Advantages=
[[File:fsm_newstate.png|thumb|FSM Adding new state]]
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

CSC/ECE 517 Fall 2012/ch2a 2w21 ap

2012-10-31T04:50:32Z

Pshegde: /* A Better Solution */

[http://en.wikipedia.org/wiki/Design_pattern Design patterns] are convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is to write down and catalog common interactions between objects that programmers have frequently found useful.
The design patterns are divided into creational patterns, structural patterns and behavioral patterns.

__TOC__

=Behavioral Patterns=
[http://sourcemaking.com/behavioral_patterns][http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm][http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral patterns] help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program. These patterns are concerned with interactions between the objects. The interactions between the objects should be such that they can talk to each other and still be loosely coupled. This helps in avoiding dependencies and hard-coding.

=State Pattern=
[http://sourcemaking.com/design_patterns/state]
[http://en.wikipedia.org/wiki/State_pattern State pattern] is a behavioral software design pattern where behavior of any object depends upon current state of the object. A monolithic object's behavior is a function of its state, and it must change its behavior at run-time depending on that state.
If an object has multiple states and corresponding behaviors, the class becomes too complex with numerous conditional statements if all the transitions are included as the functions of the same class. Also, it becomes difficult to incorporate more states in the same structure.

Therefore, to make the code more clean and modular, only state is included as a property of the object and behavior for each transition is encapsulated in the separate class. When an object's internal state changes, its behavior is changed dynamically. Object appears to change its class.

Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.

=Examples=
We should use the State pattern in the following scenario:
*When an object's behavior depends on its state, and it must change its behavior at run-time depending on that state
*Operations have multiple conditional statements that depend on the object's state. The State pattern puts each branch of the conditional statement in a separate class.

A few scenarios in which the state pattern can be used:
*Consider an implementation of XOR gate used in logic. XOR gate outputs 1 when both the inputs are 1 or both the inputs are 0. It outputs 0 when one input is 0 and one input is 1.
Application of state pattern for XOR gate:

Consider two states, ZERO and ONE.

If the system is initially in state ZERO: 

If the input message is 0, system goes into state ONE.

If the input message is 1, state does not change.

If system is initially in state ONE: 

If the input message is 0, system goes into state ZERO.

If the input message is 1, state of the system does not change.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A bank account can change from an open account to a closed account and back to an open account again. The behavior of the two types of accounts is different.

*A chocolate vending machine can have states like waiting for coins, has coin, sold and sold out. There are actions performed for transitioning among the states like insert coins, dispense chocolate and return coin.

*[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A simplified version of the Post Office Protocol used to download e-mail from a mail server. The code can be in states QUIT, HAVE_USER_NAME, START and AUTHORIZED and actions for transitioning between these states can be USER username, PASS password, LIST <message number>, RETR <message number> and QUIT.

=Structure=
[[File:genclass.png]]
 
[http://sourcemaking.com/design_patterns/state]
The diagram above shows the class diagram for State Pattern Implementation. There is a Context class which communicates with the outside world. This class maintains the state of the corresponding object. It can have a number of internal states. The Context class is also called as Wrapper class. An interface State defines a common interface for all the concreate states. The states all implement the same interface; thus they are interchangeable. Our code can be in one of these states at a time.

State transition logic can be defined either in the wrapper class or in each individual state subclass. If it is included in wrapper class, structure becomes static, i.e., we can’t dynamically add new states to the structure. On the other hand, if it is included in each individual class, it results in increased coupling.

=A Real Life Example=
==Scenario==
Consider an example of a bulb which works in three modes, namely, Off, dim and normal. Initially, the bulb is in off state. When we turn the switch, it glows and goes into dim state. If we turn the switch again, it goes into normal state. It again goes into off state on turning the switch.

==A Possible Java Implementation==
package patterns;
class LightStateContext {
private int currentState;
public LightStateContext() {
currentState = 0;
}
public void turnSwitch(){
if (currentState == 0){
currentState = 1;
System.out.println("change to dim state.");
} else if (currentState == 1){
currentState = 2;
System.out.println("change to normal state.");
} else if (currentState == 2){
currentState = 0;
System.out.println("change to off state.");
}
}
}
public class InefficientCodeDemo{
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true) {
context.turnSwitch();
}
}
}

The method turnSwitch acts as finite state machine for this scenario. It contains the conditional logic for state transitions. A lot of 'if else' statements make the code unnecessarily complex.
Also, to add another state for the bulb, we need to change the original LightStateContext class which makes this code inefficient and difficult to extend.

==A Better Solution==
[[File:classdiagram.jpeg|thumb|Class Diagram]]
A better solution can be provided using the state pattern. We can clearly identify the three states of the bulb, off, dim and normal. We can also formulate the logic for finite state machine.
#If light is in 'off' state and we turn the switch, resulting state is 'dim'.
#If light is in 'dim' state and we turn the switch, resulting state is 'normal'.
#If light is in 'normal' state and we turn the switch, resulting state is 'off'.

The finite state machine for the states can be seen below. 

[[File:fsm_resize.png]]

==Steps to Implement State Pattern==
#Identify the states and define values for each state (typically constants)
#Create an instance variable that holds the current state.
#Identify all the actions that can occur in the system and find out all the actions that can cause state transition.
#Create a class that acts as the state machine.
#For each state, create a class which contains system behavior for that state and implements State.

==Java Implementation Using State Pattern==
#Class LightStateContext acts as finite state machine for this example. This class contains the state variable 'currentState'. It includes the action 'turnSwitch' and a method 'setCurrentState' to set the state of the bulb when turnSwitch is called.
# State interface contains turnSwitch method which is called by the context class.
# A class is created for each individual state. These classes implement the State interface and turnSwitch method of State interface is defined by these classes.
package patterns;
class LightStateContext {
private State currentState;
public LightStateContext() {
currentState = new OffState();
}
public State getCurrentState() {
return currentState;
}
public void setCurrentState(State currentState) {
this.currentState = currentState;
}
public void turnSwitch(){
currentState.turnSwitch(this);
}
}
interface State{
void turnSwitch(LightStateContext context);
}
class OffState implements State{
@override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new DimState());
System.out.println("change to dim state.");
}
}
class DimState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new NormalState());
System.out.println("change to normal state.");
}
}
class NormalState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
public class StatePatternDemo {
public static void main(String[] args) {
LightStateContext context = new LightStateContext();
while (true)
context.turnSwitch();
}
}

=Advantages=
[[File:fsm_newstate.png|thumb|FSM Adding new state]]
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]
Advantages of the state pattern can be summarized as:
#One object for one state.
#Allows state transition logic to be be incorporated into a state object rather than in a monolithic if or switch statement.
#Helps avoid inconsistent states since state changes occur using just the one state object and not several objects or attributes.
#By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
#If the state pattern is implemented correctly, the code becomes easy to extend.

Let us assume we are asked to show that when the bulb is in the normal state and we turn the switch the bulb glows bright. To incorporate this kind of change we need to just do the following:

1. Add a new BrightState that implements the State interface

class BrightState implements State{
@Override
public void turnSwitch(LightStateContext context) {
context.setCurrentState(new OffState());
System.out.println("change to off state.");
}
}
2. In the previous state's (NormalState) turnSwitch method set the current state to BrightState

context.setCurrentState(new BrightState());

=Limitations=
[https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1]
#Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
#Becomes too heavy when Finite State Machine is not that complex.

=Strategy Pattern Vs State Pattern=
[http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf]A [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern] is another behavioral software design pattern which separates the behavioral algorithms from the object. Each algorithm is encapsulated in a different class. Depending upon the properties of the current object, decision of invoking an algorithm is taken at runtime.

The class diagrams of these two patterns are similar in structure. However, there are a few differences between these patterns.
#The patterns differ in their intent. In a strategy pattern, the client specifies the strategy object that the client is composed with. There is a strategy object that is most appropriate for the context object. For example, Two sorting algorithms (Merge Sort and Quick sort) are implemented and the client can select either of the algorithms for sorting a list. In a state pattern, we have a set of behaviors encapsulated in state objects, at any time the context is delegating to one of those states. The current state changes with every action to reflect the internal state of the context. The client usually knows very little about the state objects.
#In a strategy pattern, once a decision is made to invoke a particular algorithm, it is not possible to change it. Whereas in state pattern, transition between states occurs at runtime.
#In state pattern, decision of which state to invoke depends only on one variable.
#We can say that state pattern is a type of strategy pattern where each state represents a different behavioral algorithm for the object in context.
A class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.
A state pattern can be used for implementing a drawing program. The program has many tools like pointer, fill shape which at any point in time can act as one of several tools. Instead of switching between multiple objects, the code maintains an internal state representing the tool currently in use.

=References=

#http://sourcemaking.com/behavioral_patterns
#http://www.allapplabs.com/java_design_patterns/behavioral_patterns.htm
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#http://sourcemaking.com/design_patterns/state
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf
#https://docs.google.com/a/ncsu.edu/viewer?a=v&q=cache:UGImuHnhO8MJ:www.cs.toronto.edu/~arnold/407/06s/lectures/studentPresentations/stateStrategy/state_strat_pres.ppt+disadvantages+of+strategy+pattern&hl=en&gl=us&pid=bl&srcid=ADGEEShbX8h_8wQ7PkIoXMKwXjPgISI7dduhY-HrO8fUV8lntQw0RYYWQ-eG_hLAxTT3pjUj5j5Dj8F7-baC3D-C6Znv_YTujBdB_E6-WkZ9KMe2jWXGtZgeRtMcwEJtpqN8JNOC9itc&sig=AHIEtbSP_rpR12IcGL1KyQAhi0PGeUQqrQ&pli=1
#http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

=Further References=
#Freeman,Freeman,Bates,Sierra,Robson.''Head First Design Patterns'',2004, O'Reilly
#http://www.freetechbooks.com/the-design-patterns-java-companion-t126.html

File:Fsm resize.png

2012-10-31T04:49:43Z

Pshegde: