Question

I think a good way of implementing a state machine is to use the singleton pattern.
For example it can look like this:

class A
{

private:
    friend class State;
    State* _state;
    void change_state(State* state) { _state = state; }
};

class State
{
    virtual void action(A *a) = 0;
private:
    void change_state(A *a, State *state) { a->change_state(state); }
};

class StateA : public State
{
public:
    static State* get_instance()
    {
        static State *state = new StateA;
        return state;
    }
    virtual void action(A *a) { change_state(a, StateB::get_instance(); }
};

class StateB : public State
{
public:
    ...
    virtual void action(A *a) { change_state(a, StateA::get_instance(); }
};

My question is: I have read many articles about that the singleton pattern is so evil. Implementing this without a singleton pattern you have to call new everytime you change state, so for those who dont like singleton, how would you implement the state machine pattern?

Answer 1

Your StateA, StateB classes have no data members. Presumably other states won’t have modifiable data members either, since if they did then that state would be weirdly shared between different instances of A, that is different state machines running concurrently.

So your singletons have avoided half of the problem with the pattern (global mutable state). In fact with only a small change to your design, you could replace the state classes with functions; replace the pointers to their instances with function pointers; and replace the virtual call to action with a call through the current function pointer. If someone gives you a lot of hassle for using singletons, but you’re confident that your design is correct, you could make this minor change and see if they notice that their “correction” has made no significant difference at all to the design.

The other half of the problem with singletons still wouldn’t be fixed though, and that’s fixed dependencies. With your singletons, it is not possible to mock StateB in order to test StateA in isolation, or to introduce flexibility when you want to introduce a new state machine to your library which is the same as the current one except that StateA goes to StateC instead of StateB. You may or may not consider that a problem. If you do, then rather than making each state a singleton, you need to make things more configurable.

For example, you could give each state some identifier (a string or perhaps a member of an enum), and for each identifier register a State* somewhere in class A. Then rather than flipping to the singleton instance of StateB, StateA could could flip to whatever state object is used to represent “state B” in this state machine. That could then be a test mock for certain instances. You would still call new once per state per machine, but not once per state change.

In effect, this is still the strategy pattern for class A as in your design. But rather than having a single strategy to move the state machine forward, and continually replace that as the state changes, we have one strategy per state the machine passes through, all with the same interface. Another option in C++, that will work for some uses but not others, is to use (a form of) policy-based design instead of strategies. Then each state is handled by a class (provided as a template argument) rather than an object (set at runtime). The behavior of your state machine is therefore fixed at compile time (as in your current design), but can be configured by changing template arguments rather than by somehow altering or replacing the class StateB. Then you don’t have to call new at all – create a single instance of each state in the state machine, as a data member, use a pointer to one of those to represent the current state, and make a virtual call on it as before. Policy-based design doesn’t usually need virtual calls, because usually the separate policies are completely independent, whereas here they implement a common interface and we select between them at runtime.

All of this assumes that A knows about a finite set of states. This may not be realistic (for example, A might represent an all-purpose programmable state machine that should accept an arbitrary number of arbitrary states). In that case, you need a way to build up your states: first create an instance of StateA and an instance of StateB. Since each state has one exit path, each state object should have one data member which is a pointer to the new state. So having created the states, set the StateA instances “next state” to the instance of StateB and vice-versa. Finally, set A’s current state data member to the instance of StateA, and start it running. Note that when you do this, you are creating a cyclic graph of dependencies, so to avoid memory leaks you might have to take special resource-handling measures beyond reference-counting.