ビデオ説明リンク（レビュー中...）
1.定義
リクエストの送信者と複数のリクエストプロセッサの結合を回避するために、すべてのリクエストプロセッサは、前のオブジェクトの次のオブジェクトの参照を記憶することによってチェーンにリンクされます。リクエストが発生すると、リクエストに従うことができます。このチェーンは、オブジェクトが処理するまで通過します。責任の連鎖モードで最も重要な点は、クライアントがリクエストを送信した後、プロセッサがそれを処理するまでリクエストがチェーンを介して渡されることです。ここでは、クライアントはどのプロセッサがリクエストを処理するかを気にする必要はありません。その人はその要求を処理します。受信者も送信者も互いに関する明確な情報を持たず、受信者は責任の連鎖の構造を知りません。したがって、一連の責任により、オブジェクトの相互接続が簡素化され、すべての候補ではなく、後継者への参照を保存するだけで済みます。同時に、処理要求の構造をいつでもどこでも追加または変更したり、プロセッサの順序を変更したりすることもできるため、システムの柔軟性が向上します。処理の柔軟性は向上しますが、要求が処理されずにチェーンの最後に配置される場合があります。これは、責任チェーンの利点と欠点の両方です。
2.構造と実装
2.1構造
責任チェーンモデルには、主に次の役割が含まれます：抽象ハンドラー（ハンドラー）の役割：要求を処理するためのインターフェースを定義し、抽象処理メソッドと後続の接続を含みます; 具象ハンドラー（コンクリートハンドラー）の役割：抽象ハンドラー処理メソッドの実装、判断このリクエストを処理できるかどうか、処理できる場合は、後続のリクエストに転送されます。クライアントの役割：処理チェーンを作成し、チェーンの先頭にある特定のプロセッサオブジェクトにリクエストを送信しますが、そうではありません処理の詳細と配信プロセスのリクエストに注意してください。責任の連鎖のUML図は次のとおりです。
2.2実装
学生が2日以下を残す必要がある場合、クラスの教師が承認できます。7日以下、部長が承認できます。10日以下、学部長が承認できます。他のケースは承認されません。この例は、責任の連鎖モードの使用に適しています。 。フローチャートは次のとおりです。
抽象ハンドラーであるリーダークラス（Leader）を定義します。これには、次のリーダーの隣のポインターと、偽のストリップを処理する抽象処理メソッドhandleRequest（int LeaveDays）が含まれます。次に、クラスリーダークラス（ClassAdviser）、部門長を定義します。クラス（DepartmentHead）とディーンクラス（Dean）は、抽象プロセッサのサブクラスであり、具象プロセッサです。それぞれの能力に応じて、親クラスのhandleRequest（int LeaveDays）メソッドを実装する必要があります。それを次の特定のプロセッサに最後まで引き渡します。クライアントクラスは、処理チェーンを作成し、偽のストリップをチェーンの先頭にある特定のプロセッサに渡します（クラス教師）。クラス図は次のとおりです。
抽象 クラスLeader { 次にプライベートLeader; public void setNext（Leader next） { this .next = next; } public Leader getNext（） { 次へ戻る; } public abstract void handleRequest（int LeaveDays）; } クラス ClassAdviser extends Leader { public void handleRequest（int LeaveDays） { if（LeaveDays <= 2 ） { System.out.println（ "クラスの教師が休暇を承認する" + LeaveDays + "Day。" ）; } Else { if（getNext（）！= Null ） { getNext（）。HandleRequest（LeaveDays）; } else { System.out。 println（ "休暇が多すぎるため、誰も休暇を承認しません！" ）; } } } } クラス DepartmentHead extends Leader { public void handleRequest（int LeaveDays） { if（LeaveDays <= 7 ） { System.out.println（ "部門長が休暇を承認する" + LeaveDays + "Day。" ）; } Else { if（getNext（）！= Null ） { getNext（）。HandleRequest（LeaveDays） ; } else { System.out.println（ "休暇が多すぎるため、誰も休暇を承認しません！" ）; } } } } クラス Dean extends Leader { public void handleRequest（intLeaveDays） { if（LeaveDays <= 10 ） { System.out.println（ "学部長があなたの休暇を承認する" + LeaveDays + "Day。" ）; } Else { if（getNext（）！= Null ） { getNext（） handleRequest（LeaveDays）; } else { System.out.println（ "休暇日数が多すぎるため、誰も休暇を承認しません！" ）; } } } }
3.長所と短所および拡張
3.1利点
カップリングを減らします。リクエストの送信側と受信側を分離し、オブジェクトを簡素化します。オブジェクトはチェーンの構造を知っている必要はなく、オブジェクトに責任を割り当てる柔軟性を高めます。チェーン内のメンバーを変更するか、それらの順序を動員することにより、責任を動的に追加または削除することが可能であり、新しい要求処理クラスを追加すると便利です。
3.2短所
リクエストが受信される保証はありません。システムパフォーマンスがある程度影響を受け、コードをデバッグする際に不便です。ループ呼び出しが発生する可能性があります。ランタイムの特性を簡単に確認できないため、デバッグが妨げられる可能性があります。
3.3拡張
責任の連鎖モードには、次の2つの状況があります。1つは純粋な責任の連鎖モードです。要求はプロセッサオブジェクトによって受信される必要があり、特定のプロセッサは、次の2つのアクションのいずれかのみを使用して要求を処理できます。自分で処理する（責任を負う）、責任を次の家にプッシュする、2番目に、不純な責任の連鎖モデル：特定のプロセッサオブジェクトが要求の責任の一部になり、残りの責任を次の家に渡すことを許可する状況、および要求が受信側のエンドオブジェクトによって受信されない場合があります。
参照リンク：https : //wenku.baidu.com/view/04cc624d6bd97f192379e919.html
https://max.book118.com/html/2017/0711/121752783.shtm
http://c.biancheng.net/view/1383.html
https://www.cnblogs.com/cxxjohnson/p/6403849.html
https://blog.csdn.net/m0_37691414/article/details/80672007
https://blog.csdn.net/qq_38005943/article/details/82147987
https://www.jianshu.com/p/85801c01e05c