The State Design Pattern
The State pattern allows an object to alter its behavior when its internal state changes.
Use the State pattern when an object’s behavior changes according to its internal state, or when you have an object that manifests different states in complex ways.
- TypeBehavioral
- Time ComplexityO(1) Constant Time – The algorithm runs in constant time, irrespective of the input size. Operations like accessing an array element fall into this category.
- Efficiency7
-
Learning Effort
- Average6
- Conceptual6
- Debug and Maintain6
- Implementation5
- Prerequisites5
- Versatility7
Things you should know before you start
- Polymorphism Understanding of polymorphism, as the State pattern utilizes polymorphism to delegate behaviors based on state.
Minimal Example
Implementing a simple traffic light system that changes its behavior based on its current state (Red, Yellow, Green).
class TrafficLight implements Context {
setState(state: State): void { /* ... */ }
handleRequest(): void { /* ... */ }
}
const trafficLight = new TrafficLight();
trafficLight.setState(new RedState());
trafficLight.handleRequest();
trafficLight.setState(new GreenState());
trafficLight.handleRequest();
What’s happening in thie example
In this example, the `TrafficLight` serves as the Context, and `RedState` and `GreenState` are ConcreteStates. The `clientCode` shows how to change the state of the traffic light and handle requests based on the current state.
How the State Works
The State pattern is useful for implementing finite state machines within an object.
It encapsulates varying behavior for the same routine in an object based on its state.
Entities in the State Design Pattern
-
ContextThe Context delegates state-specific behavior to different State objects.
- Context has a one-to-many delegates relationship with ConcreteState
What to watch out for when using or considering this design pattern.
Avoid using the State pattern if your object’s behavior doesn’t depend significantly on its state, or if states don’t transition often, to keep the logic simple.
Design patterns often confused with the State Design Pattern
The following design patterns are often confused with the State
for various resons.
If you’re exploring solutions, have a look through this list and see if
one of these might be a better fit for your problem.
-
Strategy – The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.
The Strategy pattern is similar to the State in the following ways.
- Both patterns aim to encapsulate varying behavior in separate classes.
- Both are behavioral design patterns.
- State changes its behavior dynamically according to internal changes, while Strategy lets you change the behavior by replacing the algorithm.
-
Singleton – The Singleton pattern ensures that a class has only one instance and provides a global point of access to it.
The Singleton pattern is similar to the State in the following ways.
- Both patterns involve controlling the state of objects.
- Both can improve code organization.
- State deals with an object’s internal states, while Singleton restricts object instantiation.