個人Java設計模式-責任鏈模式

今天來講說程序員小猿和產品就關於需求發生的故事。前不久，小猿收到了產品的需求。

產品經理：小猿，爲了迎合大衆屌絲用戶的口味，咱們要放一張圖，要露點的。

小猿：......露點？你大爺的，讓身爲正義與純潔化身的我作這種需求，還露點。

產品經理：誤會誤會，是放一張暴露一點點的，尺寸不大。

小猿：尼瑪~能說清楚些嗎，需求模棱兩可的。不幹，我要上報boss。

產品經理也一陣無語，這豆丁的事還上報boss。話說這上報也得走程序是吧，技術經理就不幹了，「憑什麼要跳過我，得通過我才能到boss」。咦~這一層一層上報就涉及到此次的責任鏈模式。

1、責任鏈模式

定義

  建立多個對象，使這些對象造成一條鏈，並沿着這條鏈傳遞請求，直到鏈上的某一個對象決定處理此請求。

特色

1）接收請求的對象鏈接成一條鏈，對象之間存在層級關係。

2）這些對象可處理請求，也可傳遞請求，直到有對象處理該請求。

UML

責任鏈模式涉及到的角色以下所示：

  - 抽象處理者角色：定義了處理請求的接口或者抽象類，提供了處理請求的的方法和設置下一個處理者的方法。

  - 具體處理者角色：實現或者繼承抽象這角色，具體邏輯根據實際的架構來定，後面會提到。

2、實戰

先來看抽象處理者角色代碼：

public abstract class Handler {
    private Handler nextHandler;
    private int level;
    public Handler(int level) {
        this.level = level;
    }

    // 處理請求傳遞，注意final，子類不可重寫
    public final void handleMessage(Demand demand) {
        if (level == demand.demandLevel()) {
            this.report(demand);
        } else {
            if (this.nextHandler != null) {
                System.out.println("事情太嚴重，需報告上一級");
                this.nextHandler.handleMessage(demand);
            } else {
                System.out.println("我就是boss，沒有上頭");
            }
        }
    }

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

    // 抽象方法，子類實現
    public abstract void report(Demand demand);
}

在抽象處理者角色定義了處理請求的抽象方法，以及下一級傳遞的對象方法，重點在handleMessage處理請求傳遞的方法，下面會解釋爲何要這樣寫，繼續往下看。

下面是具體處理者角色，繼承抽象處理者角色，在咱們情景中有兩個具體處理者，分別是技術經理和boss。

// 技術經理
public class TechnicalManager extends Handler {
    public TechnicalManager() {
        super(1);
    }

    @Override
    public void report(Demand demand) {
        System.out.println("需求：" + demand.detail());
        System.out.println(getClass().getSimpleName() + "：小猿我挺你，這個需求不幹");
    }
}

// boss
public class Boss extends Handler {
    public Boss() {
        super(2);
    }

    @Override
    public void report(Demand demand) {
        System.out.println("需求：" + demand.detail());
        System.out.println(getClass().getSimpleName() + "：大家打一架吧，打贏的作決定");
    }
}

能夠看到具體處理者的代碼很簡潔，重寫了report方法，實現各自的業務邏輯，這都歸功於父類中handleMessage這個方法。

兩個角色都定義好了，來看客戶端如何實現：

public class Client {
    public static void main(String[] args) {
        Demand demandA = new DemandA(); // 請求等級低
        Demand demandB = new DemandB(); // 請求等級高

        Boss boss = new Boss();
        TechnicalManager technicalManager = new TechnicalManager();
        technicalManager.setNextHandler(boss); // 設置下一級

        technicalManager.handleMessage(demandA);
        System.out.println("============================");
        technicalManager.handleMessage(demandB);
    }
}

能夠看到在客戶端中的重點是設置下一級的處理者，這樣多個處理者對象就會造成一條鏈。運行客戶端，結果以下：

需求：加一張露一點點的圖
TechnicalManager：小猿我挺你，這個需求不幹

============================
需求：加一張露一點點的圖
TechnicalManager：事情太嚴重，需報告上一級
Boss：大家打一架吧，打贏的作決定

從結果能夠看到，級別低的請求技術經理本身處理，級別高的傳遞給了下一級的Boss，這樣就造成一條鏈，而這也是責任鏈的核心所在。注意，在請求的傳遞過程當中，請求是不會發生變化的。需求不會從「加一張露一點點的圖」變成了「加一張露點的圖」，這等着boss請到辦公室喝茶吧。

3、擴展

責任鏈+模板方法

回頭看看上面的代碼，抽象類中定義了幾個方法，一個是final修飾的handleMessage，一個是抽象方法report，還有一個是setNextHandler。這恰好是模板方法模式中的三個基本方法，分別是具體方法（抽象類聲明並實現，子類不實現）、抽象方法（抽象類聲明，子類必須實現）、鉤子方法（抽象類聲明並實現，子類可擴展）。handleMessage方法加了final修飾，子類不可重寫，而handleMessage正是把傳遞請求工做交給父類Handler，子類不須要處理傳遞的工做。而report則是抽象方法，子類必須重寫該方法，子類處理請求的業務邏輯。setNextHandler是鉤子方法，在這裏咱們並無實現。

這樣結合模板方法模式的好處在哪？首先加了handleMessage方法，把請求的傳遞判斷從子類中剝離出來，讓子類在report方法中專心處理請求的業務邏輯，作到了單一職責原則。再者是子類的實現變得簡單了，不須要進行傳遞的判斷，很是有利於快速擴展。

責任鏈模式VS觀察者模式

觀察者模式我在以前有些過，不瞭解的能夠先看看。責任鏈模式和觀察者模式存在一個共同點，就是傳遞責任鏈模式是一級一級的傳遞，造成一條鏈，鏈節點（處理者）之間是存在傳遞關係的。而觀察者模式的被觀察者向觀察者們的傳遞，並非具體觀察者之間的傳遞，觀察者之間是不存在關聯的。拿小猿的經從來說，在責任鏈模式中是請求從技術經理到boss，有層級關係，而對於觀察者模式是從被觀察者小猿發出，做爲觀察者的技術經理和boss都會收到小猿的通知，是擴散式的，技術經理和boss並無層級關係。這是責任鏈模式和觀察者模式的區別，也是責任鏈模式的核心。

4、責任鏈模式的優缺點

優勢

1）下降耦合度：客戶端不須要知道請求由哪一個處理者處理，而處理者也不須要知道處理者之間的傳遞關係，由系統靈活的組織和分配。

2）良好的擴展性：增長處理者的實現很簡單，只需重寫處理請求業務邏輯的方法。

缺點

1）請求會從鏈頭髮出，直到有處理者響應，在責任鏈比較長的時候會影響系統性能。

2）請求遞歸，調試排錯比較麻煩。

總結

責任鏈模式在實際項目中能夠用到的地方仍是比較多的，好比會員等級系統，會員等級之間構成一條鏈，用戶發起一個請求，系統只要把請求分發到責任鏈模式的入口，直到傳遞到與用戶會員匹配的等級，這樣各個會員等級的業務邏輯就會變成很清晰。這篇折騰了好久，主要是想把責任鏈的核心闡述清楚，讓你們可以容易理解，也讓我從新思考了責任鏈模式的核心。下一篇是「還沒想好」，您的點贊和關注是個人動力哦，再會！

設計模式Java源碼GitHub下載：https://github.com/jetLee92/DesignPattern