CSC/ECE 517 Fall 2012/ch2a 2w21 ap: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Created page with "The State 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 ...")
 
No edit summary
Line 1: Line 1:
The State pattern
=The State 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.
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, structural and behavioral.
The design patterns are divided into creational, structural and behavioral.


BEHAVIOURAL SOFTWARE DESIGN PATTERNS:
=Behavioral Patterns=
These 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 help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program.


STATE PATTERN:
=State Pattern=
State pattern is a behavioural software design pattern where behaviour of any object depends upon current state of the object.  
State pattern is a behavioral software design pattern where behavior of any object depends upon current state of the object.  


If an object has multiple states and corresponding behaviours, 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.
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 behaviour for each transition is encapsulated in the separate class. When the object’s internal state changes, its behaviour is changed dynamically. Object appears to change its class.
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 the 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.
Static conditional statements are replaced by a finite state machine which decides the transition flow of the object.




STRUCTURE:
=Structure=
There is a context class which communicates with the outside world. This class maintains the state of the corresponding object. An abstract state class is defined which is then derived by individual state classes. Context class is also called as Wrapper class.
There is a context class which communicates with the outside world. This class maintains the state of the corresponding object. An abstract state class is defined which is then derived by individual state classes. Context class is also called as Wrapper class.


Line 24: Line 24:
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, coupling increases.
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, coupling increases.


 
=Finite State Machine=
 
FINITE STATE MACHINE:
There are two approaches which are commonly used:
There are two approaches which are commonly used:
1. Table based approach:
1. Table based approach:
Line 36: Line 34:




EXAMPLE:
=Example=
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.
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:
Application of state pattern for XOR gate:
Line 93: Line 91:
TODO : add
TODO : add
   
   
JAVA IMPLEMENTATION using state pattern:
=A Java implementation using the state pattern=


We go about implementing the state pattern in the following way:
We go about implementing the state pattern in the following way:
Line 172: Line 170:
}
}


ADVANTAGES:
=Advantages=
Advantages of the state pattern can be summarized as:
Advantages of the state pattern can be summarized as:
1.  One object for one state. By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
1.  One object for one state. By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code.
Line 179: Line 177:
Let us consider that we have to add  
Let us consider that we have to add  


LIMITATIONS:
=Limitations=
1. Too many objects are created. This is a price that we need to pay for better flexibility and maintainablility.
1. Too many objects are created. This is a price that we need to pay for better flexibility and maintainability.
2. Becomes too heavy when Finite State Machine is not that complex.  
2. Becomes too heavy when Finite State Machine is not that complex.  


STATE PATTERN Vs STRATEGY PATTERN:
=State Pattern Vs Strategy Pattern=
Strategy pattern is another behavioural software design pattern which separates the behavioural 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.
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.


Main difference between the state pattern and strategy pattern is in 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.
Main difference between the state pattern and strategy pattern is in 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.
Line 190: Line 188:
  In state pattern, decision of which state to invoke depends only on one variable.  
  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 difference behavioural algorithm for the object in context.
We can say that state pattern is a type of strategy pattern where each state represents a difference behavioral algorithm for the object in context.


References:
=References=

Revision as of 01:59, 25 October 2012

The State 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, structural and behavioral.

Behavioral Patterns

These patterns help you to define the communication between objects in your system and also specify how the flow is controlled in a complex program.

State Pattern

State pattern is a behavioral software design pattern where behavior of any object depends upon current state of the object.

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


Structure

There is a context class which communicates with the outside world. This class maintains the state of the corresponding object. An abstract state class is defined which is then derived by individual state classes. Context class is also called as Wrapper class.

//class diagram:

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, coupling increases.

Finite State Machine

There are two approaches which are commonly used: 1. Table based approach: This approach lists all the transitions as a function of the current state and input message. This approach works well when finite state machine is not too complex. 2. Pattern based approach: In this approach, a conditional logic is used for transitions.

//Diagram:


Example

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.

//FINITE STATE MACHINE diagram FOR THIS EXAMPLE:


An inefficient Java implementation: class XOR { int current_state; public XOR() { current_state = new zero(); } public void input_zero() { if(current_state == 0) current_state = 1; if(current_state == 1) current_state = 0;

} public void input_one() { if(current_state == 1) current_state = 1; if(current_state == 0) current_state = 0;

} }

public class DEMO { public static void main(String args[]) { XOR gate = new XOR(); INPUT num; if (num == 0) gate.input_zero(); if (num == 1) gate.input_one(); } }

Why is this implementation inefficient? TODO : add

A Java implementation using the state pattern

We go about implementing the state pattern in the following way: 1. Identify the states and define values for each state (typically constants) 2. Create an instance variable that holds the current state. 3. Identify all the actions that can occur in the system and find out all the actions that can cause state transition. 4. Create a class that acts as the state machine. 5. For each action, create a method that uses conditional statements to determine what behavior is appropriate in each state. You can also transition to another state in the conditional statement.

Let us see an example that shows an efficient implementation using the state pattern.


//This class is a wrapper class which delegates the input message to corresponding state class. 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 { public void input_zero(XOR wrapper) { wrapper.set_state(new ONE()); } public void input_one(XOR wrapper) { wrapper.set_state(new ZERO()); }

} //class for state ONE class ONE implements state { public void input_zero(XOR wrapper) { wrapper.set_state(new ZERO()); } public void input_one(XOR wrapper) { wrapper.set_state(new ONE()); }

}

public class DEMO { public static void main(String args[]) { XOR gate = new XOR(); INPUT num; if (num == 0) gate.input_zero(); if (num == 1) gate.input_one(); } }

Advantages

Advantages of the state pattern can be summarized as: 1. One object for one state. By using objects we can make the states explicit and reduce the effort needed to understand and maintain the code. 2. Easy to entend

Let us consider that we have to add

Limitations

1. Too many objects are created. This is a price that we need to pay for better flexibility and maintainability. 2. Becomes too heavy when Finite State Machine is not that complex.

State Pattern Vs 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.

Main difference between the state pattern and strategy pattern is in 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 difference behavioral algorithm for the object in context.

References