I can’t dance to a cold machine (Chris Rea)

Deterministic vs. non-deterministic state machine

When using a state machine in you design you can use either deterministic or non-deterministic state machine. Following a work discussion I had regarding this issue few conclusions follows.

Non deterministic state machine

In this machine design, each state is “allowed” to have internal logic and be stateful in order to determine the next state to go to following an event. So the main interface will be:

State onEvent(Event e)

Deterministic state machine

In this style of machine, there’s a finite, pre-defined list of transitions, that fully determine the next state to go to following an event. So, each state can handle events by running code, but the next state to go to is predefined and known by explicit declaration. Hence, the interface will look like this:

Void onEvent(Event e)

What design is better ? I think they both good and each one has pros and cons.

I think the main differentiator between the two designs is that in a deterministic state machine , for a given series of events, you know what code runs without looking at the code, achieving this only by checking the transition map. This is not the case for non-deterministic machine because states’ internal logic determine the next state so you must read code to know what’s the next state that the machine will transit to.

State’s internal logic

The above main difference outcome is that in deterministic machines, you must use machine states and events to implement one state’s logic while in non-deterministic one, a state’s internal logic can be kept internal and the machine states and event can be fewer and in higher resemblance to the real physical world events.

Code coordination with EventBus

Using an event bus has great benefits. The main challenge though is how to coordinate code when one component has dependencies on other’s outcome. The ways I found most convenient are:

  1. Use different message types for different steps of the required flow. This means to divide the flow to steps, each section will use its own message type. This way only when step A finishes, it will issue a step B message.
  2. Use ordered delivery and priorities to decide which code runs first.
    Each run code can either:

    1. Cancel the delivery to lower priority handlers.
    2. “Stamp” the event so the decision on how to continue is done on the next handlers. Stamping can be made on real member fields or using a generalized stamping methods by name.
  3. Both 🙂 This means a flow is first divided into main steps using method 1 and then inside each step we can use method 2 to avoid too many message types.