Blog root page
previous post in category
next post in category
State machines were employed to describe behavior in R-T/E development long before OO development existed. That's because the rules for finite state machines enforce a number of Good Practices that are a matter of survival in the very unforgiving world of R-T/E. In addition, finite state machines are ideally suited for design-by-contract (DbC) construction of software.
The rules for finite state machines require that a state cannot know what the previous state was or what the next state will be. That necessarily means that the action associated with a state cannot be dependent in any way on actions in other states. This implementation independence essentially removes the single greatest problem of traditional procedural code -- hierarchical implementation dependencies that led to the legendary Spaghetti Code.
The independence of state actions from other state actions maps very nicely into OO fundamentals. That context independence means the action is self-contained and encapsulated. Thus its implementation is hidden from other actions and objects. Since the action can't know anything about the sequence of state transitions, it can only describe behavior that is intrinsic to the state. That maps nicely into the notion that objects abstract intrinsic properties of problem space entities.
But the mapping to OO development doesn't stop there. State actions are executed as the state machine transitions into a state. That transition is triggered by an event generated elsewhere (usually an action executed in another state machine). That represents an interaction or collaboration between state machines and the event is a message that initiates that collaboration. This is exactly what happens in OO collaboration. In particular, the message is conceptually a quite different critter than the state action that executes in response to the transition.
This same separation of message and method is fundamental to OOA/D construction. In addition, the event maps conveniently into an interface for the state machine. If the state machine represents the life cycle of a single object, then the events that the state machine accepts define the behavioral interface to the object.
Finally, because events are generated in an ideal finite state machine without knowing where they are going, events map very nicely into the notion of DbC and peer-to-peer collaboration that are also fundamental to good OO development. (I will go into more detail about DbC in another post in this category.)
Blog root page
previous post in category
next post in category
