How State Design Pattern Works: Real-World Examples

Introduction and Core Concepts

The state design pattern is a behavioral design pattern that allows an object to alter its behavior when its internal state changes. At first glance, this may sound trivial — after all, every object has state — but the pattern addresses a very specific and common problem: how to manage complex, state-dependent behavior without drowning in conditional logic. Instead of littering your code with sprawling if-else or switch statements that check the current state before deciding what to do, the State pattern encapsulates each state as its own class.

Formally, the State pattern is defined by the Gang of Four (GoF) as a way to let an object appear to change its class when its state changes. The key insight is delegation. A context object maintains a reference to a state object that represents its current state. All state-specific behavior is delegated to that state object. When a transition occurs, the context simply swaps its state object for another, and its observable behavior changes instantly. This promotes the Open/Closed Principle: you can introduce new states without modifying existing context or state classes.

Why does this matter for modern software engineering? As systems grow, the number of states and transitions often grows exponentially. Consider an e-commerce order that can be New, Paid, Shipped, Delivered, Cancelled, or Returned, each with different rules for what operations are allowed. Without the State pattern, methods like ship(), cancel(), or refund() become tangled nests of conditionals that are brittle, hard to test, and prone to bugs when a new state is added. The State pattern transforms this procedural complexity into a clean object-oriented structure where each state is explicit, testable, and self-contained. It is particularly valuable in domains where state machines are inherent, such as UI workflows, network protocols, game development, and embedded systems.

Core Participants

To understand the pattern, you must know its three core participants. The Context is the object whose behavior varies with state; it holds a reference to the current State and delegates work to it. The State is an abstract interface or base class that declares state-specific methods. The ConcreteState classes implement behavior for each distinct state and contain the logic for transitioning to other states. This separation of concerns is what makes the pattern powerful.

A common misconception is that the State pattern is just a fancy way to write a switch statement. In reality, it inverts the responsibility. Instead of the Context deciding what to do based on its state, each ConcreteState decides what to do and when to transition. This locality of behavior makes the system far easier to reason about and extend.

How It Works

The mechanism of the state design pattern revolves around composition and polymorphism. The Context does not implement state-dependent logic itself; it forwards requests to its current State object. For example, when a client calls context.request(), the Context executes something like self.state.handle(self). The State object then performs the appropriate action for that state and may change the Context's state by assigning a new ConcreteState instance to context.state.

This delegation creates a dynamic binding where the Context's behavior is determined at runtime by the object it points to. From the client's perspective, the Context appears to have changed its class, even though it is the same object with a different internal delegate. Transitions can be triggered either by the Context or, more commonly, by the ConcreteState itself. When a ConcreteState handles a request, it has full access to the Context and can inspect its data, perform actions, and decide on the next state based on business rules.

A crucial design decision is who defines the state transitions. There are two main approaches. In the first, each ConcreteState knows its successor states and performs the transition explicitly. This keeps transition logic close to the behavior it relates to but can create dependencies between state classes. In the second, transitions are centralized in the Context or in a separate transition table or manager. Centralization reduces coupling but can reintroduce conditional logic if not carefully designed. Most real-world implementations use a hybrid approach where simple, deterministic transitions live in the states, while complex, conditional transitions are managed externally.

State vs. Status Flag

Many developers start with a simple status flag, such as order.status = "paid", and then write methods that branch on that flag. This works for two or three states but quickly collapses under complexity. The State pattern replaces the flag with a polymorphic object. The flag is still there conceptually, but it is now represented by a type, not a string or enum. This enables the compiler or interpreter to help you: missing behavior for a new state becomes a missing method implementation rather than a forgotten if branch that fails silently at runtime.

Another important aspect is sharing state objects. If ConcreteState classes are stateless — that is, they contain no instance-specific data and only behavior — they can be implemented as singletons or flyweights and shared across many Context instances. This significantly reduces memory overhead in systems with thousands of contexts, such as server connections or game entities, all sharing the same small set of states.

Implementation

Implementing the state design pattern in Python is idiomatic thanks to Python's support for abstract base classes, duck typing, and first-class objects. While Python does not enforce interfaces strictly, using the abc module makes the intent explicit and helps catch errors early. Below is the canonical structure of the pattern.

from abc import ABC, abstractmethod

# State interface - declares state-specific behavior
class OrderState(ABC):
    @abstractmethod
    def pay(self, context) -> None:
        pass

    @abstractmethod
    def ship(self, context) -> None:
        pass

    @abstractmethod
    def cancel(self, context) -> None:
        pass

