一文帶你玩轉設計模式之「責任鏈」

微信搜索🔍「碼農田小齊」，關注這個在紐約的程序媛，回覆「01-05」能夠獲取計算機精選書籍、我的刷題筆記、大廠面經、面試資料等資源，麼麼噠～

前言

對於已經工做了的小夥伴，你應該是見過"責任鏈"這種面向對象的設計模式的，還在上學的小夥伴也不用着急，你早晚會接觸到的。本文旨在讓小白同窗和不太熟悉責任鏈的朋友可以迅速對這一設計模式有一個大體的瞭解。

在咱們的工農業生產中，常常有這樣的場景：一個任務、事務、流程等都須要不少不一樣的步驟，來完成不一樣的計算或者收集不一樣的數據。

爲了維護一個比較複雜，有時甚至是對順序敏感的任務流程，咱們常常在代碼的編寫和設計上採用"責任鏈"設計模式。

究竟什麼是"責任鏈"呢？我們看下面這個例子。

例子

假設你也"穿越"到了清朝，是會寫代碼的和珅和中堂，皇上立刻要南巡。請你用代碼封裝並模擬："乾隆下江南" 這件事。

你要怎麼安排萬歲爺的行程？要知道這但是個大工程，中間可不能有差錯，一旦出了什麼岔子但是要掉腦殼的 😂

但皇上又是性情中人，行程可能常常更改，甚至半路就微服私訪。

因此咱們在伺候皇上下江南的時候，既得讓皇上的行程有序進行，又要儘可能適應聖上因爲一時興起而可能作出的變化。

怎麼設計呢？若是把皇上的行程都寫在一塊兒執行，有兩個很差的地方：

1. 行程太多，並且全都事關重大，這麼遠的路，全都要你一我的打理，哪裏一不注意出了亂子，腦殼就要搬家；
2. 行程多，因此增改起來太麻煩，一旦有改動聖上的行程表容易亂。畢竟行程寫在一塊兒，好似
   一堆亂麻，條理不清。

因此問題來啦，和大人您可怎麼排聖上的行程呢？

和大人莫急，看看地圖咱們就知道，乾隆從北京到杭州要順序通過直隸、山東、江蘇、浙江四省（基本就是如今京滬高鐵的路子）:

這樣和大人就能夠按省把任務大體劃分爲四個部分，責成四省的官員們分擔這一個大工程，把他們應盡的的責任連成一個有序的鏈條，而後依次讓他們執行伺候皇上的任務。

這樣一來解決了行程過於豐富，和大人一我的安排不過來的問題，二來保證了各個步驟的靈活安排（後面的例子講），三來哪一步出了問題還便於問責（甩鍋，不然全是本身的錯）。

好了，說了這麼多，如今切入技術層面。

設計

Step1:

首先總結一下咱們所研究的問題中的名詞，來肯定大概須要哪些類：

1. 皇帝（乾隆）
2. 行程的管理者（和中堂）
3. 各省官員（具體幹活的公僕們）

Step2:

再來肯定各個類之間的關係：

• 最容易看出來的是各省官員是同僚關係，他們都要接待乾隆，只是在皇上南巡的過程當中出場順序和作的具體接待行爲不同，好比：

  • 直隸總督會帶乾隆去避暑山莊，
  • 山東巡撫會張羅着皇上祭拜孔廟，
  • 蘇州織造讓皇上游覽園林，
  • 而杭州知州就帶着皇上去西湖蘇堤。
• 這裏告訴你們 OOD 中一個優化設計的小口訣：變化的抽接口，相同的建模版。

因此咱們在這裏面對官員們不一樣的行爲，最好把他們抽象成接口或者抽象類，這裏咱們採用官員（Official）
這個抽象類。

而和大人做爲總管，他既要掌握皇帝的動向，又要轄制各省官員，因此在類的層面上和大人（PrimeMinister）這個類就得有指向皇帝（Emperor）和官員列表的引用。

下面上 UML 圖。

UML 圖

各省同僚：

而你和大人，做爲乾隆面前的紅人，得統籌安排皇帝的行程，既要挾持皇帝，又要掌管各省官員，讓他們有序地執行任務：

責任鏈通常都至少有一個被處理的對象，做爲參數傳入各個步驟，這裏的乾隆就是這個被處理（伺候）的對象。

代碼

做爲官員這個抽象類，咱們考慮到實際狀況，他要安排一個地方並陪同皇帝參觀、遊覽，其實就是一句話：伺候皇上。

因此他有一個抽象方法 serve，接受皇帝（Emperor）這個對象

@Data
public abstract class Official {
    protected String title;

