|[an error occurred while processing this directive]|
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.
StampDispenser has one instance
balance, which is an
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
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 ?.
Last Updated: Sunday, May 11, 2003
Copyright © 1996-2003 Artima Software, Inc. All Rights Reserved.
Artima.com is created by Bill Venners