drastically reduce the number of execution paths through the code, simplify the conditions tested at each branching point, and simplify transitions between different modes of execution.
number of non-overlapping chunks (states), where event responses within each individual chunk depend only on the current event, but no longer on the sequence of past events. In this model, change of behavior (that is, change in response to any event) corresponds to change of state (state transition).
this means that instead of recording the event history in a multitude of variables, you can use just one "state variable" that can take only a limited number of a priori known values.
By crisply defining the state of the system at any given time, a state machine reduces the problem of identifying the execution context to testing just one state variable instead of many variables
it seems very tempting (especially to programmers new to state-machine formalism) to add yet another extended state variable and yet another guard condition (another if or an else) rather than to factor out the related behavior into a new qualitative aspect of the system—the state.
One of the main challenges in becoming an effective state-machine designer is to develop a sense for which parts of the behavior should be captured as the qualitative aspects (the state) and which elements are better left as the quantitative aspects (extended state variables). In general, you should actively look for opportunities to capture the event history (what happened) as the state of the system, instead of a simple record of events stored in extended state variables.
the state-based solution is more robust because the context information is used locally and is discarded as soon as it becomes irrelevant. extended state variable flag needs to be reset before entering another.
Capturing behavior as the qualitative state has its disadvantages and limitations, too. First, the state and transition topology in a state machine must be static and fixed at compile time, which can be too limiting and inflexible. Consequently, state can capture only static aspects of the behavior that are known a priori and are unlikely to change in the future.
the main weakness of the qualitative state, which simply cannot store too much information (such as the wide range of timeouts). Extended state variables and guards are thus a mechanism for adding extra runtime flexibility to state machines.
The most important difference between state machines and flowcharts is that the state machines perform actions only in response to explicit events (they are entirely event driven). In contrast, flowcharts do not need to be triggered by events; rather, they transition from node to node in their graph automatically upon completion of activities.
flowchart describes the progression of some task from beginning to end. A state machine generally has no notion of such a progression. A state in a state machine is an efficient way of specifying a particular behavior, rather than a stage of processing.
these two concepts represent two diametrically opposed programming paradigms: event-driven programming (state machines) and transformational programming (flowcharts). You cannot devise effective state machines without constantly thinking about the available events. In contrast, events are only a secondary concern (if at all) for flowcharts.
only change state in the "switch" (outside of controller) to avoid spaghetti flow as the project grows...