# Context - maintains current state and delegates to it
class OrderContext:
    def __init__(self):
        # Initial state
        self.state: OrderState = NewState()
        self.payment_received = False

    def set_state(self, state: OrderState):
        print(f"Transitioning from {self.state.__class__.__name__} to {state.__class__.__name__}")
        self.state = state

    # Delegated operations
    def pay(self):
        self.state.pay(self)

    def ship(self):
        self.state.ship(self)

    def cancel(self):
        self.state.cancel(self)

This first block establishes the skeleton. The OrderState abstract class defines the operations that are state-dependent. The OrderContext holds the current state and provides a set_state method for transitions. Client code never interacts with state objects directly; it only calls methods on the context.

# Concrete States - each encapsulates behavior for one state
class NewState(OrderState):
    def pay(self, context):
        print("Processing payment for new order.")
        context.payment_received = True
        context.set_state(PaidState())

    def ship(self, context):
        print("Cannot ship unpaid order. Please pay first.")

    def cancel(self, context):
        print("Cancelling new order.")
        context.set_state(CancelledState())

class PaidState(OrderState):
    def pay(self, context):
        print("Order already paid. Duplicate payment ignored.")

    def ship(self, context):
        print("Payment verified. Shipping order.")
        context.set_state(ShippedState())

    def cancel(self, context):
        # Business rule: can cancel within 24h if not shipped
        print("Refunding payment and cancelling order.")
        context.set_state(CancelledState())

class ShippedState(OrderState):
    def pay(self, context):
        print("Order already shipped. Cannot pay again.")

    def ship(self, context):
        print("Order already shipped. Tracking number sent.")

    def cancel(self, context):
        print("Cannot cancel. Order already shipped. Initiate return instead.")

class CancelledState(OrderState):
    def pay(self, context):
        print("Cannot pay for cancelled order. Create a new order.")

    def ship(self, context):
        print("Cannot ship cancelled order.")

    def cancel(self, context):
        print("Order already cancelled.")

Here each ConcreteState implements only the behavior relevant to it. Notice how transition logic lives inside the state: NewState.pay() moves the context to PaidState, while PaidState.ship() moves it to ShippedState. Invalid operations are handled gracefully within the state rather than by the context checking flags. This makes adding a new state, such as ReturnedState, trivial: you create a new class without touching existing code.

# Client usage - no conditionals needed
if __name__ == "__main__":
    order = OrderContext()  # Starts in NewState
    order.ship()   # Output: Cannot ship unpaid order...
    order.pay()    # Output: Processing payment... Transitioning to PaidState
    order.pay()    # Output: Order already paid...
    order.ship()   # Output: Payment verified... Transitioning to ShippedState
    order.cancel() # Output: Cannot cancel. Order already shipped...

    # Adding a new order shows independence
    order2 = OrderContext()
    order2.cancel() # Output: Cancelling new order... Transitioning to CancelledState
    order2.pay()    # Output: Cannot pay for cancelled order...

The client code is remarkably clean. There are no if order.status == "paid" checks. The order object itself behaves correctly based on its internal state object. This is the primary benefit: complexity is encapsulated, not scattered.

Step-by-Step Example

To solidify the concept, let us walk through a complete, concrete example: a vending machine. A vending machine has a clear set of states and well-defined transitions, making it an ideal candidate for the State pattern. We will model four states: NoCoin, HasCoin, Dispensing, and SoldOut.

Step 1: Identify states and events. The machine starts with no coin. When a user inserts a coin, it moves to HasCoin. From HasCoin, the user can press a button to dispense an item, moving to Dispensing, or request a refund to return to NoCoin. After dispensing, if inventory remains, it returns to NoCoin; if inventory is zero, it moves to SoldOut. In SoldOut, no operations except restocking are meaningful. Events are insert_coin(), eject_coin(), select_item(), dispense(), and restock().

Step 2: Define the State interface and Context. The interface declares all events. The Context, VendingMachine, holds inventory count, current state, and delegates events. It also provides helper methods that states can call, such as release_item() and get_inventory().

from abc import ABC, abstractmethod

class VendingState(ABC):
    @abstractmethod
    def insert_coin(self, machine) -> None: pass
    @abstractmethod
    def eject_coin(self, machine) -> None: pass
    @abstractmethod
    def select_item(self, machine) -> None: pass
    @abstractmethod
    def dispense(self, machine) -> None: pass

