責任パターンの定義1.チェーン
オブジェクトの複数それにより、要求の送信者と受信者との間の結合を回避し、要求を処理する機会。これらは、鎖の中に一緒に目的、およびこれまでにオブジェクトハンドルまでそれをチェーンに沿って要求を渡します。
責任のパターンのキーチェーンは、チェーンの要求を処理する者を決定するために同様の要求を処理するためのチェーンで「連鎖」です。
第二に、責任のパターンのアプリケーションチェーン
Chain of Responsibilityパターンの利点
責任のパターンは非常に重要な利点のチェーンが要求され、別々に処理されます。リクエスタは、要求ハンドラを処理したか分からないかもしれない全体像を知ることができない、（例えばJ2EEプロジェクトの開発を、あなたはBeanの責任の連鎖によって処理ステートレスを取り除くことができます）の両方のデカップリングし、システムの柔軟性を向上させます。
2.欠点は、Chain of Responsibilityパターン
：責任のチェーンは、二つの重要な欠点があり
、比較的長鎖、パフォーマンスは非常に大きな問題である場合は特に、チェーンの最後にチェーンの先頭から各要求を横断し、まず、パフォーマンスの問題を。
第二は、特にチェーンより長く、より多くのリンクは、同様の再帰的な方法を使用しての、ロジックをデバッグするときには複雑になる可能性があるため、デバッグには非常に簡単ではありません。
責任パターンの注3.チェーン
長鎖の発生を回避するために、チェーン内のノードの数を制御する必要が、一般的には、ハンドラ内のノードの最大数を設定することであり、これは、プロセスがその閾値を避けるために、チェーンを確立するために許可されている超えて、超過しsetNextか否かを判断します無意識の破壊システムのパフォーマンス。
第三に、ベストプラクティス
Chain of Responsibilityパターンが要求を処理するマスクされ、あなたが扱われ、最終的に要求を開始し、そしてあなたは、限り、あなたは責任の連鎖を投げ、そして最終的にはもちろん、（処理結果を返すように最初の要求を処理するよう、缶を気にしないこと依頼者は、最終的に知ることができないとして）任意の処理をせず、それは、Chain of Responsibilityパターンが救済モードとしても使用することができる一方で、責任のパターンのコア鎖である、に対処する必要性に起こっている人です。
ここでは簡単な例です：
リクエスト、ハンドラを、しかし、あなたのビジネスの成長に合わせて数とタイプハンドラが増加している、この時間は、あなたが最初にすることができます：プロジェクトの開発は、これを確認する必要がある場合として、チェーンを確立するためのハンドラの後ろに、責任の連鎖がハンドルに元、良い、または最初のビジネス・ロジック場合は、要求を処理することで、米ドル、良いが、プロセスに2つ目のビジネス・ロジックに渡すと、円、ユーロ...これらは、元のビジネス・ロジックに大きな変化を持っていない、実装クラスを拡張することにより、これらの変化する要件に対処するための良い時間することができます。
コード例：https://github.com/developers-youcong/DesignPatternPractice/tree/master/ChainOfResponsibility