Question

I have a C++ state machine implemented using the State design pattern. Each state is implemented as a nested friend class of the context class.

class Context {
public:
  /* The Context class' user calls process1() to get it to perform an action */
  void process1();

private:
  class IState;

  void switchState( IState *newState );

  class IState {
    virtual void doProcess( Context &context ) = 0;
  };

  class StateA : public Context::IState {
    void doProcess( Context &context );
  };
  friend class StateA;

  class StateB : public Context::IState {
    void doProcess( Context &context );
  };
  friend class StateB;
  .
  .
  .
  class StateJ : public Context::IState {
    void doProcess( Context &context );
  };
  friend class StateJ;
};

Currently, a successful iteration of the state machine runs from Context::StateA to Context::StateJ when Context::process1() is called but some of the states contain internal logic to determine whether to loop back to an earlier state. So a typical execution will look like:

StateA
StateB
StateC
StateD
StateE
StateC
StateD
StateE
StateF
StateG
StateH
StateI
StateJ

The internal logic to determine next state is currently being implemented by the respective state itself by storing data in the context object. What I need to do now is add a Context::process2() option that significantly differs in the order of execution of states. Of course, this can be done using flags that are set in the context object but I was wondering if there is better way to implement this; maybe even use this method to rewrite the handling of state switches within Context::process2().

The Visitor design pattern might do the trick but I’m not sure whether its intended for implementing state machines. When using Visitor, process1() could contain all logic for the order of execution of states and then just call each state in that order. Similarly, process2() would handle all of its own logic.

EDIT:
To those of you that replied saying I should be creating a separate state machine, the reason I’m looking to avoid that is because the code for the states used by the second state machine is identical to those in the first; only the progression is different.

The second state machine will go through the following state transitions:

StateA
StateB
StateC
StateJ

So I’m trying to eliminate duplicated code.

Answer 1

I assume that in your code, switchState is invoked by the individual states when it’s time to transition to something else. Something like this:

void StateA::doProcess(Context& context) {
   context.switchState(new StateB()); // NOTE: potential leak!
}

Is this the case?

If so, one thing you might consider is having the states return transition objects that abstractly represent a control point in your state graph. You then have the Context run a loop which executes the states, retrieves the resulting transitions, and maps the transitions to the appropriate next states for whatever process you have. The transition map can be set up differently for each process method that you have.

Pros:

• States don’t have to know about each other. The transition is their declaration to the world of what they’ve done. It’s up to the context to route between the states in appropriate ways. This could make the states reusable across different Context objects, for example.
• Allows the idea of “same structure, slightly different behavior” by allowing the context to essentially maintain the same state graph, but plug in a slightly different state with a compatible transition interface as the target of a particular transition.

Cons:

• Adds an extra layer of stuff to set up. Transition mapping code is mostly boilerplate. Tools to generate the boilerplate may help.
• Doesn’t help you if you really want to do something radically different in the two processes which the states don’t have the right transitions to support – but then, you’re trying to reuse at the wrong level – you probably want different state objects at that point.

EDIT: Sample code is up at http://pastebin.com/eBauP060 .