SpecialistOff.NET / Вопросы / Статьи / Фрагменты кода / Резюме / Метки / Помощь / Файлы

Table-Driven State Machine

Метки: python

The advantage of the previous design is that all the information about a state, including the state transition information, is located within the state class itself. This is generally a good design principle.

However, in a pure state machine, the machine can be completely represented by a single state-transition table. This has the advantage of locating all the information about the state machine in a single place, which means that you can more easily create and maintain the table based on a classic state-transition diagram.

The classic state-transition diagram uses a circle to represent each state, and lines from the state pointing to all states that state can transition into. Each transition line is annotated with conditions for transition and an action during transition. Here’s what it looks like:

(Simple State Machine Diagram)

Goals:

• Direct translation of state diagram
• Vector of change: the state diagram representation
• Reasonable implementation
• No excess of states (you could represent every single change with a new state)
• Simplicity and flexibility

Observations:

• States are trivial - no information or functions/data, just an identity
• Not like the State pattern!
• The machine governs the move from state to state
• Similar to flyweight
• Each state may move to many others
• Condition & action functions must also be external to states
• Centralize description in a single table containing all variations, for ease of configuration

Example:

• State Machine & Table-Driven Code
• Implements a vending machine
• Uses several other patterns
• Separates common state-machine code from specific application (like template method)
• Each input causes a seek for appropriate solution (like chain of responsibility)
• Tests and transitions are encapsulated in function objects (objects that hold functions)
• Java constraint: methods are not first-class objects