Difference between State and Strategy patterns in Java

In order to properly use the State and Strategy patterns in core Java applications, it is important for Java programmers to clearly understand the difference between them. Although both patterns, State and Strategy, have a similar structure, and both are based on the open/closed principle, representing the “O” in SOLID principles , they are completely different in intent . The Strategy pattern in Java is used to encapsulate related sets of algorithms to provide execution flexibility to the client. The client can choose any algorithm at runtime without changing the context of the class that uses the . Some popular examples of the Strategy pattern are writing code that uses algorithms, such as encryption, compression, or sorting. On the other hand, the State pattern allows an object to behave differently in different states. Because in the real world an object often has states, and it behaves differently in different states, for example, a vending machine only sells goods if it is in the state , it doesn't sell until you put a coin in it. Now you can clearly see the difference between the Strategy and State patterns, these are different intentions. The State pattern helps an object manage state, while the Strategy pattern allows the client to choose a different behavior. Another difference that is not so easy to see is who is driving the change in behavior. In the case of the Strategy pattern, this is a client that provides various strategies to the context; in the State pattern, the transition is controlled by the context or the state of the object itself. Additionally, if you manage state changes in the State object yourself, there must be a reference to the context, for example, a vending machine must be able to call a method to change the current state of the context. On the other hand, the Strategy object never contains a reference to the context; the client itself passes the Strategy of its choice to the context. The difference between State and Strategy patterns is one of the popular interview questions about Java patterns , in this article on Java patterns we will take a closer look at it. We will explore some similarities and differences between the Strategy and State patterns in Java that will help you improve your understanding of these patterns. StrategyhasCoinsetState()

Similarities between the State and Strategy patterns

If you look at the UML diagram of the State and Strategy patterns, you will notice that both look similar to each other. An object that uses State to change its behavior is known as Contextan -object, similarly an object that uses Strategy to change its behavior is referred to as Contextan -object. Remember that the client interacts with Contextthe -object. In the case of the State pattern, the context delegates call methods to a State object, which is held as the current object, and in the case of the Strategy pattern, the context uses the Strategy object as a parameter or is provided during the creation of the object's context. UML diagram of the State pattern in Java This UML diagram for the State pattern depicts the classic problem of creating an object-oriented vending machine design in Java. You can see that the state of the vending machine is represented using an interface, which then has an implementation to represent the specific state. Each state also has references to the object context to make a transition to another state as a result of actions called in the context. UML diagram of the Strategy pattern in Java This UML diagram for the Strategy pattern contains functional implementations of sorts. Since there are many sorting algorithms, this design pattern allows the client to choose an algorithm when sorting objects. In fact, the Java Collection framework uses this pattern to implement a method Collections.sort()that is used to sort objects in Java. The only difference is that instead of allowing the client to choose a sorting algorithm, it allows it to specify the comparison strategy by passing an instance of the Comparator or Comparable interface to Java . Let's look at a few similarities between these two major design patterns in Java:

1. Both patterns, State and Strategy, make it easy to add new state and strategy without affecting the context of the object that uses them.


2. Both of these maintain your code according to the open/closed principle , meaning the design will be open to extensions but closed to modification. In the case of the State and Strategy patterns, the object's context is closed to modifications, the introduction of new States or new Strategies, or you do not need to modify the other state's context, or minimal changes.


3. Just as an object context starts with the object's initialization state in the State pattern, an object context also has a default strategy in the case of the Strategy pattern in Java.


4. The State pattern represents different behaviors in the form of different object states, while the Strategy pattern represents different behaviors in the form of different object strategies.


5. Both patterns, Strategy and State, depend on subclasses of behavior implementation. Each concrete strategy extends an Abstract Strategy; each state is a subclass of an interface or abstract class that is used to represent the State.

Differences between Strategy and State patterns in Java

So now we know that the State and Strategy patterns are similar in structure, but their intent is different. Let's look at some key differences between these design patterns.

1. The Strategy pattern encapsulates a set of related algorithms, and allows the client to use interchangeable behaviors despite composition and delegation at runtime, on the other hand, the State pattern helps a class exhibit different behaviors in different states.


2. The next difference between the State and Strategy patterns is that State encapsulates the state of an object, whereas the Strategy pattern encapsulates an algorithm or strategy. Since state is associated with an object it cannot be reused, but by decoupling a strategy or algorithm from its context we can reuse it.


3. In the State pattern, a personal state may contain a reference to the context to implement transitions between states, but a Strategy does not contain a reference to the context where it is used.


4. The implementation of a Strategy can be passed as a parameter to the object that will use it, for example Collection.sort() takes a Comparator which is a strategy. On the other hand, state is part of the object's context itself, and over time the object's context transitions from one state to another.


5. Although both Strategy and State follow the open/closed principle, Strategy also follows the Single Responsibility Principle since each Strategy contains an individual algorithm, the different strategies are independent of each other. Changing one strategy does not require changing another strategy.


6. Another theoretical difference between the Strategy and State patterns is that the creator defines the “How” part of the object, e.g. “How” the sort object sorts data, on the other hand, the State pattern defines the “what” and “when” parts of the object, e.g. what an object can do when it is in a certain state.


7. The order of state transitions is well defined in the State pattern; there is no such requirement for the Strategy pattern. The Client is free to choose any implementation of the Strategy of his choice.


8. Some of the common examples of the Strategy pattern are the encapsulation of algorithms, such as sorting algorithms, encryption algorithms, or a compression algorithm. If you see that your code must use different kinds of related algorithms, you should consider using the Strategy pattern. On the other hand, recognizing the use of the State pattern is quite easy, if you need to manage state and state transitions without a lot of nested conditional statements, the State pattern is the right pattern to use.


9. The last but one of the most important differences between the State and Strategy patterns is that a change to Strategy is performed by the Client, while a change to State can be performed by the context or the object's state itself.

This is all about the difference between the State and Strategy patterns in Java . As I said, both look similar in their classes and UML diagrams, both provide open/closed principles and encapsulate behavior. Use the Strategy pattern to encapsulate an algorithm or strategy that is exposed to the context at runtime, perhaps as a parameter or composite object, and use the State pattern to control state transitions in Java. Original here