Should a State Machine need to expose its current state?

Question

We use a State Machine 'framework' (based on the State Pattern) which doesn't expose its current state, which sometimes means I have to do things in a roundabout way.

When I questioned this design decision, one of the justifications was that "if you need to know the current state, you're using it wrong".

Is this correct? I'm not much of an expert on state machines.

(I'm asking here because I know I have an inherent bias against the State Pattern, which I find too verbose.)

EXAMPLE

Imagine a system which in one of it states reads two sensors. One sensor gives a numeric value, the other gives a boolean which tells you if the first is 'reliable' or not. The system outputs a value which is either the current 'good' value, or an interpolation (or some other fancy calculation) based on the last n good values.

My idea would be to have two substates - one 'good', the other 'not'. And when a new value arrives, I'd like to ask the state machine which state it's in so that I know how to handle the interpolation.

(I think I've answered my own question: the solution would be to have a NewDataValue(val) event in the state machine, which would only forward the value from the 'good' state?)

Answer 1

I have to agree with the person who made the "using it wrong" comment.

The whole point of a state machine is to be a black box into which events are pumped and which cause certain things to happen based on those events (including state transitions). The events themselves should not depend at all on the current state of the machine.

I cannot envisage a single situation in which the event should change depending on the current state (but feel free to enlighten me if you have one).

An event will always be what it is. If it needs to be treated differently based on the current state, that is an issue for the state machine itself, not the event pump.

In fact, the whole idea of changing an event based on the current state flies in the face of encapsulation.

The best state machines have a very simple form:

                         +------+
                         |      | state
                         V      |  transitions
            +---------------+   |
 events --> |               | --+
            | state machine |
effects <-- |               |
            +---------------+

In other words, events are pumped into it somehow (independent of the state) and it has certain effects based on its state and the events. And it maintains its own state.

---

In terms of the update to your question where you would like to handle the output differently based on whether the last reading was good or a formula based on previous ones, I would just put that in the effects section. Have the state machine output the current value plus an indication as to whether it was from the sensor or calculated.

Then your code which handles the effects can do what it likes with that information. That effectively gives you the information you need and doesn't break the black-box nature.

Answer 2

Well, that's the real question. Why do you need to know the current state of the state machine? What do you plan on doing with it?

If you're second guessing it, that is trying to predict where the state machine will be in the future based on the current state and new inputs, then you're running something in parallel to the state machine. Dunno whether that's good or bad, kind of depends on what and why you're doing it.

Ostensibly, the state machine is a black box (or in some cases, it seems like a slot machine!) that you feed data in to and pull data out of.

Like anything in programming, there's no need for things to be opaque black boxes. Things can always be clear cased boxes that have input slots and output slots, but you can at least see the gears running inside of them. But it is counter to the abstraction if you're trying to work around it, since the state machine is designed to encapsulate a block of logic.

So, the opacity of the structure isn't really the issue, it's what you're trying to do with the information if or when you get it.