class VendingMachine:
    def __init__(self, inventory: int):
        self.inventory = inventory
        # Initialize states (could be singletons)
        self.no_coin_state = NoCoinState()
        self.has_coin_state = HasCoinState()
        self.sold_out_state = SoldOutState()
        self.dispensing_state = DispensingState()

        if inventory > 0:
            self.state = self.no_coin_state
        else:
            self.state = self.sold_out_state

    def set_state(self, state: VendingState):
        self.state = state

    def release_item(self):
        if self.inventory > 0:
            self.inventory -= 1
            print(f"Item dispensed. Inventory remaining: {self.inventory}")

    # Delegation methods
    def insert_coin(self): self.state.insert_coin(self)
    def eject_coin(self): self.state.eject_coin(self)
    def select_item(self): self.state.select_item(self)
    def dispense(self): self.state.dispense(self)

class NoCoinState(VendingState):
    def insert_coin(self, machine):
        print("Coin inserted.")
        machine.set_state(machine.has_coin_state)

    def eject_coin(self, machine):
        print("No coin to eject.")

    def select_item(self, machine):
        print("Please insert coin first.")

    def dispense(self, machine):
        print("Payment required.")

class HasCoinState(VendingState):
    def insert_coin(self, machine):
        print("Coin already inserted. Cannot insert another.")

    def eject_coin(self, machine):
        print("Coin ejected. Returning to idle.")
        machine.set_state(machine.no_coin_state)

    def select_item(self, machine):
        print("Item selected. Dispensing...")
        machine.set_state(machine.dispensing_state)
        # Automatically trigger dispense in this design
        machine.dispense()

    def dispense(self, machine):
        print("Please select an item first.")

class DispensingState(VendingState):
    def insert_coin(self, machine): print("Please wait, dispensing...")
    def eject_coin(self, machine): print("Cannot eject, already dispensing...")
    def select_item(self, machine): print("Already dispensing item...")

    def dispense(self, machine):
        machine.release_item()
        if machine.inventory > 0:
            machine.set_state(machine.no_coin_state)
        else:
            print("Machine is now sold out.")
            machine.set_state(machine.sold_out_state)

class SoldOutState(VendingState):
    def insert_coin(self, machine): print("Sold out. Coin rejected.")
    def eject_coin(self, machine): print("No coin to eject. Machine sold out.")
    def select_item(self, machine): print("Sold out. No item to select.")
    def dispense(self, machine): print("Sold out. Cannot dispense.")

    # Extra behavior not in interface - can be added via context method
    def restock(self, machine, count: int):
        machine.inventory += count
        print(f"Restocked with {count} items.")
        if machine.inventory > 0:
            machine.set_state(machine.no_coin_state)

Step 3: Trace an execution. Create machine = VendingMachine(inventory=2). It starts in NoCoinState. Calling machine.select_item() prints "Please insert coin first" and does not change state. Calling machine.insert_coin() transitions to HasCoinState. Calling machine.select_item() now transitions to DispensingState and immediately calls dispense(), which releases an item, decrements inventory to 1, and returns to NoCoinState. A second purchase repeats the cycle, but after the second dispense, inventory becomes 0 and the machine transitions to SoldOutState, where further inserts are rejected. Each step is handled by the appropriate state object, with no conditional logic in VendingMachine itself.

Step 4: Observe extensibility. Suppose we need a new state: MaintenanceMode where the machine is being serviced. We simply create a MaintenanceState class and add a transition method to the context. No existing state classes need modification, demonstrating the Open/Closed Principle in action.

Complexity Analysis

Analyzing the state design pattern requires distinguishing between the pattern's overhead and the complexity of the operations it encapsulates. The pattern itself does not change the asymptotic complexity of business logic, but it affects how that logic is organized and how state transitions are performed. All core operations are typically constant time.

Request handling is O(1). When the context delegates to its current state, it performs a single method dispatch via polymorphism. There is no searching or iteration over states. Similarly, a state transition is O(1): it is simply an assignment of a reference, context.state = new_state. Memory overhead is also constant per context if states are shared as singletons. If states are instantiated per transition, there is a small allocation cost, but still O(1) per operation.

The real complexity benefit is in maintainability, not raw performance. Without the pattern, a method with branching on n states has cyclomatic complexity O(n) and each new state requires modifying every method that branches. With the pattern, adding a new state is O(1) in terms of changes to existing code — you add one new class — and each state's methods have cyclomatic complexity O(1). This linear vs. constant scaling of maintenance effort is where the pattern shines for large state machines.

