What is the difference between Strategy design pattern and State design pattern?

Question

What are the differences between the Strategy design pattern and the State design pattern? I was going through quite a few articles on the web but could not make out the dif

Answer 1

State comes with a little bit dependencies within the state derived classes: like one state knows about other states coming after it. For example, Summer comes after winter for any season state, or Delivery state after the Deposit state for shopping.

On the other hand, Strategy has no dependencies like these. Here, any kind of state can be initialized based on the program/product type.

Answer 2

Both patterns delegate to a base class that has several derivative, but it's only in the State pattern that these derivative classes hold a reference back to context class.

Another way to look at it is that the Strategy pattern is a simpler version of the State pattern; a sub-pattern, if you like. It really depends if you want the derived states to hold references back to the context or not (i.e: do you want them to call methods on the context).

For more info: Robert C Martin (& Micah Martin) answer this in their book, "Agile Principles, Patterns and Practices in C#". (http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258)

Answer 3

Consider an IVR (Interactive Voice Response) system handling customer calls. You may want to program it to handle customers on:

• Work days
• Holidays

To handle this situation you can use a State Pattern.

• Holiday: IVR simply responds saying that 'Calls can be taken only on working days between 9am to 5pm'.
• Work days: it responds by connecting the customer to a customer care executive.

---

This process of connecting a customer to a support executive can itself be implemented using a Strategy Pattern where the executives are picked based on either of:

• Round Robin
• Least Recently Used
• Other priority based algorithms

The strategy pattern decides on 'how' to perform some action and state pattern decides on 'when' to perform them.

Answer 4

Honestly, the two patterns are pretty similar in practice, and the defining difference between them tends to vary depending on who you ask. Some popular choices are:

• States store a reference to the context object that contains them. Strategies do not.
• States are allowed to replace themselves (IE: to change the state of the context object to something else), while Strategies are not.
• Strategies are passed to the context object as parameters, while States are created by the context object itself.
• Strategies only handle a single, specific task, while States provide the underlying implementation for everything (or most everything) the context object does.

A "classic" implementation would match either State or Strategy for every item on the list, but you do run across hybrids that have mixes of both. Whether a particular one is more State-y or Strategy-y is ultimately a subjective question.

Answer 5

When you have a project which can be divided into 2 tasks:

task 1: you can use one of two different algorithms to accomplish: alg1, alg2

task 2: you can use one of three different algorithms to accomplish: alg3, alg4, alg5

alg1 and alg2 are interchangeable; alg3, alg4 and alg5 are interchangeable.

Choosing which algorithm to perform in task 1 and task 2 depends on states:

state 1: you need alg1 in task 1 and alg3 in task 2

state 2: you need alg2 in task 1 and alg5 in task 2

You context can change state object from state 1 to state 2. Then your task would be accomplished by alg2 and alg5, instead of alg1 and alg3.

You can add more interchangeable algorithms for task 1 or task 2. This is strategy pattern.

You can have more states with different combination of algorithms in task 1 and task 2. State pattern allows you to switch from one state to another and perform different combination of algorithms.

Answer 6

'Strategy' is only an algorithm that you can change it in different circumstances upon your need, and it processes something for you. Ex. you can choose how compress a file. zip or rar ... in a method.

But 'State' CAN change all your object behaviour, when it changes, Even it can change other fields... that's why it has a reference to its owner. You should notice that changing an object field can change object behaviour at all. Ex. when you change State0 to State1 in obj, you change an integer to 10.. so when we call obj.f0() that do some calculation and use that integer, it affects the result.