I. State — Behavioral Pattern

State lets an object change its behavior when its internal state changes, as if the object had switched to a different class. Instead of one big method full of if status == "pending" / else if status == "brewing" branches, each state is extracted into its own type that implements a shared interface, and the object simply delegates to whichever state it currently holds.

The problem this solves is state-conditional logic that grows unbounded. As more states and more transitions are added, a single method with branching logic becomes harder to read and easier to break — forgetting to update one branch when a new state is introduced is a common source of bugs. With State, adding a new state means adding a new type, not touching the existing ones.

It also makes illegal transitions explicit: a state simply doesn't provide a transition to a state it shouldn't reach.

II. Real-world Example

A coffee order that moves through a fixed lifecycle:

1. Order (Context) — holds a reference to its current OrderState and delegates Advance() and Status() to it. It doesn't contain any state-specific logic itself.

2. OrderState (interface) — declares Next(order *Order) string and Status() string, the contract every state must implement.

3. PendingState — the order's starting state; advancing moves it to Brewing.

4. BrewingState — the drink is being made; advancing moves it to Served.

5. ServedState — the terminal state; advancing does nothing further, the order is done.

Each state decides for itself what the next state is — Order never needs to know the full lifecycle graph.

III. Implementation

order_state.go

1package state
2
3type OrderState interface {
4	Next(order *Order) string
5	Status() string
6}

order.go

1package state
2
3type Order struct {
4	ID    string
5	Drink string
6	state OrderState
7}
8
9func NewOrder(id string, drink string) *Order {
10	order := &Order{
11		ID:    id,
12		Drink: drink,
13	}
14	order.state = &PendingState{order: order}
15	return order
16}
17
18func (o *Order) Advance() string {
19	return o.state.Next(o)
20}
21
22func (o *Order) Status() string {
23	return o.state.Status()
24}
25
26func (o *Order) setState(state OrderState) {
27	o.state = state
28}

order_states.go

1package state
2
3type PendingState struct {
4	order *Order
5}
6
7func (s *PendingState) Next(order *Order) string {
8	order.setState(&BrewingState{order: order})
9	return "Order accepted, brewing started"
10}
11
12func (s *PendingState) Status() string {
13	return "Pending"
14}
15
16type BrewingState struct {
17	order *Order
18}
19
20func (s *BrewingState) Next(order *Order) string {
21	order.setState(&ServedState{order: order})
22	return "Drink is ready"
23}
24
25func (s *BrewingState) Status() string {
26	return "Brewing"
27}
28
29type ServedState struct {
30	order *Order
31}
32
33func (s *ServedState) Next(order *Order) string {
34	return "Order already served"
35}
36
37func (s *ServedState) Status() string {
38	return "Served"
39}

main.go (usage)

1order := state.NewOrder("ORD-002", "Cappuccino")
2fmt.Println("Status:", order.Status())
3fmt.Println(order.Advance())
4fmt.Println("Status:", order.Status())
5fmt.Println(order.Advance())
6fmt.Println("Status:", order.Status())

IV. Explain the example above

1. state.NewOrder("ORD-002", "Cappuccino") creates an Order and sets its initial state to &PendingState{order: order}.

2. order.Status() delegates to the current state's Status() — at this point, PendingState.Status() returns "Pending".

3. order.Advance() calls PendingState.Next(order), which calls order.setState(&BrewingState{order: order}) to swap the internal state pointer, then returns a message describing the transition.

4. order.Status() now delegates to BrewingState.Status(), returning "Brewing".

5. order.Advance() again calls the current state's Next — now BrewingState.Next — which swaps to ServedState and returns its own message.

6. order.Status() finally returns "Served".

Running it produces:

1*** Example State ***
2Status: Pending
3Order accepted, brewing started
4Status: Brewing
5Drink is ready
6Status: Served
7*** End of State ***

Notice that Order.Advance() never changes — it always just calls o.state.Next(o). All the branching lives inside the state types themselves, and ServedState.Next is a natural place to guard against advancing past the terminal state.

V. Conclusion

State is worth reaching for when an object's behavior depends heavily on which "mode" it's in, and that set of modes is stable enough to model as types — order lifecycles, connection states, game character states, and similar finite-state workflows are a good fit. It trades a single method with visible branching for several small types, which makes each transition easy to reason about in isolation but harder to see the whole state machine at a glance without reading every state type.

For two or three states that rarely change, a plain enum with a switch statement is often simpler and easier to grep than a full State pattern implementation. The pattern earns its keep once the number of states or transitions grows enough that the switch statement itself becomes the maintenance burden.

No pattern is universally superior.

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Source code on GitHub