Space complexity deserves attention. If each context creates new state objects on every transition, memory usage can grow with the number of transitions. The optimized approach is to make ConcreteState classes stateless and share singleton instances across all contexts. In Python, this can be done by instantiating states once in the context's __init__ and reusing them, as shown in the vending machine example. This reduces space from O(n * m) to O(n + m), where n is the number of states and m is the number of contexts.

In performance-critical systems, the extra indirection of delegation introduces a negligible overhead compared to a direct if-else. In Python, a polymorphic call is slightly slower than a simple integer comparison, but the difference is on the order of nanoseconds and is overwhelmingly outweighed by improved readability, testability, and reduced bug risk. For high-frequency systems like game loops or network packet handlers, the pattern is still preferred because it prevents state-related bugs that are far more expensive than a virtual dispatch.

Variations and Optimizations

While the classic GoF implementation is powerful, several variations adapt the pattern to different constraints and language features. Understanding these helps you choose the right level of complexity for your problem.

The first common variation is the Table-Driven State Machine. Instead of each state knowing its successors, transitions are defined in a central data structure, often a dictionary mapping (current_state, event) to next_state and action. This is useful when transitions are numerous, data-driven, or need to be configured externally, such as from a JSON file or database. It centralizes transition logic and makes it easy to visualize the entire state machine, but it can obscure the behavior associated with each state if actions are also table-driven.

A second variation uses Hierarchical or Nested States, also known as Statecharts. In complex systems, states often have substates. For example, a PaidState might have substates PaymentVerified and PaymentFailed. Hierarchical states allow common behavior to be defined in a parent state and inherited by children, reducing duplication. Python can implement this via class inheritance among state classes or by composing states. This is particularly useful in UI frameworks and embedded systems where state nesting is natural.

A third optimization is using Python Enums and Functions for lightweight state machines. For simple machines with little behavior per state, full classes may be overkill. You can use an Enum for states and a dictionary of functions, achieving similar delegation with less boilerplate. Libraries like transitions or python-statemachine provide declarative syntax for this approach.

# Variation: Table-driven + Enum for lightweight machines
from enum import Enum, auto

class LightState(Enum):
    IDLE = auto()
    RUNNING = auto()
    PAUSED = auto()

class LightContext:
    def __init__(self):
        self.state = LightState.IDLE
        # Transition table: (state, event) -> (next_state, action)
        self.transitions = {
            (LightState.IDLE, "start"): (LightState.RUNNING, self._on_start),
            (LightState.RUNNING, "pause"): (LightState.PAUSED, self._on_pause),
            (LightState.PAUSED, "resume"): (LightState.RUNNING, self._on_resume),
            (LightState.RUNNING, "stop"): (LightState.IDLE, self._on_stop),
            (LightState.PAUSED, "stop"): (LightState.IDLE, self._on_stop),
        }

    def handle(self, event: str):
        key = (self.state, event)
        if key not in self.transitions:
            print(f"Event '{event}' not allowed in state {self.state.name}")
            return
        next_state, action = self.transitions[key]
        action()
        print(f"Transition: {self.state.name} --({event})--> {next_state.name}")
        self.state = next_state

    def _on_start(self): print("System starting...")
    def _on_pause(self): print("System pausing...")
    def _on_resume(self): print("System resuming...")
    def _on_stop(self): print("System stopping...")

# Usage
# ctx = LightContext()
# ctx.handle("start")  # IDLE --(start)--> RUNNING
# ctx.handle("pause")  # RUNNING --(pause)--> PAUSED
# ctx.handle("resume") # PAUSED --(resume)--> RUNNING

This table-driven version trades explicit state classes for a declarative table. It is excellent when states are many but behavior per state is small, or when non-developers need to configure transitions. For behavior-rich states, the classic class-based approach remains clearer because it colocates data and behavior.

Other optimizations include using the Flyweight pattern to share state instances, adding history states to remember the last substate when exiting a composite state, and integrating event queues for asynchronous state machines where events arrive from multiple threads. In concurrent systems, ensuring thread-safe transitions, often by protecting set_state with a lock, is critical.

Real-World Applications

The state design pattern is not an academic curiosity; it powers many production systems across different domains. Its ability to model finite state machines cleanly makes it indispensable where behavior is inherently stateful.

