design-patterns - 責任の連鎖と有限状態マシン - 違い

Question

私は少し電気技師でプログラマーなので、FSM の設計パターンをよく知っていると思っていました。それは：

• のセットがありますNodes。
• プログラムがこのノードにあるとき、それぞれNodeが何をすべきかを知っています。
• それぞれNode contains references to another chosen nodesが、どのような条件の下で、選択したものに進むべきかを知っています。
• eventまたはafter processingノード上で、Node proceeds次に選択されたノードへ

私にはそれが非常に明確だと思いました。最近、私がステートマシンを実装していたとき、ある人が私に言ったのですが、それは実際には少し変更された責任の連鎖であり(彼が正しいかどうかはわかりません)、私がしたこと/持っていたことは次のとおりでした:

• のセットNodes(線形またはツリー構造を表していない)
• ノードには、どの条件でどのノードにジャンプするかを知っているオブジェクトがありました
• 各ノードには独自の処理コンテキストがありました (コンテキストの一部はノード間で共有されていました)。

残念ながら、法的な問題により、ここにクラス図を貼り付けることはできません。

---

一方で、私たちは責任の連鎖を持っています。これは（私が理解しているように）次のように定義します。

• 私たちはいくつかのItemToProcessインターフェースを持っています。
• 私たちはいくつかのNodeインターフェースを持っています。
• ノードは、次の1 つのノードのみへの参照を持ちます。
• 各ノードが処理ItemToProcessし、処理された 1 つをnextNode

だから私が理解している限り：

• を使用Chain Of Responsibilityします。各ノードで1 つのアイテムを処理する (または少なくとも処理を試行する) 必要があります。
• 一連の責任は、プロセスの連続的かつ継続的な実行を表します
• StateMachineグラフを表すために使用します
• 計算を実行するために使用StateMachineしますが、計算の順序または種類は、いくつかのイベントによって異なる場合があります。

これらの設計パターンの理解を確認するか、どこが間違っているかを教えてください。

Answer 1

デザインパターンはソフトウェアを簡単に拡張できるようにすることも考慮していると言って、他の答えを補足します。

責任の連鎖にはConcreteHandler、クラスを変更することなく、新しいクラスをコーディングして処理機能を拡張できるという利点がありますClient。

ただし、チェーンを構築するコードを変更して、新しいハンドラーをオブジェクトとして追加する必要があります。

新しい具体的な状態を追加したい場合、状態はそれほど柔軟ではありません。GoF ブックには、次の図が示されています。

明らかでないのは (この回答で詳細を読む)、イベントが別のクラス (つまり、次の状態) にHandle()結合されていることです。ConcreteStateそのため、新しいクラスをコーディングするConcreteStateには、既存のクラスの一部またはすべてを変更する必要がありConcreteStateます。

State パターンに新しい状態を追加するのは、Chain of Responsibility パターンに新しいハンドラーを追加するほど簡単ではないかもしれません。