Display for a pedestrian crossing in Bristol © Kevlin Henney
Some objects in a system are inherently state-driven: entire methods, or significant portions of them, behave differently depending on their current state. Such object lifecycles are often best implemented in terms of state machines, which allow explicit modeling of—and control over—their modal behavior. This chapter presents three patterns that support the implementation of state machines, considering trade-offs such as solution complexity, performance, memory usage, and internal versus external control of state change.
There are many ways to implement state-driven lifecycles for an object. Sometimes simple flags and conditional statements within the object's method control flow are enough. Sometimes, however, many or all of an object's methods can behave entirely differently in different object states. Such a lifecycle is often modeled as a state machine, but in implementation a developer faces many choices, and some design paths lead to unnecessarily complex implementations. The following issues influence the choice and shape of the solution:
Minimizing conditionals. Gigantic
switch statements and long
if else if cascades are often inappropriate for capturing stateful life-cycle behavior because of the accidental complexity they introduce. Anything more than a few conditional cases becomes hard ...