責任の定義：Chainの責任（COR）は、これらのクラスを処理しようとする一連のクラスです。つまり、リクエストが最初に処理されない場合、クラスBプロセスに渡され、チェーンのように渡されます。
責任チェーンモデルの使用方法
この段落はCORを使用していますが、CORとは何かを示しています。
ハンドラーインターフェイスがあります：
コードコピーは次のとおりです。
パブリックインターフェイスハンドラー{
public void handlerequest（）;
}
これは、リクエストを処理する例です。
◆頭に浮かぶ最初の解決策は、インターフェイスに複数のリクエストを追加することです。
コードコピーは次のとおりです。
パブリックインターフェイスハンドラー{
public void handlehelp（）;
public void handlePrint（）;
public void handleformat（）;
}
具体的には、インターフェイスを実装するコードです。
コードコピーは次のとおりです。
パブリッククラスのコンクリートハンドラーはハンドラーを実装しています{
プライベートハンドラーの後継者。
パブリックコンクリートハンドラー（ハンドラー後継者）{
this.successor =後継者;
}
public void handlehelp（）{
//ヘルプリクエストを処理するための特定のコード...
}
public void handleprint（）{
//プリントの場合は、プリントを処理します
後継者handleprint（）;
}
public void handleformat（）{
//フォーマットの場合は、プロセス形式に移動します
後継者handleformat（）;
}
}
上記の3つの特定の実装クラスがあり、処理ヘルプであり、プリントおよび処理形式を処理します。これは、おそらく最も一般的に使用されるプログラミングのアイデアです。
アイデアは簡単で明確ですが、拡張機能の問題がある場合は、インターフェイスと各実装を変更する必要があります。
◆2番目のソリューション：各リクエストをインターフェイスに変換するため、次のコードがあります。
コードコピーは次のとおりです。
パブリックインターフェイスヘルプハンドラー{
public void handlehelp（）;
}
パブリックインターフェイスプリントハンドラー{
public void handlePrint（）;
}
public interface formathandler {
public void handleformat（）;
}
パブリッククラスコンクリートハンドラー
helphandler、printhandler、formathandlet {
プライベートヘルプハンドラーは、CUCSERSERをヘルプします。
プライベートプリントランドプリプスキャッカー。
プライベートフォームサンドラーフォーマットCUCSERS;
Public ConcreteHandler（ヘルプハンドラーHEALTUCCERSER、PRINTHANDLER PRINTSSUCSERS、FORMATHANDLER FORMATSUCCERSER）
{
this.helpsucsessor = helpinguccessor;
this.printsuccessor = printsuccessor;
this.formatsuccessor = formatsuccesser;
}
public void handlehelp（）{
.........
}
public void handlePrint（）{this.printsuccesser = printsuccesser;}
public void handleformat（）{this.formatsuccesser = formatsuccessor;}
}
新しいリクエストリクエストを追加する場合、このメソッドはインターフェイスの変更の量のみを節約し、ConcreteHandlerのインターフェイス実装も変更する必要があります。そして、コードは明らかにシンプルで美しいものではありません。
◆ソリューション3：ハンドラーインターフェイスで使用されているパラメーター化方法は1つだけです。
コードコピーは次のとおりです。
パブリックインターフェイスハンドラー{
public void handlerequest（string request）;
}
次に、ハンドラーの実装コードは次のとおりです。
パブリッククラスのコンクリートハンドラーはハンドラーを実装しています{
プライベートハンドラーの後継者。
パブリックコンクリートハンドラー（ハンドラー後継者）{
this.successor =後継者;
}
public void handlerequest（string request）{
if（request.equals（ "help"））{
//ここにヘルプを処理するための特定のコードがあります} else
//次の後継者に渡されます。Handle（request）;
}
}
}
最初に、リクエストが文字列タイプであると仮定しましょう。もちろん、特別なクラスリクエストを作成できます
◆最終解決策：インターフェイスハンドラーのコードは次のとおりです。
コードコピーは次のとおりです。
パブリックインターフェイスハンドラー{
public void Handlerequest（リクエストリクエスト）;
}
リクエストクラスの定義：
パブリッククラスリクエスト{
プライベート文字列タイプ。
public request（string type）{this.type = type;}
public string getType（）{return type;}
public void execute（）{
//リクエストの実際の特定の動作コード}
}
次に、ハンドラーの実装コードは次のとおりです。
コードコピーは次のとおりです。
パブリッククラスのコンクリートハンドラーはハンドラーを実装しています{
プライベートハンドラーの後継者。
パブリックコンクリートハンドラー（ハンドラー後継者）{
this.successor =後継者;
}
public void handlerequest（リクエストリクエスト）{
if（helprequestのinstanceのリクエスト）{
//ここにヘルプを処理するための特定のコードがあります} else if（printrequestのインスタンスを要求）{
request.execute（）;
}それ以外
//次の後継者に渡されます。Handle（request）;
}
}
}
この解決策はチェーンにあり、対応する責任があるため、責任のチェーンと呼ばれます。
1. CORの利点：外の世界からのどのタイプのリクエストが属するかを予測することは不可能であるため、各クラスが処理できない要求に遭遇した場合、あきらめるだけです。これにより、クラス間の結合が間違いなく減少します。
2。CORの不利な点は、その非効率性です。これは、もちろん完了する前にリクエストの完了を通過する必要があるため、ツリーの概念を使用して最適化することもできます。 Java AWT1.0では、マウスボタンの取り扱いは、java.1.1を入力した後、corの代わりに使用されます。
CORでは、統一されたインターフェイスハンドラーがある必要があるため、スケーラビリティは低くなっています。