That's not bad. One limitation is that is probably a builder pattern, creating an object that runs an arbitrary state machine. (I suppose it could be a method

That's not bad. One limitation is that is probably a builder pattern, creating an object that runs an arbitrary state machine. (I suppose it could be a method repeated rerun, where fsm is a wrapper around the current state, and method calls that don't apply return a null object singleton, but that seems less likely). If so it will have a few downsides, like extra memory needed to build up the transition table(s), and possibly being less efficient in executing than a hard coded implementation, simply because the FSM type would need to implement code for arbitrary FSMs, meaning potentially less efficient than scenario specific implementation. In many scenarios this additional overhead is probably not a big concern, and the increased maintainability vs some other styles of coding FSMs may be well worth it. I'd guess the built up data structure data structure would be something like a dictionary that maps from the current state to a dictionary that maps from trigger conditions (or commands in the code above), to a struct that contains the new state, and optionally a transition action function pointer (or delegate, or whatever your language calls them). One of the interesting things about FSMs is that there are many ways to code them. I've also seen an thin wrapper around state object with methods for all transition actions, said methods being mostly a switch statement (or if/else chain) around the current state, setting the new one and possibly calling an transition action. Plus of course there are plenty of ways to code an FSM such that its existence is more implicit than explicit, where the main hint that an FSM exists at all the existence of a variable named state.