3

I need to implement a non-deterministic FSM, so I came up with the idea of defining an FSM class that holds states and transitions (that may or may not depend on the states of other FSMs, but must depend on events/input) for each object and adding a static std::map to the class that every FSM would register with on construction. This way, on events/input each FSM can look up the state of other FSMs if needed and behave accordingly without combining all the FSMs into one huge deterministic FSM.

This works for one NFSM, which is all I need now, but can in be extended if more are needed? Is there anything fundamentally wrong with this design?

albizgil
  • 103
  • 6
  • 2
    why would it be static and not an instance variable? If I create two FSM objects shouldn't that mean I have two independent state machines? – Kevin Dec 09 '11 at 15:55

1 Answers1

3

I am very unsure about the static part- a map seems a good idea. It seems more reasonable to make a namespace object that holds the map for all related FSMs (i.e. those that interact with each other) because it is reasonable to assume that you might want different sets of machines that can be run independently (with thread safety) in many contexts.

The static map is an example of a singleton which is generally understood to have a bad code smell.

Elemental
  • 7,365
  • 2
  • 28
  • 33