Mastering the State Pattern

Hello! Welcome to your next lesson on behavioral design patterns.

In our previous session, we explored the Strategy pattern, which allows you to define a family of interchangeable algorithms and select one at runtime. We saw how it helps organize code that performs the same task in different ways, like choosing a payment method or a parking strategy.

Today, we'll tackle the learning outcome: Apply the State pattern to allow an object to alter its behavior when its internal state changes.

At first glance, the State pattern's structure can look almost identical to the Strategy pattern's. However, their intent is fundamentally different. While Strategy deals with how an action is performed, State deals with what actions are possible and how the object behaves based on its current condition. This pattern is essential for modeling objects that move through a lifecycle of different states, a common scenario in system design interviews.

What is the State Pattern?

Many objects in software don't have static behavior. Their response to a method call depends on their internal state. Think of a smartphone: pressing the power button does one thing if the screen is off (turns it on) and another if the screen is on (locks it). This concept is formally known as a finite state machine.

The State pattern provides an object-oriented way to implement such state machines. Instead of using large if/else or switch statements within the object's methods to check the current state, we encapsulate the behavior of each state into its own class.

As the video explains, the State pattern lets an object alter its behavior when its internal state changes, making it seem as if the object has changed its class. This approach helps us adhere to the Single Responsibility Principle (SRP) by moving state-specific logic into separate classes and the Open/Closed Principle (OCP) by allowing us to add new states without modifying existing ones.

The Structure of the State Pattern

The pattern has three key participants:

1. Context: The object whose behavior changes based on its state. It maintains a reference to an instance of a ConcreteState, which represents its current state.
2. State: An interface or abstract class that defines the methods representing the state-dependent behavior. The Context interacts with its state object through this interface.
3. ConcreteState: A class that implements the State interface. Each ConcreteState class provides the implementation for a particular state of the Context. Crucially, a ConcreteState can also be responsible for managing the transition of the Context to a new state.

Let's look at the structure of the pattern through a practical example: a package delivery service.

From this example, we see the key dynamics:

• The client code interacts only with the Package (Context) object, calling methods like nextState().
• The Package object doesn't contain any if/else logic. It simply delegates the call to its current state object (e.g., state.next(this)).
• The OrderedState's next() method contains the logic for transitioning to the next state: pkg.setState(new DeliveredState()). The state object itself controls the transition.

State vs. Strategy: A Critical Distinction

This is where many developers get confused, as the UML diagrams for both patterns are very similar. The key difference lies in their intent and dynamics.

Let's clarify this crucial distinction.

Here is a summary of the differences:

LLD Application: Designing a Vending Machine

One of the classic LLD interview problems you wanted to cover is designing a vending machine. This is a perfect use case for the State pattern, as a vending machine moves through a well-defined set of states: Idle, Has Money, Dispensing, Out of Stock, etc.

Let's design one. First, it's helpful to visualize the flow using a state diagram. This shows the possible states and the events that trigger transitions between them.

Now, let's see how we can model this using the State pattern in Java. The video below provides a detailed walkthrough, which is highly relevant for an LLD interview setting.

To complement the video, here is a clear UML class diagram and a complete code implementation for the vending machine. This shows the static structure of the classes you would design.

Finally, let's review a clean implementation of these components in Java.

In a Spring Boot application, you could implement the concrete state classes as singleton beans. The VendingMachine (Context) could then have the current state injected, or it could fetch the required state bean from the application context when a transition occurs.

Conclusion

You've now added another powerful behavioral pattern to your LLD toolkit. The State pattern is your go-to solution when an object's behavior is dictated by its internal state.

Key Takeaways:

• Purpose: The State pattern allows an object to change its behavior when its internal state changes, by encapsulating state-specific logic into separate classes.
• Problem Solved: It helps you avoid complex conditional logic (if/else, switch) for managing states, leading to cleaner code that follows SOLID principles.
• Core Components: It consists of a Context (the stateful object), a State interface, and ConcreteState classes that implement behavior and manage transitions.
• State vs. Strategy: Remember the key difference in intent. State is about what an object is (its state), while Strategy is about how an object does something (its algorithm).
• Interview Application: It is perfectly suited for designing stateful systems like vending machines, ATMs, elevators, and document workflows.

In our next lesson, we will cover the Template Method pattern. This pattern provides a way to define the skeleton of an algorithm in a base class, allowing subclasses to redefine certain steps without changing the algorithm's overall structure. It offers a different approach to code reuse and variability compared to the State and Strategy patterns.