[[352609]]

前言

對于已經工作了的小伙伴，你應該是見過"責任鏈"這種面向對象的設計模式的，還在上學的小伙伴也不用著急，你遲早會接觸到的。本文旨在讓小白同學和不太熟悉責任鏈的朋友能夠迅速對這一設計模式有一個大致的了解。

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

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

究竟什么是"責任鏈"呢?咱們看下面這個例子。

例子

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

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

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

所以我們在伺候皇上下江南的時候，既得讓皇上的行程有序進行，又要盡量適應圣上由于一時興起而可能做出的變化。

怎么設計呢?如果把皇上的行程都寫在一起執行，有兩個不好的地方：

行程太多，而且全都事關重大，這么遠的路，全都要你一個人打理，哪里一不注意出了亂子，腦袋就要搬家;

行程多，所以增改起來太麻煩，一旦有改動圣上的行程表容易亂。畢竟行程寫在一起，好似 一堆亂麻，條理不清。

所以問題來啦，和大人您可怎么排圣上的行程呢?

和大人莫急，看看地圖我們就知道，乾隆從北京到杭州要順序經過直隸、山東、江蘇、浙江四省(基本就是現在京滬高鐵的路子):

這樣和大人就可以按省把任務大致劃分為四個部分，責成四省的官員們分擔這一個大工程，把他們應盡的的責任連成一個有序的鏈條，然后依次讓他們執行伺候皇上的任務。

這樣一來解決了行程過于豐富，和大人一個人安排不過來的問題，二來保證了各個步驟的靈活安排(后面的例子講)，三來哪一步出了問題還便于問責(甩鍋，否則全是自己的錯)。

好了，說了這么多，現在切入技術層面。

設計

Step1:

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

皇帝(乾隆)

行程的管理者(和中堂)

各省官員(具體干活的公仆們)

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 類所構成的鏈表(題外話，想把一個鏈表翻轉過來，可以參見齊姐之前寫過的：)，只不過其中的邏輯比較復雜，而且還應用了"模板方法"這一設計模式。由于本文只是做一個責任鏈模式的簡單入門，這些不做過多展開了。

綜上，充分理解和應用責任鏈設計模式，對我們的日常工作和閱讀源碼都很有幫助，能讓我們有效提高代碼的擴展性和可讀性，希望對你也有所幫助。

本文轉載自微信公眾號「碼農田小齊」，可以通過以下二維碼關注。轉載本文請聯系碼農田小齊公眾號。