Finite State Machine Patterns

By: S. Yacoub, H. Anmar
Published in: PLoPD4
Pages: 413-440
Category: Finite State Machines

Summary: An extension of State Patterns and Three-Level FSM to implement a state machine in an object-oriented design.

An extension of State Patterns and Three-Level FSM to implement a state machine in an object-oriented design.

Pattern: Basic FSM

Pages: 417-420

An object's state changes in response to events in the system. To implement the correct object behavior, use State [Gamma+95] and add one of the state transition mechanisms of State Patterns

Pattern: State-Driven Transition

Pages: 421-423

To get a state object to change when the owning object's state changes, have the state object initiate the transition from itself (the current state) to the new state object. This ensures that transitions are atomic and removes state-dependent code.

• This is the same pattern as State-Driven Transitions
• This pattern is a refinement of State [Gamma+95]

Pattern: Interface Organization

Pages: 423-426

To enable communication between entities when the behavior of one is described by an FSM, encapsulate the state classes and state-transition logic in the machine, and provide a simple interface that receives events.

• This motives you to use State-Driven Transition to simplify tasks required by the interface by delegating state transition logic to the states themselves.

Pattern: Layered Organization

Pages: 426-428

You're using an FSM. To make your design maintainable, structure the system in layers that decouple the logic of state transition from object behavior.

• This pattern is an extension of Three-Level FSM
• A Hierarchy of Control Layers, Four-Layer Architecture, Layered Architecture[Shaw95], Layered and Sectioned Architecture, Layers, Pedestal, Shape of Program, Three-Tier Architecture

Pattern: Meally

Pages: 428-430

To begin FSM output, make the concrete event method of each state call the output action method.

• Hybrid and Moore offer solutions for related problems.

Pattern: Moore

Pages: 430-432

To begin FSM output produced only at state entry when each state has a specific set of outputs, implement an output method in each state that calls the required actions. Make the state transition mechanism call the output method of the next upcoming state.

• Hybrid and Meally offer solutions for related problems.

Pattern: Hybrid

Pages: 433

If some FSM outputs are started on events and other outputs are started only in a given state, make the event method of each state produce the event-dependent outputs, and make the state transition mechanism call an output method of the upcoming state to produce the state-dependent output.

• Meally and Moore offer solutions for related problems.

Pattern: Encapsulated State

Pages: 434

Your FSM should follow a sequence of state changes. To ensure that no other state changes are imposed, encapsulate the current state and keep the reference private.

• Exposed State offers a different approach.

Pattern: Dynamic State Instantiation

Pages: 435-437

Your application is large, with too many states. To instantiate them, don't initially create all states. Make each state knowledgeable of upcoming states, and create instances of them on state entry and delete them on state exit.