State machines have always fascinated me. There is a clockwork precision to their inner workings that appeals to me on an aesthetic level. They are also an invaluable programming tool. In building libraries and applications, I have returned to them again and again.
A state machine is a model of how something behaves in response to events. It models behavior by making its responses appropriate to the state that it is currently in. How a state machine responds to an event is called a transition. A transition describes what happens when a state machine receives an event based on its current state. Usually, but not always, the way a state machine responds to an event is to take some sort of action and change its state. A state machine will sometimes test a condition to make sure it is true before performing a transition. This is called a guard.
* A state machine is a model of behavior composed of states, events, guards, actions, and transitions.
* A state is a unique condition in which a state machine can exist during its lifetime.
* An event is something that happens to a state machine.
* A transition describes how a state machine behaves in response to an event based on its current state.
* A guard is a condition that must be true before a state machine will perform a transition.
* An action is what a state machine performs during a transition.
This description of state machines introduces several abstract concepts quickly, and is not meant to be formal or complete. It is just a starting point. I will explore what state machines are in a series of posts.
Next post will be about the implementation of State Machines in Adobe Flex with a running code example.