他のパターン
の説明を
読んでください 。

問題
潜在的に多数のハンドラーを備えたシステムでイベント/リクエスト/メッセージのフローを処理するメカニズムを効果的かつコンパクトに実装します。
説明
イベント/ハンドラモデルは、さまざまな分野のソフトウェアシステムで広く使用されています。 基本的に、これはユーザーアクションによって生成されたイベントがインターフェイス要素によってさまざまな方法で処理されるグラフィカルユーザーインターフェイスです。 このようなモデルを頻繁に実装するWinAPIを忘れてはなりません。 ほとんどのソースでは、このモデルは
イベントループと呼ばれ
ます 。
一方では、すべてが非常に透明です。 メッセージには多くの種類があり、これらのメッセージには多くのハンドラがあります。 タスクは、ストリーム内の各メッセージを、特定のタイプの関連プロセッサーで処理することです。 簡単に言えば、メッセージタイプとハンドラーをリンクするための効果的なメカニズムが必要です。
ほとんどの場合、システム内に少数のハンドラーが固定されているため、if-then-else構造に基づいてこのメカニズムを実装するだけで十分です。 ただし、必ずしもそれほど単純ではありません。 まず、必要なハンドラーの数が事前に正確に常にわかっているわけではありません。 第二に、システムに新しいタイプのメッセージを追加すると、通常、新しいハンドラーが出現しますが、その導入はすでに非常に難しいタスクになっています。
このような問題を解決するために、「責任の連鎖」というテンプレートがあります。
テンプレートの考え方は、各ハンドラーが着信メッセージ(特定のタイプのメッセージのみなど)を処理するか、パイプライン内の次のハンドラーに処理を委任できる、ハンドラーの反復パイプラインを編成することです。 処理のさらなる変形とその後の送信が可能です。 同時に、特定のメッセージの処理を開始するために、クライアントはそれをパイプラインの最初のプロセッサに渡すだけで済みます。
実用例
おそらくテンプレートの最も明白な例-コンピューターネットワークを考えてみてください。 確かに-多数のハンドラー-ネットワークノード(コンピューター、サーバー、ルーター)および多数の種類のネットワーク要求。
単純化された架空のネットワークモデルには、ネットワーク、ルーター、フォワーダー、サーバーの4種類のプロセッサがあると仮定します。 そのため、サーバー処理の要求という1種類の要求しかありません。 ハンドラーの動作は次のとおりです。ネットワークは単にその環境でリクエストを送信し、ルーターはネットワーク間でリクエストを送信し、フォワーダーは特定のホストにリクエストを送信し、サーバーはリクエストを処理します。
ホストはプロセッサのパイプラインです。 要求は特定のメッセージです。 チェーンに沿って移動する要求は、各ノードによって処理(ルーティング、転送)され、渡されます。 最終的にサーバーによって処理されるまで。
クラス図
注目すべき主なポイントは、コンベア処理を整理する方法です。 この場合、次のアプローチが使用されます。 すべてのハンドラーは、パイプラインの次のハンドラーに処理責任を委任するための自身(後続)への参照を含む1つの抽象クラスRequestHandledを実装します。 handleRequest()メソッドの実装は、デフォルトでそのような委任を実装します。

C ++実装
PS
気配りのある読者はこう言います-「ああ! 私はすでにこの男の記事を読んでいます!」 そうです、私はデザインパターンに関する一連の記事を続けることにしました。フィードバックをお待ちしています。