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和一個請求request，根據i的值來決定由誰來處理request，如果i==1，由Handler1來處理，如果i==2，由Handler2來處理，以此類推。在編程中，這種處理業務的方法非常常見，所有處理請求的類有if…else…條件判斷語句連成一條責任鏈來對請求進行處理，相信大家都經常用到。這種方法的優點是非常直觀，簡單明瞭，並且比較容易維護，但是這種方法也存在着幾個比較令人頭疼的問題：

        代碼臃腫：實際應用中的判定條件通常不是這麼簡單地判斷是否爲1或者是否爲2，也許需要複雜的計算，也許需要查詢數據庫等等，這就會有很多額外的代碼，如果判斷條件再比較多，那麼這個if…else…語句基本上就沒法看了。

        耦合度高：如果我們想繼續添加處理請求的類，那麼就要繼續添加else if判定條件；另外，這個條件判定的順序也是寫死的，如果想改變順序，那麼也只能修改這個條件語句。

        既然缺點我們已經清楚了，就要想辦法來解決。這個場景的業務邏輯很簡單：如果滿足條件1，則由Handler1來處理，不滿足則向下傳遞；如果滿足條件2，則由Handler2來處理，不滿足則繼續向下傳遞，以此類推，直到條件結束。其實改進的方法也很簡單，就是把判定條件的部分放到處理類中，這就是責任連模式的原理。

        責任連模式的結構

        責任連模式的類圖非常簡單，它由一個抽象地處理類和它的一組實現類組成：

        抽象處理類：抽象處理類中主要包含一個指向下一處理類的成員變量nextHandler和一個處理請求的方法handRequest，handRequest方法的主要主要思想是，如果滿足處理的條件，則有本處理類來進行處理，否則由nextHandler來處理。

        具體處理類：具體處理類主要是對具體的處理邏輯和處理的適用條件進行實現。

        瞭解了責任連模式的大體思想之後，再看代碼就比較好理解了： 

package com.zq.designpattern.dutychain;

/**
 * Created by zhengshouzi on 2015/10/24.
 */
public class DutyChain {
    public static void main(String[] args) {
        Request request = new Request(new Level(7));
        ConcreteHandler1 concreteHandler1 = new ConcreteHandler1();
        ConcreteHandler2 concreteHandler2 = new ConcreteHandler2();
        ConcreteHandler3 concreteHandler3 = new ConcreteHandler3();
        ConcreteHandler4 concreteHandler4 = new ConcreteHandler4();
        concreteHandler1.setNextHandler(concreteHandler2);
        concreteHandler2.setNextHandler(concreteHandler3);
        concreteHandler3.setNextHandler(concreteHandler4);
        concreteHandler1.handleRequest(request);
    }
}

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.level)){
            response = 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 Response response(Request request);
    protected abstract  Level getHandlerLevel();
}
class ConcreteHandler1 extends Handler{

    @Override
    protected Response response(Request request) {
        System.out.println("ConcreteHandler1 處理");
        return null;
    }

    @Override
    protected Level getHandlerLevel() {
        return new Level(1);
    }
}
class ConcreteHandler2 extends Handler{

    @Override
    protected Response response(Request request) {
        System.out.println("ConcreteHandler2 處理");
        return null;
    }

    @Override
    protected Level getHandlerLevel() {
        return new Level(4);
    }
}
class ConcreteHandler3 extends Handler{

    @Override
    protected Response response(Request request) {
        System.out.println("ConcreteHandler3 處理");
        return null;
    }

    @Override
    protected Level getHandlerLevel() {
        return new Level(7);
    }
}
class ConcreteHandler4 extends Handler{
    @Override
    protected Response response(Request request) {
        System.out.println("ConcreteHandler4 處理");
        return null;
    }
    @Override
    protected Level getHandlerLevel() {
        return new Level(9);
    }
}

         代碼中Level類是模擬判定條件；Request，Response分別對應請求和響應；抽象類Handler中主要進行條件的判斷，這裏模擬一個處理等級，只有處理類的處理等級高於Request的等級才能處理，否則交給下一個處理者處理。在Client類中設置好鏈的前後執行關係，執行時將請求交給第一個處理類，這就是責任連模式，它完成的功能與前文中的if…else…語句是一樣的。

        責任鏈模式的優缺點:

        責任鏈模式與if…else…相比，他的耦合性要低一些，因爲它把條件判定都分散到了各個處理類中，並且這些處理類的優先處理順序可以隨意設定。責任鏈模式也有缺點，這與if…else…語句的缺點是一樣的，那就是在找到正確的處理類之前，所有的判定條件都要被執行一遍，當責任鏈比較長時，性能問題比較嚴重。

        責任鏈模式的適用場景：

        就像開始的例子那樣，假如使用if…else…語句來組織一個責任鏈時感到力不從心，代碼看上去很糟糕時，就可以使用責任鏈模式來進行重構。

        總結：

        責任鏈模式其實就是一個靈活版的if…else…語句，它就是將這些判定條件的語句放到了各個處理類中，這樣做的優點是比較靈活了，但同樣也帶來了風險，比如設置處理類前後關係時，一定要特別仔細，搞對處理類前後邏輯的條件判斷關係，並且注意不要在鏈中出現循環引用的問題（否則的話，如果沒有找到能處理的請求，將會無線循環）。