状态机是否需要公开其当前状态？
我们使用状态机“框架”（基于状态模式），它不会公开其当前状态，这有时意味着我必须以迂回的方式做事。
当我质疑这个设计决策时，理由之一是“如果你需要知道当前状态，那么你就用错了”。
这是正确的吗？我不是状态机方面的专家。
（我在这里问是因为我知道我对状态模式有一种固有的偏见，我发现状态模式太冗长了。）
示例
想象一个系统，其中一个状态读取两个传感器。一个传感器给出一个数值，另一个传感器给出一个布尔值，告诉您第一个传感器是否“可靠”。系统输出的值要么是当前的“好”值，要么是基于最后n个好值的插值（或其他一些奇特的计算）。
我的想法是有两种子状态——一种是“好”，另一种是“不好”。当新值到达时，我想询问状态机它处于哪个状态，以便我知道如何处理插值。
（我想我已经回答了我自己的问题：解决方案是在状态机中添加一个 NewDataValue(val) 事件，该事件只会转发来自“良好”状态的值？）
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?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我必须同意那个提出“错误使用”评论的人。
状态机的全部意义在于成为一个黑匣子，事件被注入其中，并根据这些事件（包括状态转换）导致某些事情发生。事件本身根本不应该依赖于机器的当前状态。
我无法想象事件会根据当前状态而改变的单一情况（但如果您有这样的情况，请随时启发我）。
事件永远就是它本来的样子。如果需要根据当前状态对其进行不同的处理，那么这是状态机本身的问题，而不是事件泵的问题。
事实上，根据当前状态更改事件的整个想法与封装背道而驰。
最好的状态机具有非常简单的形式：
换句话说，事件以某种方式（独立于状态）注入其中，并且它根据其状态和事件产生某些影响。并且它保持自己的状态。
就您的问题的更新而言，您希望根据上次读数是否良好或基于先前读数的公式来以不同方式处理输出，我只是将其放在效果部分中。让状态机输出当前值加上有关该值是来自传感器还是计算得出的指示。
然后处理效果的代码就可以利用这些信息做它喜欢做的事情。这有效地为您提供了所需的信息，并且不会破坏黑匣子的本质。
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:
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.
嗯，这才是真正的问题。为什么需要知道状态机的当前状态？你打算用它做什么？
如果您再次猜测，那就是尝试根据当前状态和新输入来预测状态机将来的位置，那么您正在与状态机并行运行某些内容。不知道这是好还是坏，这取决于你这样做的目的和目的。
表面上，状态机是一个黑匣子（或者在某些情况下，它看起来像一台老虎机！），您可以将数据输入其中并从中取出数据。
就像编程中的任何事情一样，事情不需要是不透明的黑匣子。东西总是可以是带有输入槽和输出槽的透明盒子，但你至少可以看到里面运行的齿轮。但如果您试图解决它，则与抽象相反，因为状态机被设计为封装逻辑块。
因此，结构的不透明度并不是真正的问题，而是当您获得信息时您想要对信息执行的操作。
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.
“如果你需要知道当前状态，那么你就用错了”。 - 没错。
当前状态无法暴露。由于处于指定状态而需要您采取不同行为的所有事物都应该放置在该状态内部（并且仅在那里） - 作为从公共方法调用的私有方法，或者作为公共方法，执行以下操作在其他州没有任何东西（或其他东西）。你的“状态机”必须工作……而你从外面看，不应该知道为什么。
"if you need to know the current state, you're using it wrong". - That's correct.
Current state can not be exposed. All the things that require you to act differently, because of being in specified state, should be placed inside (and only there) of that state - as private methods called from public ones, or as public, doing nothing (or something else) in other states. Your "state machine" has to work... and you, looking from outside, shouldn't know why.
在分层系统设计中，通常较高级别的对象仅知道较低级别对象的状态的抽象，例如state_good抽象（完美，可接受，...）和state_bad抽象（failed1，failed2，failed3..）。
在非分层系统中，一个对象准确地了解另一个对象的状态是可以的，特别是当对象被分配不同的任务时。
-贾努斯
In hierarchical systems design usually the higher level object knows only the abstraction of the state of the lower level object e.g. state_good abstracting (perfect, acceptable, ...) and state_bad abstracting (failed1, failed2, failed3..).
In non hierarchical systems it is OK for one object to know precisely the state of another object, especially if objects are assigned dissimilar tasks.
-Janusz