Difference Between State and Strategy?

Junior Level

Both patterns look similar, but their purpose is different:

Strategy — choosing algorithm externally (client decides):

// Client chooses the strategy
order.setPaymentStrategy(new CreditCardPayment());  // From outside
order.pay();

State — behavior change internally (object decides itself):

// Object changes its own state
order.process();  // Inside: if paid -> ship, if not -> wait

Simple analogy:

Strategy: You choose a route in a navigator (by car/on foot)
State: Traffic light changes color itself (red -> yellow -> green)

Middle Level

Strategy: External Control

interface SortStrategy { void sort(List<Integer> list); }

class QuickSort implements SortStrategy { ... }
class MergeSort implements SortStrategy { ... }

// CLIENT decides
List<Integer> data = new ArrayList<>();
Sorter sorter = new Sorter();
sorter.setStrategy(new QuickSort());  // Client chose
sorter.sort(data);

State: Internal Control

interface OrderState { void process(Order order); }

class Order {
    private OrderState state;
    void setState(OrderState s) { this.state = s; }
    void process() { state.process(this); } // delegation to state
}

class NewState implements OrderState {
    public void process(Order order) {
        // Direct state creation (new PaidState()) is an anti-pattern (tight coupling).
        // Correct approach: transitions via Registry/Factory.
        order.setState(new PaidState());
    }
}

class PaidState implements OrderState {
    public void process(Order order) {
        order.setState(new ShippedState());
    }
}

// OBJECT changes state itself
Order order = new Order();
order.setState(new NewState());
order.process();  // Inside: NewState -> PaidState
order.process();  // Inside: PaidState -> ShippedState

Comparison

Criterion	Strategy	State
Who chooses	Client	Object itself
When changed	Runtime, by choice	When state changes
Dependencies	Strategies don’t know each other	States know about transitions
Goal	Algorithm replacement	Behavior management

Senior Level

Architecture Intent

Strategy = Dependency Injection for algorithms
  -> Inject the right algorithm
  -> Algorithms are independent

State = Finite State Machine
  -> States are linked by transitions
  -> Each state knows about the next ones

Coupling Differences

// Strategy: strategies DON'T know about each other
class CreditCardPayment implements PaymentStrategy { }
class PayPalPayment implements PaymentStrategy { }
// No dependencies between them

// State: states know about transitions
class NewState implements OrderState {
    public void process(Order order) {
        order.setState(new PaidState());  // Knows about PaidState!
    }
}
// Coupled through context

Production Experience

Real scenario:

Order: 5 states
First used Strategy -> client managed transitions
Bugs: order went from “Delivered” to “New”
Solution: State machine with transition validation
Result: invalid transitions impossible

Best Practices

Strategy for algorithm swapping
State for lifecycle management
Enum for simple states
Spring Statemachine for enterprise
Transition validation in State

Senior Summary

Strategy = client chooses algorithm
State = object manages its own behavior
Strategy = independent algorithms
State = linked transitions between states
State Machine prevents invalid transitions

Interview Cheat Sheet

Must know:

Strategy — client chooses algorithm externally, State — object changes behavior internally
Strategy: algorithms are independent, State: states are linked by transitions
Strategy = Dependency Injection for algorithms, State = Finite State Machine
State prevents invalid transitions (cannot go from “Delivered” to “New”)
Template Method — replacing algorithm parts via inheritance, Strategy — entire algorithm via composition
For simple states: Enum with abstract methods, for enterprise: Spring Statemachine
Direct state creation (new PaidState()) — tight coupling, correct approach: transitions via Registry/Factory

Common follow-up questions:

When to use State instead of Strategy? — When there’s a lifecycle with valid transitions (order, document)
Why should states know about transitions? — Otherwise the client can make an invalid transition
How does Template Method differ from Strategy? — Template Method = algorithm parts (inheritance), Strategy = entire algorithm (composition)
What to do if there are too many transitions? — State machine with transition table, Spring Statemachine

Red flags (DO NOT say):

“Strategy and State are the same” — fundamentally different purpose and control
“Client should manage states” — then it’s Strategy, not State
“State machine is overengineering” — with 5+ states, there will be transition bugs without it
“States shouldn’t know about each other” — then transitions cannot be validated

Related topics:

[[10. When to use Strategy]] — main Strategy pattern
[[15. What is Iterator pattern]] — state iteration
[[02. What pattern categories exist]] — Behavioral patterns
[[16. What anti-patterns do you know]] — Sequential Coupling
[[01. What are design patterns]] — Behavioral category