如果在 programmers.stackexchange 上提出问题，请移动它或通知我。
想象一个程序，其唯一目的是使用传感器测量温度。有两个输入，传感器和用户(用户可以按下中止按钮)。
程序启动时，必须满足某些条件。假设传感器的温度不得高于 x。如果满足条件，程序将继续下一步，如果不满足，则告知用户确保满足条件。
一旦满足，用户就会看到下一步要做的事情，比如“现在将传感器插入您要测量的物体中”。 该程序现在测量。假设此过程需要的不仅仅是传感器的快照，还需要一些相当复杂的过滤等。一旦满足特定条件，就会告知用户下一步该做什么。
在某个时候，用户会看到结果。 用户可以随时决定中止整个过程(返回开始或关闭)。
我为此苦苦挣扎的原因是，如果在某个时候引入了另一个步骤，或者删除了某个步骤，但它们将始终遵循相同的工作流程怎么办。我正处于一个新程序的开始，我想创建一个可维护的系统。
我不确定状态机是否是一个很好的解决方案，或者我是否完全误解了状态机的用途，或者是否有更简单的解决方案。
最佳答案
在松散的定义下，您编写的任何程序都可以归类为状态机。当程序从一行代码移动到另一行代码时，以及随着变量值的改变，您的程序会改变状态。
当我们谈论使用状态机作为设计模式时，它通常涉及将主要状态转换分离到单独的模块(类)中，其中每个对象的字段存储它感兴趣的状态信息及其主要执行方法处理当前状态的主要任务，然后返回有关您应该进入的下一个状态的信息。主控制循环调用每个状态的主要执行方法，直到返回定义的结束状态。
此模式的优点是可以紧密反射(reflect)您可能在 Visio 或类似工具中创建的可视化工作流程的结构。当程序的每个主要状态具有截然不同的职责时，这有助于您按照单一职责原则自然地对代码进行分组。当每个状态只能进入一个或两个其他状态时，您最终会得到相对松散耦合的代码，这也有助于使事情更易于维护。
您描述的程序似乎很适合这种模式。
- 听起来它会很复杂，您不想在单个类或方法中定义整个工作流。
- 听起来每个州都允许您搬到有限数量的其他州。
- 听起来每个州的预期操作都不同，足以值得他们自己的类(class)。如果对工作流进行更改，它们可能会影响一个或两个状态，而不是整个工作流，因此以这种方式拆分类是有意义的。
关于java - 当必须以明确的顺序执行某些步骤时，状态机是否是合适的设计？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20503526/