    protected abstract void serve(Emperor emperor);

    @Override
    public String toString() {
        return title;
    }
}

這裏爲了區別不一樣的官員，咱們還給了官員（Official）類一個成員變量 title。

Official 下面有具體實現的類，表明各省官員，他們本身有本身具體的方式去服務吾皇，好比直隸總督，他是這麼幹的：

public class HebeiOfficial extends Official {

    public HebeiOfficial() {
        this.title = "直隸總督";
    }

    @Override
    protected void serve(Emperor emperor) {
        emperor.play(this, "避暑山莊");
    }
}

這裏在 serve 裏面徹底讓參數"皇帝"本身決定怎麼玩，（順便說句題外話，這種讓參數這個"外來的和尚"唸經的方式，在各類設計模式裏很常見。若是把這裏的 Emperor 換成 Comparator，相信不少小夥伴就感受有點像策略模式了。並且"直隸總督"也能夠在皇帝 play 以前或者以後分別作一些事情，這像不像用 JDK 的代理的時候中那個 InvocationHandler 對待 Method 的方式？或者 Spring 中對於 Aspect 的處理？另外在 Visitor 等設計模式中你也能看到這種寫法的身影）

其餘官員的寫法相似，只是換個地方供皇帝遊覽而已，參見後面的輸出結果，這裏略。

而做爲皇帝，乾隆只管着玩就好，固然了，你和中堂能夠安排當地的官員陪同，因此
皇帝類只有一個 play 方法，這裏用一個字符串簡單表示去遊覽的地方。

爲了防止乾隆南下期間有人在北京"另立新君"（執行 new Emperor()），這個"皇帝"對象的建立過程採用了單例模式，保證整個 JVM 裏面就只有這麼一個皇上，並且名字叫"乾隆"：

public class Emperor {
    private static final Emperor INSTANCE = new Emperor("乾隆");
    private final String name;

    private Emperor(String name) {
        this.name = name;
    }

    public static Emperor getInstance() {
        return INSTANCE;
    }

    public void play(Official official, String place){
        System.out.println(official.getTitle() + " 安排 " + name + "皇帝遊覽了: " + place);
    }
}

而你，和珅和大人，只須要按各省順序，合理安排好下面的官員，而後請出皇上並昭告天下：聖上下江南了，沿途各省當心伺候就好：

public class PrimeMinister {
    private static List<Official> list = new ArrayList<>();

    public static void main(String[] args) {
        // 下令沿途各省官員準備好
        list.add(new HebeiOfficial());
        list.add(new ShandongOfficial());
        list.add(new JiangsuOfficial());
        list.add(new ZhejiangOfficial());
        // 請出皇上
        Emperor emperor = Emperor.getInstance();
        // 昭告天下：萬歲爺起駕下江南！沿途各省依次伺候聖上
        System.out.println("乾隆下江南!");
        start(list, emperor);
    }

    private static void start(List<Official> officials, Emperor emperor) {
        for (Official o : officials) {
            o.serve(emperor);
        }
    }
}

看看，你的任務是否是簡明多了，只須要維護好這個沿途各省官員的花名冊便可。

更重要的是，你不用親自負責了，下面的人誰辦事不力，就要誰的腦殼！

只要本身的這個"花名冊"或者"行程表"沒寫錯，咱的腦殼就算保住啦。

並且各個官員的任務也比較單一，他們本身也更不容易出錯。下面是整個行程模擬的執行狀況：

乾隆下江南!
直隸總督 安排 乾隆皇帝遊覽了: 避暑山莊
山東巡撫 安排 乾隆皇帝遊覽了: 曲阜孔廟
蘇州織造 安排 乾隆皇帝遊覽了: 蘇州園林
杭州知州 安排 乾隆皇帝遊覽了: 西湖蘇堤

嗯，一切看上去彷佛還不錯，各省官員按照順序，依次完成了任務，把萬歲爺伺候的還不錯，沒有什麼異常情況發生，總算鬆了口氣。

可是，如今來了個突發狀況：皇上忽然要求，在路過山東的時候加一個環節——大明湖畔三日遊！

爲啥要特地去那裏？咱也不敢問吶！只管準備就好。

幸虧咱們的行程又已經有了大體框架，趕忙查，大明湖那裏歸誰管，哦，濟南知府，就是他了！

如今只需把他也加到"花名冊"：責令濟南知府安排皇上在大明湖畔三天的行程，不得有誤，不然拿你試問！下面是和大人這邊要作的改動：

