この記事では、主にデザインパターンの責任接続パターンの関連情報を詳しく紹介します。興味のある方は参考にしてください。
定義: 複数のオブジェクトがリクエストを処理できるようにします。リクエストの送信者と受信者の間の結合関係を回避します。これらのオブジェクトはチェーンに接続され、リクエストはオブジェクトが処理するまでチェーンに沿って渡されます。
タイプ: 動作クラスパターン
クラス図:
最初にコードの一部を見てみましょう:
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); } }
このメソッドには 2 つのパラメーターがあります。整数 i と an リクエストの場合、i の値によって、誰がリクエストを処理するかが決まります。i==1 の場合は Handler1 によって処理され、i==2 の場合は Handler2 によって処理されます。プログラミングでは、このビジネス処理方法は非常に一般的であり、リクエストを処理するすべてのクラスには、リクエストを処理するための一連の責任を形成するために接続された if...else... 条件判断ステートメントが含まれています。この方法の利点は、非常に直感的で、シンプルかつ明確で、保守が比較的容易であることです。しかし、この方法にはいくつかの厄介な問題もあります。
コードが肥大化する: 1 か 2 かを判断するのはそれほど単純ではありません。複雑な計算やデータベースへのクエリなどが必要になる場合があり、さらに多くの判断条件がある場合は、この if になります。 ..else... ステートメントは基本的にもう見ることができません。
高度な結合: リクエストを処理するためのクラスを追加し続けたい場合は、さらに else if 判定条件を追加し続ける必要があり、この条件判定の順序もハードコーディングされます。順序を変更したい場合は、この条件文を変更するだけです。
欠点が明らかになったので、それらを解決する方法を見つけなければなりません。このシナリオのビジネス ロジックは非常に単純です。条件 1 が満たされている場合は Handler1 によって処理され、条件 2 が満たされていない場合は Handler2 によって処理されます。 、条件が終了するまで、引き続き引き継がれます。実は改善方法も非常にシンプルで、判定条件部分を処理クラスに組み込むというもので、これが責任連鎖モデルの原理です。
責任連鎖パターンの構造
責任連鎖パターンのクラス図は、抽象処理クラスとその実装クラスのセットで構成されています:
抽象処理クラス。 : 概要 処理クラスには主に、次の処理クラスを指すメンバー変数 nextHandler と、リクエストを処理するためのメソッド handRequest が含まれています。 handRequest メソッドの主な考え方は、処理条件が満たされた場合に、この処理クラスが次の処理を実行するということです。それを処理しない場合は、nextHandler が処理します。
特定の処理クラス: 特定の処理クラスは、主に特定の処理ロジックと処理に適用される条件を実装します。模 責任とパターンの一般的な考え方を理解した後、コードを理解することをお勧めします。
R
class Level { private int level = 0; public Level(int level){ this.level = level; }; public boolean above(Level level){ if(this.level >= level.level){ return true; } return false; } } class Request { Level level; public Request(Level level){ this.level = level; } public Level getLevel(){ return level; } } class Response { } abstract class Handler { private Handler nextHandler; public final Response handleRequest(Request request){ Response response = null; if(this.getHandlerLevel().above(request.getLevel())){ response = this.response(request); }else{ if(this.nextHandler != null){ this.nextHandler.handleRequest(request); }else{ System.out.println("-----没有合适的处理器-----"); } } return response; } public void setNextHandler(Handler handler){ this.nextHandler = handler; } protected abstract Level getHandlerLevel(); public abstract Response response(Request request); } class ConcreteHandler1 extends Handler { protected Level getHandlerLevel() { return new Level(1); } public Response response(Request request) { System.out.println("-----请求由处理器1进行处理-----"); return null; } } class ConcreteHandler2 extends Handler { protected Level getHandlerLevel() { return new Level(3); } public Response response(Request request) { System.out.println("-----请求由处理器2进行处理-----"); return null; } } class ConcreteHandler3 extends Handler { protected Level getHandlerLevel() { return new Level(5); } public Response response(Request request) { System.out.println("-----请求由处理器3进行处理-----"); return null; } } public class Client { public static void main(String[] args){ Handler handler1 = new ConcreteHandler1(); Handler handler2 = new ConcreteHandler2(); Handler handler3 = new ConcreteHandler3(); handler1.setNextHandler(handler2); handler2.setNextHandler(handler3); Response response = handler1.handleRequest(new Request(new Level(4))); } }
責任連鎖パターンは、if...else...と比較して、条件判定をさまざまな処理クラスに分散させるため結合度が低く、これらの処理クラスの順序が異なります。優先順位は任意に設定できます。責任連鎖モデルにも、if...else... ステートメントの欠点と同じ欠点があります。つまり、責任連鎖が見つかると、正しい処理クラスが見つかる前にすべての判断条件が実行される必要があります。比較的長い場合、パフォーマンスの問題はより深刻です。責任連鎖モードの応用
冒頭の例のように、責任連鎖を整理するために if ... else ... ステートメントを使用すると、コードの見た目が悪くなると、無力に感じてしまいます。リファクタリングを使用するために使用する責任チェーン モード。
概要
責任連鎖モードは、実際には if ... else ... ステートメントの柔軟なバージョンであり、これらの判断条件をさまざまな処理カテゴリに分類するものであり、クラスのコンテキストを扱うときは、正確に決定するように特に注意する必要があります。クラスの処理前後のロジック間の条件関係を確認し、チェーン内で循環参照が発生しないように注意してください。
以上がJava 設計パターンにおける責任連鎖パターンの分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。