What is the difference between Strategy design pattern and State design pattern?
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 difference clearly.
Can someone please explain the difference in layman's terms?
Solution 1:
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.
Solution 2:
- The Strategy pattern is really about having a different implementation that accomplishes (basically) the same thing, so that one implementation can replace the other as the strategy requires. For example, you might have different sorting algorithms in a strategy pattern. The callers to the object does not change based on which strategy is being employed, but regardless of strategy the goal is the same (sort the collection).
- The State pattern is about doing different things based on the
state, while leaving the caller relieved from the burden of
accommodating every possible state. So for example you might have a
getStatus()method that will return different statuses based on the state of the object, but the caller of the method doesn't have to be coded differently to account for each potential state.
Solution 3:
The difference simply lies in that they solve different problems:
- The State pattern deals with what (state or type) an object is (in) -- it encapsulates state-dependent behavior, whereas
- the Strategy pattern deals with how an object performs a certain task -- it encapsulates an algorithm.
The constructs for achieving these different goals are however very similar; both patterns are examples of composition with delegation.
Some observations on their advantages:
By using the State pattern the state-holding (context) class is relieved from knowledge of what state or type it is and what states or types that are available. This means that the class adheres to the open-closed design principle (OCP): the class is closed for changes in what states/types there are, but the states/types are open to extensions.
By using the Strategy pattern the algorithm-using (context) class is relieved from knowledge of how to perform a certain task (-- the "algorithm"). This case also creates an adherence to the OCP; the class is closed for changes regarding how to perform this task, but the design is very open to additions of other algorithms for solving this task.
This likely also improves the context class' adherence to the single responsibility principle (SRP). Further the algorithm becomes easily available for reuse by other classes.