design-patterns - 状态机是否需要公开其当前状态？

Question

我们使用不公开其当前状态的状态机“框架”(基于状态模式)，这有时意味着我必须以迂回的方式做事。

当我质疑这个设计决定时，理由之一是“如果你需要知道当前状态，你就错了”。

这样对吗？我不是状态机方面的专家。

(我在这里问是因为我知道我对状态模式有固有的偏见，我觉得它太冗长了。)

示例

想象一个系统，其中一个状态读取两个传感器。一个传感器给出一个数值，另一个给出一个 bool 值，告诉你第一个是否“可靠”。系统输出一个值，该值要么是当前的“好”值，要么是基于最后 n 个好值的插值(或其他一些花哨的计算)。

我的想法是有两个子状态 - 一个“好”，另一个“不是”。当一个新值到达时，我想询问状态机它处于哪个状态，以便我知道如何处理插值。

(我想我已经回答了我自己的问题:解决方案是在状态机中有一个 NewDataValue(val) 事件，它只会转发来自“良好”状态的值？)

Answer 1

我必须同意提出“使用错误”评论的人。

状态机的全部意义在于成为一个黑匣子，事件被泵入其中，并根据这些事件(包括状态转换)导致某些事情发生。事件本身不应该完全依赖于机器的当前状态。

我无法想象事件应该根据当前状态而改变的单一情况(但如果你有的话，请随时启发我)。

事件将永远是它的样子。如果需要根据当前状态对其进行不同的处理，那是状态机本身的问题，而不是事件泵的问题。

事实上，基于当前状态改变事件的整个想法与封装相悖。

最好的状态机有一个非常简单的形式:

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

换句话说，事件以某种方式(独立于状态)被泵入其中，并且基于其状态和事件具有一定的影响。并且它保持自己的状态。

就您的问题的更新而言，您希望根据上次读数是否良好或基于先前读数的公式以不同方式处理输出，我会将其放在效果部分。让状态机输出当前值以及关于它是来自传感器还是计算出来的指示。

然后你的处理效果的代码可以用这些信息做它喜欢的事情。这有效地为您提供了所需的信息，并且不会破坏黑盒性质。