23デザインパターン第19章：Java責任チェーンモデル
定義：複数のオブジェクトがリクエストを処理する機会を持つことができるため、送信者とリクエストのレシーバーとの間の結合関係を回避できます。これらのオブジェクトをチェーンに接続し、オブジェクトが処理するまでチェーンに沿ってリクエストを渡します。
タイプ：行動パターン
クラス図：
まずコードを見てみましょう。
public void Test（int i、request request）{if（i == 1）{handler1.response（request）; } else if（i == 2）{handler2.response（request）; } else if（i == 3）{handler3.Response（request）; } else if（i == 4）{handler4.response（request）; } else {handler5.Response（request）; }}コードのビジネスロジックは次のとおりです。メソッドには、整数Iとリクエストリクエストの2つのパラメーターがあります。リクエストを処理するIの値に応じて、i == 1の場合、Handler1によって処理され、i == 2の場合、Handler2によって処理されます。
プログラミングでは、この種のビジネス処理方法が非常に一般的です。リクエストを処理するすべてのクラスには、ifが含まれます。私は誰もがそれをよく使うと信じています。この方法の利点は、非常に直感的で、シンプルで明確で、メンテナンスが比較的簡単であることですが、この方法にはいくつかの頭痛もあります。
コードの肥大化：実際のアプリケーションでは、判断条件は通常、1か2か2かどうかを判断するのはそれほど簡単ではありません。複雑な計算が必要になる場合があります。データベースなどを照会する可能性があります。これには追加のコードがあります。多くの判断条件がある場合、これは...他の...声明が基本的に読むことは不可能です。
高い結合度：プロセス要求のクラスを追加し続けたい場合は、判断条件の場合は他のものを追加し続ける必要があります。さらに、この状態の順序も死者に書かれています。注文を変更したい場合は、この条件ステートメントのみを変更できます。
私たちはすでに欠点を理解しているので、それらを解決する方法を見つける必要があります。このシナリオのビジネスロジックは非常に単純です。条件1が満たされている場合、Handler1によって処理され、満たされていない場合、受け継がれます。条件2が満たされている場合、それはHandler2によって処理され、満たされていない場合、条件が終了するまで渡されます。実際、改善方法も非常に単純です。これは、判断条件の一部を処理クラスに入れることです。これが責任接続モデルの原則です。
責任チェーンモデルの構造
責任パターンのクラス図は非常に単純で、抽象的に処理されたクラスとその一連の実装クラスで構成されています。
抽象処理クラス：抽象処理クラスには、主に次の処理クラスを指すメンバー変数Nexthandlerと、リクエストを処理するメソッドハンドレクエストが含まれます。ハンドレクエスト方法の主な考え方は、処理条件が満たされている場合、この処理クラスが処理されるということです。
特定の処理クラス：特定の処理クラスは、主に特定の処理ロジックと処理に適用可能な条件を実装します。
責任チェーンモデルの一般的なアイデアを理解した後、コードを見ると理解しやすくなります。
クラスレベル{private int level = 0;パブリックレベル（intレベル）{this.level = level; };上記のパブリックブール（レベルレベル）{if（this.level> = level.level）{return true; } falseを返します。 }} class request {レベルレベル;パブリックリクエスト（レベルレベル）{this.level = level; } public level getLevel（）{return level; }} class Response {} abstract class Handler {private Handler nexthandler; Public Final Response Handlerequest（リクエストリクエスト）{応答応答= null; if（this.gethandlerlevel（）。上（request.getLevel（））{respons = this.response（request）; } else {if（this.nexthandler！= null）{this.nexthandler.handlerequest（request）; } else {system.out.println（ "---------"）; }}返信応答; } public void setnexthandler（ハンドラーハンドラー）{this.nexthandler = handler; }保護された抽象レベルgethandlerlevel（）;パブリックアブストラクト応答応答（リクエストリクエスト）; } class concretehandler1拡張ハンドラー{プロテクションレベルgethandlerlevel（）{return new level（1）; } public Response Response（リクエストリクエスト）{ System.out.println("------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ class concretehandler2は、プロテクタントレベルgethandlerlevel（） system.out.println（-------プロセッサによって処理されます。 handler1.setNexthersler（Handler2）;コードでは、レベルクラスが決定条件をシミュレートします。リクエストと応答は、それぞれリクエストと応答に対応しています。抽象クラスハンドラーは主に条件を判断し、処理レベルはここでシミュレートされます。処理クラスの処理レベルのみが、リクエストのレベルを処理できるよりも高いため、処理のために次のプロセッサに引き渡されます。
クライアントクラスのチェーンのフロントおよびバック実行関係を設定し、実行中にリクエストを最初の処理クラスに引き渡します。これが責任チェーンパターンです。それが完了する関数は、前の記事のif ... else ...ステートメントと同じです。
責任チェーンモデルの長所と短所
IFと比較して…責任チェーンパターンは、条件付き判断をさまざまな処理クラスに分配するため、カップリング能力が低くなり、これらの処理クラスの優先処理順序を自由に設定できます。責任チェーンモデルには欠点もあります。これは、if ... else ...ステートメント、つまり、正しい処理クラスを見つける前に、すべての判断条件を実行する必要があります。責任チェーンが比較的長い場合、パフォーマンスの問題はより深刻です。
責任チェーンモデルに適用されるシナリオ
最初の例と同じように、if…else…statementの責任を整理するためのステートメントを使用するときに圧倒された場合、コードは悪く見えます。
要約します
責任チェーンモデルは、実際には... else ...ステートメントの柔軟なバージョンです。これらの判断条件を各処理クラスに入れます。これの利点は、より柔軟性があることですが、リスクももたらします。たとえば、処理クラスの前後に処理クラス間の関係を設定する場合、処理クラスの前後に条件付きロジック間の関係を判断し、チェーンに循環参照がないように注意する必要があります。
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。