State Pattern

Definition

The State allows an object to alter its behavior when its internal state changes. The object will appear to change its class. Each state is encapsulated in its own class, and the context delegates to the current state object.

Coffee Shop Example

A coffee order has a lifecycle: Created → Paid → Brewing → Ready → Collected. In each state, the order responds differently to the same actions — you can't start brewing an unpaid order, and you can't collect an order that isn't ready.

Structure

State Interface

public interface IOrderState
{
    void Pay(OrderContext order);
    void StartBrewing(OrderContext order);
    void FinishBrewing(OrderContext order);
    void Collect(OrderContext order);
    string GetName();
}

Context — The Order

public class OrderContext
{
    public string Customer { get; }
    public string Coffee { get; }
    public CupSize Size { get; }
    private IOrderState _state;

    public OrderContext(string customer, string coffee, CupSize size)
    {
        Customer = customer;
        Coffee = coffee;
        Size = size;
        _state = new CreatedState();
        Console.WriteLine($"  [{_state.GetName()}] Order created: {size} {coffee} for {customer}");
    }

    public void TransitionTo(IOrderState state)
    {
        _state = state;
        Console.WriteLine($"  → State: {_state.GetName()}");
    }

    public void Pay() => _state.Pay(this);
    public void StartBrewing() => _state.StartBrewing(this);
    public void FinishBrewing() => _state.FinishBrewing(this);
    public void Collect() => _state.Collect(this);
    public string GetState() => _state.GetName();
}

Concrete States

public class CreatedState : IOrderState
{
    public void Pay(OrderContext order)
    {
        Console.WriteLine($"  [Payment] Charging for {order.Coffee}...");
        order.TransitionTo(new PaidState());
    }

    public void StartBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Cannot brew — order not paid yet!");

    public void FinishBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Cannot finish — brewing hasn't started!");

    public void Collect(OrderContext order) =>
        Console.WriteLine("  ⚠️ Cannot collect — order not ready!");

    public string GetName() => "Created";
}

public class PaidState : IOrderState
{
    public void Pay(OrderContext order) =>
        Console.WriteLine("  ⚠️ Already paid!");

    public void StartBrewing(OrderContext order)
    {
        Console.WriteLine($"  [Barista] Starting to brew {order.Coffee}...");
        order.TransitionTo(new BrewingState());
    }

    public void FinishBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Cannot finish — brewing hasn't started!");

    public void Collect(OrderContext order) =>
        Console.WriteLine("  ⚠️ Cannot collect — order not ready!");

    public string GetName() => "Paid";
}

public class BrewingState : IOrderState
{
    public void Pay(OrderContext order) =>
        Console.WriteLine("  ⚠️ Already paid!");

    public void StartBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Already brewing!");

    public void FinishBrewing(OrderContext order)
    {
        Console.WriteLine($"  [Barista] {order.Coffee} is done!");
        order.TransitionTo(new ReadyState());
    }

    public void Collect(OrderContext order) =>
        Console.WriteLine("  ⚠️ Cannot collect — still brewing!");

    public string GetName() => "Brewing";
}

public class ReadyState : IOrderState
{
    public void Pay(OrderContext order) =>
        Console.WriteLine("  ⚠️ Already paid!");

    public void StartBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Already brewed!");

    public void FinishBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Already finished!");

    public void Collect(OrderContext order)
    {
        Console.WriteLine($"  [Pickup] {order.Customer} collected their {order.Coffee}! 🎉");
        order.TransitionTo(new CollectedState());
    }

    public string GetName() => "Ready";
}

public class CollectedState : IOrderState
{
    public void Pay(OrderContext order) =>
        Console.WriteLine("  ⚠️ Order already completed.");

    public void StartBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Order already completed.");

    public void FinishBrewing(OrderContext order) =>
        Console.WriteLine("  ⚠️ Order already completed.");

    public void Collect(OrderContext order) =>
        Console.WriteLine("  ⚠️ Order already collected.");

    public string GetName() => "Collected";
}

Client

var order = new OrderContext("Alice", "Latte", CupSize.Large);

// Try to brew before paying — blocked!
order.StartBrewing();
// ⚠️ Cannot brew — order not paid yet!

// Normal flow
order.Pay();
order.StartBrewing();
order.FinishBrewing();
order.Collect();

// Try to pay again — blocked!
order.Pay();
// ⚠️ Order already completed.

// Output:
//   [Created] Order created: Large Latte for Alice
//   ⚠️ Cannot brew — order not paid yet!
//   [Payment] Charging for Latte...
//   → State: Paid
//   [Barista] Starting to brew Latte...
//   → State: Brewing
//   [Barista] Latte is done!
//   → State: Ready
//   [Pickup] Alice collected their Latte! 🎉
//   → State: Collected
//   ⚠️ Order already completed.

tip

Each state class handles the same methods differently. The OrderContext delegates to the current state. Invalid transitions are handled gracefully — no if (state == "Brewing") checks needed.

State vs Strategy

	State	Strategy
Who changes it	The object itself (internal transitions)	Client (external injection)
Knowledge	Client doesn't know about states	Client chooses the strategy
Transitions	States know about other states	Strategies don't know about each other
Intent	Behavior changes with state	Algorithm changes by choice

.NET Real-World Usage

• ASP.NET Core IAuthenticationHandler — different behavior per auth state
• Task<T> lifecycle — Created → WaitingForActivation → Running → Completed/Faulted
• Workflow engines (Elsa, Orleans grains) — state-driven processing
• Game development — character states (idle, running, jumping, attacking)

When to Use

• An object's behavior depends on its state, and it must change at runtime
• You have large if/switch blocks that check state in many methods
• State transitions are complex with many rules

When NOT to Use

• There are only 2 states — a simple boolean flag suffices
• State logic is trivial — enum + switch is simpler
• States don't have complex behavior differences

Key Takeaways

• State encapsulates each state's behavior in its own class
• The context delegates to the current state object
• State transitions happen internally — the context calls TransitionTo()
• Eliminates large conditional blocks — each state class handles its own logic

Interview Questions

Q: How is State different from a finite state machine (FSM)? State pattern is an implementation of FSM in OOP. Each state class represents a state, and transitions are method calls. A traditional FSM uses a state table or switch — State pattern uses polymorphism.

Q: Should states be singletons or new instances? If states are stateless (no instance fields), they can be singletons — shared across all contexts. If states hold data (like a timer), create new instances per context.

Q: What's the State pattern's relationship to the Open/Closed Principle? Adding a new state (e.g., CancelledState) adds a new class without modifying existing states or the context. Each state is closed for modification, open for extension.

Related Topics

• Strategy — similar structure, client-driven (not state-driven)
• Template Method — fixed algorithm with variable steps
• Command — can trigger state transitions
• SOLID — OCP & SRP — each state class has one responsibility