In web servers and network protocols, connections follow a strict lifecycle. A TCP connection moves through states like LISTEN, SYN_SENT, ESTABLISHED, FIN_WAIT, and CLOSED. Web frameworks use state to manage request handling, authentication flows, and session management. For example, an HTTP request handler might have states for Unauthenticated, Authenticating, Authenticated, and TokenExpired, each with different permissions for accessing resources. Using the State pattern prevents security bugs where an expired session is incorrectly allowed to perform privileged actions.

In databases and transaction managers, transactions have states such as Active, Partially Committed, Committed, Failed, and Aborted. The behavior of commit(), rollback(), and read() depends entirely on the current transaction state. Workflow engines, such as those in order management or document approval systems, are essentially large state machines where each document moves through Draft, Review, Approved, Published, and Archived states with role-based transition rules.

In game development, the pattern is ubiquitous. A game character might have states like Idle, Running, Jumping, Falling, Attacking, and Dead. Each state handles input, animation, and physics differently. AI opponents use state machines for behaviors like Patrol, Chase, Attack, and Flee. Without the State pattern, character controllers become unmanageable spaghetti code.

In user interfaces, the pattern manages complex interactions. A drawing tool might have states for Select, DrawLine, DrawRectangle, and Erase, each handling mouse events differently. A media player with states Idle, Playing, Paused, and Buffering ensures that pressing pause while already paused does not cause errors. Frontend frameworks like XState for JavaScript have popularized explicit state machines for UI logic, and the same principles apply in Python desktop apps with Tkinter or PyQt.

Even DevOps and infrastructure tools use it. CI/CD pipelines model builds as Pending, Running, Success, Failed, and Cancelled. Cloud resource provisioning, such as AWS EC2 instances with states Pending, Running, Stopping, Stopped, and Terminated, relies on state machines to orchestrate lifecycle operations safely.

Comparison with Alternatives

Choosing the right pattern requires understanding how the State pattern relates to similar approaches. It is often confused with Strategy, Template Method, and simple conditional logic, but each solves a different problem.

The most frequent comparison is State vs. Strategy. Both use composition and delegation to vary behavior, and their class diagrams look nearly identical. The difference is intent. Strategy is about selecting an algorithm at runtime from a family of interchangeable algorithms; the client typically chooses the strategy and it does not change autonomously. State is about an object changing its behavior as its internal state changes over time; transitions are often autonomous and driven by the states themselves. In Strategy, strategies are usually unaware of each other. In State, concrete states often know about and transition to other states.

Template Method defines a skeleton algorithm in a base class and lets subclasses override steps. It uses inheritance, not composition, and is suitable when the overall flow is fixed but steps vary. State is preferred when the entire behavior, including which steps are allowed, varies with state. Finite State Machine (FSM) libraries provide a declarative alternative where you define states and transitions externally. They are more concise for large, data-driven machines but less flexible for behavior-rich states that need complex logic and access to context data.

For very simple cases with two or three states and little behavior, a well-structured if-else may be more pragmatic than introducing multiple classes. The overhead of the pattern is not justified when the state machine is trivial and unlikely to grow. The key is to recognize the tipping point: when you find yourself adding a third or fourth conditional that checks the same status flag in multiple methods, it is time to refactor to the State pattern before technical debt accumulates.

Common Mistakes and Best Practices

Despite its elegance, the State pattern is frequently misapplied. Awareness of common pitfalls helps you reap its benefits without introducing new problems.

A major mistake is leaking transition logic everywhere. If both the Context and multiple ConcreteStates can change the state, transitions become hard to trace. Best practice is to decide on a single responsibility for transitions. For simple machines, let states handle their own transitions. For complex machines with many conditional transitions, centralize logic in the Context or a dedicated StateManager. Document who is allowed to call set_state.

Another pitfall is creating stateful ConcreteState objects that store per-context data. States should ideally be stateless and shareable. If a state needs context-specific data, it should read it from the Context passed into its methods, not store it internally. Storing per-context data in the state object leads to bugs when states are shared and to memory bloat when they are not. If you must store state-specific data, ensure each Context gets its own state instances or store the data in the Context itself.

Developers often forget to handle invalid events. In a robust implementation, every state should explicitly handle every possible event, even if the handling is just to log a warning or raise an exception. Silent failures where an event is ignored because a state does not implement it are a source of subtle bugs. Using an abstract base class that declares all events forces each ConcreteState to provide an implementation, making missing handlers a compile-time or instantiation error.