...以上略...
    list.add(new HeibeiOfficial());
    // 加入濟南知府，讓他幹活，他知道在大明湖畔該怎麼玩
    list.add(new JinanOfficial());
    list.add(new ShandongOfficial());
    list.add(new JiangsuOfficial());
    list.add(new ZhejiangOfficial());
    ...如下略...

而另外一邊濟南知府這裏，他也是屬於官僚體制了（Official 的子類），因此也要極盡所能，讓聖上在大明湖畔玩得開心：

public class JinanOfficial extends Official{
    public JinanOfficial() {
        title = "濟南知府";
    }

    @Override
    protected void serve(Emperor emperor) {
        emperor.play(this, "大明湖畔");
    }
}

再次執行程序，模擬聖上的行程，結果輸出以下：

乾隆下江南!
直隸總督 安排 乾隆皇帝遊覽了: 避暑山莊
濟南知府 安排 乾隆皇帝遊覽了: 大明湖畔
山東巡撫 安排 乾隆皇帝遊覽了: 曲阜孔廟
蘇州織造 安排 乾隆皇帝遊覽了: 蘇州園林
杭州知州 安排 乾隆皇帝遊覽了: 西湖蘇堤

嗯，這下總算又迎合了聖意，之後皇上再來什麼其餘的行程也不怕了（只要他不微服私訪，微服私訪您找紀曉嵐去啊，單一責任原則，專門的類幹專門的事兒不是？）。

只要找到當地具體的官員，一紙命令：你給我極盡所能招待皇上，具體怎麼招待，你看着辦，伺候很差萬歲爺，我要你腦殼！

固然了，皇帝也可能臨時刪掉南巡中的某個環節，咱們直接把它從行程列表中刪除就好，並且何時想再從新加進來還能夠隨時添加，作到了能夠"靈活插拔"，把代碼的改動減到了最小，有新的業務邏輯加進來的時候，只是作添加，這樣既不容易出錯，也確保了代碼的彈性擴展，並且當前責任鏈中的步驟，若是沒有狀態相關的信息的話，也能夠被組裝到其餘的責任鏈中。

並且若是是咱們的真實項目，咱們甚至能夠把工做步驟的列表配置在 Spring Boot 的配置文件裏，開啓流程的這個類，只要讀取配置，而後把各個步驟依次執行。

這樣若是有修改只要改動配置文件便可，在 Java 代碼裏無需任何改動。

總結與拓展

以上其實只是一個責任鏈模式最簡單的應用，它是一個有序列表裏面裝了各個任務的步驟，而後依次運行到最後。

咱們能夠把它寫在本身的程序裏，也能夠把它抽象出來作成產品，讓其餘人自由擴展與配置，儘可能減小重複製造輪子。

有不少工做流引擎即是這樣，好比 Activiti、Netflix 的 Conductor 等。不光這些，就連你
最經常使用的 SpringMVC 甚至是 Tomcat 都用到了責任鏈模式，只不過他們的責任鏈是雙向的，分別處理請求和響應，並且他們的處理順序是恰好相反的，本質上是用相似遞歸的方法正序倒序各便歷了一次（Filter 或 Interceptor 的）數組。

另外在一些持續集成和持續部署的框架中，如 Jenkins，會有管道（Pipeline）的概念，當你在作出 git push 提交代碼以後，會觸發整個流程開始一步步地運做：拉取代碼（Checkout code）、構建（Build）、測試（Test）等，直到部署（Deploy）完成並運行腳本關閉舊版本的服務並啓動最新部署的服務。這個"流水線"（Pipeline）其實也是一個可讓你用代碼腳原本配置的責任鏈。

沒有責任鏈模式的應用，你甚至都沒法運行任何一個 Java 程序。由於類加載通常遵循"雙親委派"機制，其實是用相似遞歸的方法正序和倒序各便歷了一次 Classloader 類所構成的鏈表（題外話，想把一個鏈表翻轉過來，能夠參見齊姐以前寫過的：），只不過其中的邏輯比較複雜，並且還應用了"模板方法"這一設計模式。因爲本文只是作一個責任鏈模式的簡單入門，這些不作過多展開了。

綜上，充分理解和應用責任鏈設計模式，對咱們的平常工做和閱讀源碼都頗有幫助，能讓咱們有效提升代碼的擴展性和可讀性，但願對你也有所幫助。

---

好了，以上就是本文的所有內容，若是你喜歡這篇文章，記得給我點贊留言哦～大家的支持和承認，就是我創做的最大動力，咱們下篇文章見！

我是小齊，紐約程序媛，終生學習者，天天晚上 9 點，雲自習室裏不見不散！

更多幹貨文章見個人 Github: https://github.com/xiaoqi6666...