We ordinarily view the world as populated by independent objects, each
of which has a state that changes over time. An object is said to
have state if its behavior is influenced by its history.
A bank account, for example, has state in that the answer to the question
Can I withdraw $100? depends upon the history of
deposit and withdrawal transactions. We can characterize an
object's state by one or more
state variables, which among them maintain enough
information about history to determine the object's current behavior.
In a simple banking system, we could characterize the state of an
account by a current balance rather than by remembering the entire
history of account transactions.
In a system composed of many objects, the objects are rarely
completely independent. Each may influence the states of others
through interactions, which serve to couple the state variables of one
object to those of other objects. Indeed, the view that a system is
composed of separate objects is most useful when the state variables
of the system can be grouped into closely coupled subsystems that are
only loosely coupled to other subsystems.
This view of a system can be a powerful framework for organizing
computational models of the system. For such a model to be modular,
it should be decomposed into computational objects that model the
actual objects in the system. Each computational object must have its
own local state variables describing the actual object's
state. Since the states of objects in the system being modeled change over
time, the state variables of the corresponding computational objects
must also change. If we choose to model the flow of time in the
system by the elapsed time in the computer, then we must have a way to
construct computational objects whose behaviors change as our programs
run. In particular, if we wish to model state variables by ordinary
symbolic names in the programming language, then the language must
to enable us to change the value
associated with a name.
3.1 Assignment and Local State