Strategy vs State pattern

I've seen a lot of job interview. Whenever it comes to design patterns, the most common question is the difference between Strategy and State patterns. Surprising part here, that acceptable answer usually is wrong.

Developers claiming next statement:

Strategy should be changed outside, while State manage itself by its own

While being technically correct, it is still wrong. Do you know why? Let’s find out.

Back to the bone

Strategy and State are both quite similar. Just look at their representation in UML form:

Eeeeh… that did not really help, did it? So far, our statement is correct 😕
Alright, maybe we can have a look at their definition or pieces of code.

Strategy

Strategy patterns allow having multiple implementation of one algorithm.

The algorithm itself could be complex, but even something simple can fit our need. For example, imagine we need to log information about our system, so we would write an interface like this:

The next step would be to implement that interface. In our system we want to support multiple behavior, log to console and in azure application insight. Of course, we could do it with a single service, but separating it in multiple strategies will help us to reduce coupling. After all, we are professional developers that don't write spaghetti code 😎

So here we are. Strategy is very simple and straightforward patterns. It helps us to reduce complexity by splitting multiple implementation in separate classes, so we can choose which one to use.

State

On the other hand, State pattern allows us to implement a state machine.

“Wait? State machine? What the hell is that? It does not sound like Strategy at all. I thought state helps classes to implement different algorithm and use one depending on a current state, same way as strategy does.”

It is not a surprise you thought like this. That is just a simpler explanation of what state machine is. And that is exactly why all confusing happen.

Developers used to think about state as strategy, where context define which strategy should be used. They simplified stuff so much that even renamed “State Machine” pattern to simple “State”. However, State is indeed a much deeper and diverse pattern comparing to Strategy.

To understand state pattern, you need to understand finite state machine first. It is not that easy. There are books written about it. It just hella big subject to investigate.

But you can think about a state machine as a graph with nodes and edges which you can travel. Do you know what it reminds me? States of water. The water can be in one state and transit to another based on certain condition.

Which can now be represented as a simple state machine:

“Enough theory. I am already tired 😖 Just show me the code”

😃 Alright, alright, as you wish.

Firstly, we need to show that our state are not independent but work in conjunction. The interface is great for it:

Now let's implement each state. Node from our diagram will be represented as classes and transition between states will be represented by methods. By executing each method, the state should change:

Notice, how Liquid state changes to Solid whenever we freeze it. On the other hand, freezing Solid state does not do anything, since such change not supported by our state machine.

Currently, our states does not contain any logic except transition, however, you can extend it the way you like.

And last piece. The consumer of our code should not know about states at all. We will just give him a simplified API of our Water class.

We can call it a day 😌

Our state machine implemented. However, there are tons of other state machine around the world. Think about a shopping cart that can transit between empty, active and paid states. What about traffic light? Or vending machine? Those also have few states, depending on the complexity of their implementation. Setup wizard is just a state machine represented with UI where next window is chosen based on your previous selection. Maybe you came from microservice word where you have such thing as saga or circuit breaker. Those also could be done as state machine. Next time you see a flowchart in your requirements, try simplifying it to state machine and see where it gets you.

State machines are a common way to break complex tasks into manageable steps that implement some narrowly defined behavior.

Of course there is no much use in implementing state pattern when so little state present, but once you start noticing pattern you would start thinking about it in different way.

Summary

Do you remember that statement from the very beginning?

Strategy should be changed outside, while State manage itself by its own

The difference between strategy and state not the one is changes outside the context while another inside. That does not affect our patterns at all. Look at the Strategy we have here. Try changing Strategy inside our context and that would not turn it to State pattern. Those are completely different in their implementation and in what they do.

Patterns are not only about UML, but their definition and idea that stand behind them. While Strategy define different algorithms, State implements a finite state machine.

That's all folks 🐷 I hope you learned something new here 🤓 Give this article a clap 👏 Support me with coffee ☕️ And do not forget to follow to receive more on design patterns ✅