哈嘍，各位新來的小夥伴們，大家好！由於公眾號做了改版，為了保證公眾號的資源能準時推送到你手裡，大家記得將咱們的公眾號加星標置頂，在此真誠的表示感謝~
正文如下：
前言
對於已經工作了的小夥伴，你應該是見過“責任鏈”這種面向物件的設計模式的，還在上學的小夥伴也不用著急，你遲早會接觸到的。本文旨在讓小白同學和不太熟悉責任鏈的朋友能夠迅速對這一設計模式有一個大致的瞭解。
在我們的工農業生產中，經常有這樣的場景：一個任務、事務、流程等都需要很多不同的步驟，來完成不同的計算或者收集不同的資料。
為了維護一個比較複雜，有時甚至是對順序敏感的任務流程，我們經常在程式碼的編寫和設計上採用“責任鏈”設計模式。
究竟什麼是“責任鏈”呢？咱們看下面這個例子。
例子
假設你也“穿越”到了清朝，是會寫程式碼的和珅和中堂，皇上馬上要南巡。請你用程式碼封裝並模擬“乾隆下江南”這件事。
你要怎麼安排萬歲爺的行程？要知道這可是個大工程，中間可不能有差錯，一旦出了什麼岔子可是要掉腦袋的
但皇上又是性情中人，行程可能經常更改，甚至半路就微服私訪。
所以我們在伺候皇上下江南的時候，既得讓皇上的行程有序進行，又要儘量適應聖上由於一時興起而可能做出的變化。
怎麼設計呢？如果把皇上的行程都寫在一起執行，有兩個不好的地方：
行程太多，而且全都事關重大，這麼遠的路，全都要你一個人打理，哪裡一不注意出了亂子，腦袋就要搬家；
行程多，所以增改起來太麻煩，一旦有改動聖上的行程表容易亂。畢竟行程寫在一起，好似一堆亂麻，條理不清。
所以問題來啦，和大人您可怎麼排聖上的行程呢？
和大人莫急，看看地圖我們就知道，乾隆從北京到杭州要順序經過直隸、山東、江蘇、浙江四省（基本就是現在京滬高鐵的路子）：
這樣和大人就可以按省把任務大致劃分為四個部分，責成四省的官員們分擔這一個大工程，把他們應盡的的責任連成一個有序的鏈條，然後依次讓他們執行伺候皇上的任務。
這樣一來解決了行程過於豐富，和大人一個人安排不過來的問題，二來保證了各個步驟的靈活安排（後面的例子講），三來哪一步出了問題還便於問責（甩鍋，否則全是自己的錯）。
好了，說了這麼多，現在切入技術層面。
設計
Step1：
首先總結一下我們所研究的問題中的名詞，來確定大概需要哪些類：
皇帝（乾隆）
行程的管理者（和中堂）
各省官員（具體幹活的公僕們）
Step2：
再來確定各個類之間的關係：
最容易看出來的是各省官員是同僚關係，他們都要接待乾隆，只是在皇上南巡的過程中出場順序和做的具體接待行為不一樣，比如：
直隸總督會帶乾隆去避暑山莊，
山東巡撫會張羅著皇上祭拜孔廟，
蘇州織造讓皇上游覽園林，
而杭州知州就帶著皇上去西湖蘇堤。
這裡告訴大家 OOD 中一個最佳化設計的小口訣：變化的抽介面，相同的建模版。
所以我們在這裡面對官員們不同的行為，最好把他們抽象成介面或者抽象類，這裡我們採用官員（Official）這個抽象類。
而和大人作為總管，他既要掌握皇帝的動向，又要轄制各省官員，所以在類的層面上和大人（PrimeMinister）這個類就得有指向皇帝（Emperor）和官員列表的引用。
下面上 UML 圖。
UML 圖
各省同僚：
而你和大人，作為乾隆面前的紅人，得統籌安排皇帝的行程，既要挾持皇帝，又要掌管各省官員，讓他們有序地執行任務：
責任鏈一般都至少有一個被處理的物件，作為引數傳入各個步驟，這裡的乾隆就是這個被處理（伺候）的物件。
程式碼
作為官員這個抽象類，我們考慮到實際情況，他要安排一個地方並陪同皇帝參觀、遊覽，其實就是一句話：伺候皇上。
所以他有一個抽象方法 serve，接受皇帝（Emperor）這個物件
這裡為了區別不同的官員，我們還給了官員（Official）類一個成員變數 title。
Official 下面有具體實現的類，代表各省官員，他們自己有自己具體的方式去服務吾皇，比如直隸總督，他是這麼幹的：
這裡在 serve 裡面完全讓引數“皇帝”自己決定怎麼玩，（順便說句題外話，這種讓引數這個“外來的和尚”唸經的方式，在各種設計模式裡很常見。如果把這裡的 Emperor 換成 Comparator，相信很多小夥伴就感覺有點像策略模式了。而且“直隸總督”也可以在皇帝 play 之前或者之後分別做一些事情，這像不像用 JDK 的代理的時候中那個 InvocationHandler 對待 Method 的方式？或者 Spring 中對於 Aspect 的處理？另外在 Visitor 等設計模式中你也能看到這種寫法的身影）
其他官員的寫法類似，只是換個地方供皇帝遊覽而已，參見後面的輸出結果，這裡略。
而作為皇帝，乾隆只管著玩就好，當然了，你和中堂可以安排當地的官員陪同，所以皇帝類只有一個 play 方法，這裡用一個字串簡單表示去遊覽的地方。
為了防止乾隆南下期間有人在北京“另立新君”（執行 new Emperor（）），這個“皇帝”物件的建立過程採用了單例模式，保證整個 JVM 裡面就只有這麼一個皇上，而且名字叫“乾隆”：
而你，和珅和大人，只需要按各省順序，合理安排好下面的官員，然後請出皇上並昭告天下：聖上下江南了，沿途各省小心伺候就好：
看看，你的任務是不是簡明多了，只需要維護好這個沿途各省官員的花名冊即可。
更重要的是，你不用親自負責了，下面的人誰辦事不力，就要誰的腦袋！
只要自己的這個“花名冊”或者“行程表”沒寫錯，咱的腦袋就算保住啦。
而且各個官員的任務也比較單一，他們自己也更不容易出錯。下面是整個行程模擬的執行情況：
嗯，一切看上去似乎還不錯，各省官員按照順序，依次完成了任務，把萬歲爺伺候的還不錯，沒有什麼異常狀況發生，總算鬆了口氣。
但是，現在來了個突發情況：皇上突然要求，在路過山東的時候加一個環節——大明湖畔三日遊！
為啥要特意去那裡？咱也不敢問吶！只管準備就好。
幸好我們的行程又已經有了大致框架，趕緊查，大明湖那裡歸誰管，哦，濟南知府，就是他了！
現在只需把他也加到“花名冊”：責令濟南知府安排皇上在大明湖畔三天的行程，不得有誤，否則拿你試問！下面是和大人這邊要做的改動：
而另一邊濟南知府這裡，他也是屬於官僚體制了（Official 的子類），所以也要極盡所能，讓聖上在大明湖畔玩得開心：
再次執行程式，模擬聖上的行程，結果輸出如下：
嗯，這下總算又迎合了聖意，以後皇上再來什麼其他的行程也不怕了（只要他不微服私訪，微服私訪您找紀曉嵐去啊，單一責任原則，專門的類幹專門的事兒不是？）。
只要找到當地具體的官員，一紙命令：你給我極盡所能招待皇上，具體怎麼招待，你看著辦，伺候不好萬歲爺，我要你腦袋！
當然了，皇帝也可能臨時刪掉南巡中的某個環節，我們直接把它從行程列表中刪除就好，而且什麼時候想再重新加進來還可以隨時新增，做到了可以“靈活插拔”，把程式碼的改動減到了最小，有新的業務邏輯加進來的時候，只是做新增，這樣既不容易出錯，也確保了程式碼的彈性擴充套件，而且當前責任鏈中的步驟，如果沒有狀態相關的資訊的話，也可以被組裝到其他的責任鏈中。
如果是我們的真實專案，我們甚至可以把工作步驟的列表配置在 Spring Boot 的配置檔案裡，開啟流程的這個類，只要讀取配置，然後把各個步驟依次執行。
這樣如果有修改只要改動配置檔案即可，在 Java 程式碼裡無需任何改動。
總結與拓展
以上其實只是一個責任鏈模式最簡單的應用，它是一個有序列表裡面裝了各個任務的步驟，然後依次執行到最後。
我們可以把它寫在自己的程式裡，也可以把它抽象出來做成產品，讓其他人自由擴充套件與配置，儘量減少重複製造輪子。
有很多工作流引擎便是這樣，比如 、 的 等。不光這些，就連你最常用的 甚至是 都用到了責任鏈模式，只不過他們的責任鏈是雙向的，分別處理請求和響應，而且他們的處理順序是剛好相反的，本質上是用類似遞迴的方法正序倒序各便歷了一次（Filter 或 Interceptor 的）陣列。
另外在一些持續整合和持續部署的框架中，如 ，會有管道（Pipeline）的概念，當你在做出 提交程式碼之後，會觸發整個流程開始一步步地運作：拉取程式碼（Checkout code）、構建（Build）、測試（Test）等，直到部署（Deploy）完成並執行指令碼關閉舊版本的服務並啟動最新部署的服務。這個“流水線”（Pipeline）其實也是一個可以讓你用程式碼指令碼來配置的責任鏈。
沒有責任鏈模式的應用，你甚至都無法執行任何一個 程式。因為類載入一般遵循“雙親委派”機制，實際上是用類似遞迴的方法正序和倒序各便歷了一次 類所構成的連結串列（題外話，想把一個連結串列翻轉過來，可以參見齊姐之前寫過的：），只不過其中的邏輯比較複雜，而且還應用了“模板方法”這一設計模式。由於本文只是做一個責任鏈模式的簡單入門，這些不做過多展開了。
綜上，充分理解和應用責任鏈設計模式，對我們的日常工作和閱讀原始碼都很有幫助，能讓我們有效提高程式碼的擴充套件性和可讀性，希望對你也有所幫助。
熱門推薦：
