The Role of State Machines

On occasion, software requirements are specified with formal state machines. For example, the Java Telephony API specification includes a state-transition diagram that defines the states through which a single call can progress. Nevertheless, software requirements are most often specified with human language descriptions, not with state machines.

The complexity of most objects makes it impractical to define their behavior solely in terms of state machines. The stamp dispenser's behavior can be specified in terms of a state machine primarily because it is a contrived example. I purposely chose this example to illustrate the kinship between mutable objects and state machines. The requirements of a real-world stamp dispenser would be far more complex, and therefore far less practical to describe in terms of a state machine. Most objects simply have too many possible states.

The StampDispenser has one instance variable, balance, which is an int. The class enforces that this int will ever have only one of four possible values: 0, 5, 10, or 15. It is practical to fully describe the behavior of StampDispenser objects in terms of a state machine because the object has only four possible states. If the class where written such that the balance variable could take on any possible value for an int, the class would have 2**32 possible states. That's already too many states to make it practical to describe the class's behavior fully in terms of a state machine. Even more impractical, describing the behavior of many mutable objects in exclusively state machine terms would require in effect an infinite number of possible states.

I bring up state machines to flesh out the object-as-machine metaphor -- to give you a better feel for the kind of machine you are designing when you design an object. Mutable service-oriented objects act like state machines, often with an infinite number of possible states. Invoking a method on an object corresponds to sending a message to a state machine. When a method is invoked, the object, like the state machine, potentially performs actions and changes state.

I will discuss the relationship between objects and state machines further in the context of the state pattern in Guideline ?.