责任链与有限状态机 - 差异

Question

因此，作为一名电工和程序员，我认为我非常了解 FSM 设计模式。它是：

• 我们有一组Nodes，
• 每个Node都知道，当程序在这个节点时，该做什么，
• 每个Nodecontains references to another chosen nodes，并且知道在什么条件下，他应该继续选择的那个。
• 在event 或after processing 一个节点上，Node proceeds 到下一个选择的节点

我想，这对我来说很清楚。虽然最近，当我实施状态机时，一个人告诉我，它实际上是一个有点修改的责任链（不确定他是否正确），我所做/拥有的是：

• Nodes 集（不代表线性或树形结构）
• 节点有对象，知道在什么条件下应该跳转到哪个节点
• 每个节点都有其自己的处理上下文（部分上下文在节点之间共享）。

很遗憾，由于法律问题，我不能在此处粘贴类图。

---

另一方面，我们有责任链，我会（据我了解）用以下方式定义，即：

• 我们有一些ItemToProcess接口，
• 我们有一些Node接口，
• Node 引用了只有一个下一个 Node，
• 每个节点处理ItemToProcess并将处理过的一个转发到nextNode

据我所知：

• 我们使用Chain Of Responsibility，我们希望每个节点处理（或至少尝试处理）一个项
• 责任链代表顺序和持续流程的执行
• 我们使用StateMachine 来表示图形
• 我们使用StateMachine 执行计算，根据某些事件，计算的顺序或种类可能会有所不同。

我想请你确认我对这些设计模式的理解，或者告诉我我在哪里理解错误。

Answer 1

我将通过说设计模式还考虑使软件易于扩展来补充另一个答案。

责任链的优势在于能够编写新的ConcreteHandler 类来扩展您的处理功能，而无需修改Client 类。

但是，必须修改构建链的代码以将新处理程序添加为对象：

如果您想添加新的具体状态，

State 就没有那么灵活了。 GoF 书显示了此图：

不明显（在this answer 中阅读更多内容）是Handle() 事件与另一个ConcreteState 类（即下一个状态）耦合。因此，编写新的ConcreteState 可能需要更改部分或全部现有ConcreteState 类。

在状态模式中添加新状态可能不像在责任链模式中添加新处理程序那么容易。

Answer 2

你的理解是正确的。

我要补充一点，FSM 中的节点是不同的状态。当您切换到其他节点时，您会更改状态。您可以连续多次调用同一个状态/节点。

责任链没有不同的状态。正如您所说，链中的每个节点都尝试处理一个对象，如果一个节点成功处理了该对象，那么通常链会停止。

责任链的常见用途是查找用于确定对给定输入（例如文件类型或扩展名）使用什么 Handler 或在类路径或资源定位器中查找项目。您可以将这些类型的操作视为：

[Node 1]

"-Do you know what this is?"
-No
[Node 2]
"-Do you know what this is?"
-No
[Node 3]
"-Do you know what this is?"
-Yes!

完成