• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

difference between state and strategy design pattern

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can someone explain me the difference between the state and strategy design pattern. Thanks in advance.

Murali
 
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The state and strategy patterns are similar in the sense that both of them encapsulate behavior in separate objects and use composition to delegate to the composed object to implement the behavior and both of them provide the flexibility to change the behavior dynamically by changing the composed object at run-time. But there are some key differences :

1. In the state pattern, the client knows nothing about the state objects. State changes happen transparently to the client. The client just calls methods on the context, the context oversees its own state. Because the client is not aware of the state changes, it appears to the client as though the context is instantiated from a different class each time there is a change in behavior due to a state change. The object will appear to change its class as the official definition of the pattern states. The pattern is built around a well-defined series of state transitions. Changing state is key to the pattern's existence.

2. Even though the strategy pattern provides the flexibility to change behavior by changing the composed strategy object dynamically, mostly there is an appropriate strategy object already set for each context. ie even though the pattern provides a way to change the composed strategy object dynamically, there won't be much of a need for it. Even if it has to be done, it is the client that does the change. The client will call the setter method on the context and pass the new strategy object. Thus behavior changes are NOT transparent to the client and are initiated and controlled by the client. The pattern does not encourage a series of well-defined behavior changes like the state pattern. The client knows about the strategy objects and will usually set the appropriate strategy object in the context while creating it. The client controls what strategy object the context uses, but in the state pattern, the client knows nothing about the state object(s) that the context uses
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Both are different pattern usage.
1) State Pattern: All people know about the state flow diagram. how it's work based on the condition it will go one state to another state.
State Pattern means flow of states.
I am giving below examples, it will clear when to go for state pattern and when to go for strategy pattern.
public abstract class Sort {
public abstract void sortAlgorithm();
}
public class MergeSort extends Sort {
public void sortAlgorithm(){
System.out.println("MergeSorting...");
}
}
public class QuickSort extends Sort {
public void sortAlgorithm(){
System.out.println("QuickSorting...");
}
}
public class BubbleSort extends Sort{
public void sortAlgorithm(){
System.out.println("BubbleSorting...");
}
}

In the above example, we have Sort abstract class is there BubbleSort,MergeSort,QuickSort are extending that Sort.
StatePattern: My scenario is if(i==1) then BubbleSort state,if(i==2) then MergeSort state,if(i==3) then QuickSort state. my flow of states are defined like that.
public class Context {

private Sort state;

private Sort quickSort;
private Sort mergeSort;
private Sort bubbleSort;

public Context(){
quickSort = new QuickSort();
mergeSort = new MergeSort();
bubbleSort = new BubbleSort();

}

public void startWorkflow(int i){

if(i==1){
state = bubbleSort;
state.sortAlgorithm();
i=2;
}

if(i==2){
state = mergeSort;
state.sortAlgorithm();
i=3;
}

if(i==3){
state = quickSort;
state.sortAlgorithm();

}

}
}
public class StateTest {

public static void main(String args[]){

Context ctx = new Context();
ctx.startWorkflow(1);

}

}

State Patter:"Allow an object to alter its behavior when its internal state changes",

Explanation: Here in this example Context Internal state is Sort state, based on the if condition state is getting changes, Context object behaviour (startWorkflow) changes means getting different outputs.
Output:
/* output
BubbleSorting...
MergeSorting...
QuickSorting...

Strategy Design Pattern: Scenario is I want to choose any algorithm based on the client choice.
public class Context {
private Sort state;
public Context(Sort state){

this.state = state;
}
public void sortFromContext(){
state.sortAlgorithm();
}
}
public class StrategyTest {
public static void main(String args[]){
Context ctx = new Context(new QuickSort());
ctx.sortFromContext();
}
}
output:
QuickSorting...
Strategy Principle:"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it."

Explanation: In abstract class we define one algorithm. Each one of the specified classes would usually encapsulate an algorithm, switching between classes would switch the used algorithm and thus change the behaviour of the application.

*****Difference between State and Strategy Pattern************
In Strategy pattern, Assume one base class is there, 10 subclasses extends/implements that base class. Client will choose any one of them as strategy.Means client should explicity mention which class he is going to use.
client will any one out of n subclasses .

In State Pattern main purpose state flow like 1 -> 2 ->4->3 based on the condition. **client will not choose any of them.State Pattern main purpose flow of state it's like our state flow diagram.

Hope it's clear the concept of state vs strategy.

Regards,
Ramesh V








 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ramesh

its very useful post. and it is very clear to understand..

thanks for posting this.....
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ramesh,

Thanks for clear clarification ... !!

Regards,
Thulasi Prasad
 
Farmers know to never drive a tractor near a honey locust tree. But a tiny ad is okay:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic