STATE PATTERN STRATEGY PATTERN
In-State pattern, an individual state can contain the reference of Context, to implement state transitions. But Strategies doesn’t contain the reference of Context, where they are used.
State encapsulate state of an Object. While Strategy Pattern encapsulates an algorithm or strategy.
State pattern helps a class to exhibit different behaviors in a different state. Strategy Pattern encapsulates a set of related algorithms and allows the client to use interchangeable behaviors through composition and delegation at runtime.
The state is part of the context object itself, and over time, the context object transitions from one State to another. It can be passed as a parameter to there the Object which uses them e.g. Collections.sort() accepts a Comparator, which is a strategy.
State Pattern defines the “what” and “when” part of an Object. Example: What can an object when it’s in a certain state. Strategy pattern defines the “How” part of an Object. Example: How a Sorting object sorts data.
Order of State transition is well-defined in State pattern. There is no such requirement for a Strategy pattern. The client is free to choose any Strategy implementation of his choice.
Change in State can be done by Context or State object itself. Change in Strategy is done by the Client.
Some common examples of Strategy Patterns are encapsulating algorithms e.g. sorting algorithms, encryption algorithms, or compression algorithms. On the other hand, recognizing the use of State design patterns is pretty easy.
If you see, your code needs to use different kinds of related algorithms, then think of using a Strategy pattern. If you need to manage state and state transition, without lots of nested conditional statements, state pattern is the pattern to use.