• Keep states focused: Each state should have a single responsibility and handle only events relevant to it. If a state class grows too large, consider splitting it into hierarchical substates.
• Use dependency injection for context: Pass the context into state methods rather than giving states a permanent reference to the context at construction time. This reduces coupling and makes testing easier.
• Make transitions explicit and auditable: Log every transition with from-state, to-state, and triggering event. This is invaluable for debugging and for building audit trails in business workflows.
• Consider immutability: Where possible, make state objects immutable singletons. This simplifies concurrency and reasoning about shared state.
• Test states in isolation: Write unit tests for each ConcreteState by mocking the Context. Verify that each event either performs the correct action and transition or correctly rejects the operation.
• Do not overuse: If your object has only one or two states and transitions are unlikely to grow, prefer a simple enum and conditionals. Apply the pattern when complexity justifies it.

Finally, avoid exposing set_state publicly without validation. If clients can arbitrarily set any state, they can bypass business rules and put the context into an invalid state. Make set_state private or protected, or add validation to ensure only allowed transitions occur. Some implementations use a transition map to validate that a requested transition is legal before applying it.

Interview Questions

Understanding the State pattern deeply will help you answer common interview questions and demonstrate design judgment beyond just memorizing the structure.

1. What is the difference between State and Strategy patterns, and when would you choose one over the other?

This question tests whether you understand intent versus structure. Answer by emphasizing that both use composition and delegation but solve different problems. State is for an object that changes behavior as its internal state evolves over its lifecycle; transitions are often internal and autonomous, and states are aware of each other. Strategy is for selecting one algorithm from a family at runtime; the client usually chooses the strategy, strategies are interchangeable and unaware of each other, and they do not transition between themselves. Choose State when you have a lifecycle with distinct phases and rules about what is allowed when, such as an order or connection. Choose Strategy when you need to vary how a task is performed, such as different sorting, compression, or payment algorithms.

2. How would you implement a thread-safe State pattern in Python?

Interviewers ask this to probe concurrency knowledge. Explain that the critical section is the state transition and any read-modify-write on context data that influences transitions. You would protect set_state and any delegation that checks and updates state with a lock, such as threading.Lock or threading.RLock. For better performance, you could use a single lock in the Context that wraps both the delegation call and transition. Mention that if ConcreteState objects are stateless singletons, they are inherently thread-safe, but the Context's reference to the current state must be protected. For high-throughput systems, consider using an event queue and a single state-machine thread to avoid fine-grained locking altogether.

3. What are the trade-offs of putting transition logic inside ConcreteState versus inside the Context?

This explores design trade-offs. If transitions live in ConcreteStates, behavior and transition are colocated, which is cohesive and follows the Single Responsibility Principle for that state. However, it creates coupling between state classes because each state must import or know about its successor states, and it distributes transition logic, making it harder to see the full state machine at a glance. If transitions live in the Context, coupling between states is reduced and the full transition map is centralized and easier to visualize or configure, but the Context can become a god object with complex conditionals, partially defeating the purpose of the pattern. A balanced answer suggests using state-driven transitions for simple, deterministic cases and centralized table-driven transitions for complex, conditional, or configurable machines, and mentions logging and validation in either case.

4. Can you give an example where you would NOT use the State pattern?

This tests pragmatism. Answer that you would not use it for trivial state with two values and little behavior, such as a boolean is_enabled flag that only affects one method. The overhead of multiple classes would outweigh benefits. Also avoid it when states have no behavior differences and only data differs — a simple data object or enum suffices. Another case is when transitions are highly dynamic and data-driven from external configuration; a table-driven FSM library or workflow engine may be more appropriate than hand-coded state classes. Emphasize the principle of not over-engineering and applying the pattern when cyclomatic complexity or the number of states justifies it.

5. How do you handle adding a new state that requires a new event not present in the State interface?

This question checks understanding of the Open/Closed Principle and interface evolution. Explain that adding a new event to the State interface requires modifying the abstract base class and all existing ConcreteState implementations, which violates Open/Closed. To mitigate, you can provide default no-op or raise-NotImplemented implementations in the base class so existing states do not break, or use a more flexible design where the State interface has a generic handle(event) method that dispatches via a dictionary. Alternatively, use the Visitor pattern or introduce a new interface for the new event and have only relevant states implement it, with the Context checking capability via hasattr or isinstance. Discuss versioning and how to keep the interface stable by anticipating events or using an event object hierarchy.