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

Question

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

我们有一套Nodes ,

每个Node知道，当程序在这个节点时，该做什么，

每个Node contains references to another chosen nodes ，并且知道在什么条件下，他应该前往所选择的那个。

在 event或 after processing一个节点，Node proceeds到下一个选择的节点

我想，这对我来说很清楚。虽然最近，当我实现状态机时，一个人告诉我，这实际上是一个有点修改的责任链(不确定他是否正确)并且，我所做/曾经做过的是:

一套Nodes (不代表线性或树结构)

节点有对象，知道在什么条件下应该跳转到哪个节点

每个节点都有它的 自己的上下文 处理(部分上下文在节点之间共享)。

不幸的是，我担心由于法律问题，我不允许在此处粘贴类图。

另一方面，我们有责任链，我会(据我了解)以以下方式定义，即:

我们有一些 ItemToProcess接口(interface)，

我们有一些 Node接口(interface)，

节点有对 的引用只有一个下一个节点，

每个节点处理ItemToProcess并将已处理的一个转发到 nextNode

据我了解:

我们使用 Chain Of Responsibility , 我们想要 一个 处理(或至少尝试处理)的项目每个 节点

责任链代表连续的和恒定的进程的执行

我们使用 StateMachine表示图形

我们使用 StateMachine执行计算，计算的顺序或种类可能会有所不同取决于一些事件。

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

Answer 1

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

责任链的优点是可以编写新的 ConcreteHandler类来扩展您的处理功能，没有 Client必须修改类。



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



如果你想添加新的具体状态，状态就不那么灵活了。 GoF 书显示了此图:



不明显(在 this answer 中阅读更多内容)是 Handle()事件耦合到另一个 ConcreteState类(即下一个状态)。所以，编码一个新的ConcreteState可能需要对现有的部分或全部 ConcreteState 进行更改类。

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