23のデザインパターン（13） - Chain of Responsibilityパターン

1.定義

オブジェクトの複数の送信側と受信側の結合関係要求品質を回避するように、要求を処理する機会。これは、オブジェクトを受信チェーンに接続されており、オブジェクトハンドル彼アップするまで鎖に沿って要求を渡しています。

2、UML 图

図3に示すように、組成物

抽象プロセッサ（ハンドラ）：それは主な治療が含まhandlerRequestとケアの対象をnextHandler、彼はそれを自分自身を扱うことができるならば、彼のアイデアは、ある、そうでない場合はオブジェクト処理に言及
プロセッサ実装クラス（FirstHandler） ：プロセッサの実装クラスは、各クラスは、その定義の処理ロジックを達成するために

図4に示すように、コード

負のサンプルコードではまず見て、多数のif分析の実行ロジックを選択します：

public Response handleRequest(Request request) {
    Level level = request.getLevel();
    if (1 == level) {
    	Handler1.handleRequest(request);
    } else if (2 == level) {
    	Handler2.handleRequest(request);
    } else if (3 == level) {
    	Handler3.handleRequest(request);
		}
    throw new RuntimeException("无法处理 ......")
}

このコードは次のような欠点があります。

コードの膨張：判定条件は単純ではない場合は1==level、より複雑な計算は、それは非常に悪いコードの読みやすだろう。
高い結合：あなたは新しいケースを追加する場合は、新たに追加する必要があるif else文を、に違反して元のコードを変更する-オープンクローズ原則。

ここChain of Responsibilityパターンを使用したコードは次のとおりです。

// 抽象处理类
public abstract class Handler {
		// 下一个处理器处理
    protected Handler nextHandler;

    void setNextHandler(Handler nextHandler){
        this.nextHandler = nextHandler;
    }

    final Response handleRequest(Request request){
      	// 如果自己能处理，则自己处理
        if(request.getLevel() == getHandlerLevel()){
            return this.doHandler(request);
        }
        System.out.println("本处理器:"+getHandlerLevel()+" 无法处理，开始转交 ......");
        if(null != this.nextHandler){
          // 如果不能处理，转交给下一个处理器处理
            return this.nextHandler.handleRequest(request);
        } else {
            System.out.println("无合适的处理器，处理失败 ......");
        }
        return null;
    }
		// 自己处理的任务标识
    abstract Level getHandlerLevel();
		// 实际处理逻辑，子类自己定义
    abstract Response doHandler(Request request);
}

// 任务标识，用于区分用哪个处理器处理
public enum Level {
    FIRST_LEVEL,
    SECOND_LEVEL,
    THIRD_LEVEL;
}

//请求类
public class Request {
    private Level level;
  
    public Request(Level level){
        this.level = level;
    }
  
    public Level getLevel() {
        return level;
    }
}

// 处理结果类
public class Response {
}

// 第一个处理器
public class FirstConcreteHandler extends Handler {
    @Override
    Level getHandlerLevel() {
        return Level.FIRST_LEVEL;
    }

    @Override
    Response doHandler(Request request) {
        System.out.println("本处理器:"+getHandlerLevel()+" 开始处理 .....");
        return null;
    }
}

// 第二个处理器
public class SecondConcreteHandler extends Handler {
    @Override
    Level getHandlerLevel() {
        return Level.SECOND_LEVEL;
    }

    @Override
    Response doHandler(Request request) {
        System.out.println("本处理器:"+getHandlerLevel()+" 开始处理 .....");
        return null;
    }
}

// 第三个处理器
public class ThirdConcreteHandler extends Handler {
    @Override
    Level getHandlerLevel() {
        return Level.THIRD_LEVEL;
    }

    @Override
    Response doHandler(Request request) {
        System.out.println("本处理器:"+getHandlerLevel()+" 开始处理 .....");
        return null;
    }
}

//调用者
public class Main {

    public static void main(String[] args) {
        Handler firstHandler = new FirstConcreteHandler();
        Handler secondHandler = new SecondConcreteHandler();
        Handler thirdHandler = new ThirdConcreteHandler();

        firstHandler.setNextHandler(secondHandler);
        secondHandler.setNextHandler(thirdHandler);
				// 需要第三个处理类处理
        Request request = new Request(Level.THIRD_LEVEL);
        firstHandler.handleRequest(request);
    }
}

出力：

本处理器:FIRST_LEVEL 无法处理，开始转交 ......
本处理器:SECOND_LEVEL 无法处理，开始转交 ......
本处理器:THIRD_LEVEL 开始处理 .....

5、長所と短所

レコードのみチェーンまでのコードのそれぞれの場合において、ユーザは、特定のロジックを実行することなく、1本のインレットチューブを知る必要があります。
Chain of Responsibilityパターンは、偽装のバージョンであるif elseチェーンが過剰消費性能、長すぎる場合は、声明;
チェーンは、表示されませ引用責任例チェーンをたどる無限ループが存在することになります

6、アプリケーションのシナリオ

Chain of Responsibilityパターンは、実際の柔軟なバージョンであるif…else…声明が、それは、各クラスのノードチェーンの判断に条件を置きます。それは、コード表示された場合if…else…のステートメントが悪い可読性を起こし、Chain of Responsibilityパターンを考えます。