你也是業務開發？提前用這個設計模式預防產品加需求吧

大家好，我是每週在這裏陪大家一起進步的網管。

今天繼續更新設計模式相關的文章，我在前面兩篇關於模板模式和策略模式的文章裏給大家說過一個我總結的 "暴論"：“模板、策略和職責鏈三個設計模式是解決業務系統流程複雜多變這個痛點的利器”。這篇文章我們就來一起說說這第三個設計模式利器—職責鏈模式。

職責鏈模式

職責鏈——英文名 Chain of responsibility 有時也被翻譯成責任鏈模式。我看網上叫責任鏈的更多一些，這裏大家知道它們是一個東西就行了。

它是一種行爲型設計模式。使用這個模式，我們能爲請求創建一條由多個處理器組成的鏈路，每個處理器各自負責自己的職責，相互之間沒有耦合，完成自己任務後請求對象即傳遞到鏈路的下一個處理器進行處理。

職責鏈在很多流行框架裏都有被用到，像中間件、攔截器等框架組件都是應用的這種設計模式，這兩個組價大家應該用的比較多。在做 Web 接口開發的時候，像記錄訪問日誌、解析 Token、格式化接口響應的統一結構這些類似的項目公共操都是在中間件、攔截器裏完成的，這樣就能讓這些基礎操作與接口的業務邏輯進行解耦。

中間件、攔截器這些組件都是框架給我們設計好的直接往裏面套就可以，今天我們的文章裏要講的是，怎麼把職責鏈應用到我們核心的業務流程設計中，而不僅僅是隻做那些基礎的公共操作。

職責鏈的價值

上面我們說了職責鏈在項目公共組件中的一些應用，讓我們能在覈心邏輯的前置和後置流程中增加一些基礎的通用功能。但其實在一些核心的業務中，應用職責鏈模式能夠讓我們無痛地擴展業務流程的步驟。

比如淘寶在剛剛創立的時候購物生成訂單處理流程起初可能是這樣的。

職責鏈模式—購物下單—清純版

整個流程比較乾淨 "用戶參數校驗 -- 購物車數據校驗 -- 商品庫存校驗 -- 運費計算 -- 扣庫存—生成訂單"，我們姑且把它稱爲清純版的購物下單流程，這通常都是在產品從 0 到 1 的時候，流程比較清純，在線購物你能實現在線選品、下單、支付這些就行了。

不過大家都是互聯網衝浪老手了，也都是喫過見過的主，這個流程要是一直這麼清純，公司的 PM 和運營就可以走人了。等購物網站跑起來，有消費者了之後，爲了提高銷售額，一般會加一些，某些品類商品滿減的促銷手段。

運營也不能閒着，多談點客戶，造個購物節，到時候優惠券安排上多吸引點用戶。那這樣在下訂單的流程中，就得判斷購物車裏的商品是否滿足折扣條件、用戶是否有優惠卷，有的話進行金額減免。相當於我們下單的內部流程中間加了兩個子流程。

職責鏈模式—購物下單—老練版

爲了實現新加的邏輯，我們就得在寫好的訂單流程中最起碼加兩個 if else 分支才能加上這兩個邏輯。不過最要命的是因爲整個流程耦合在一起，修改了以後我們就得把整個流程全測一遍。並且有了上面的經驗我們也應該知道這個流程以後肯定還會擴展，比如再給你加上社羣砍一刀、拼單這些功能，以後每次在訂單生成流程中加入步驟都得修改已經寫好的代碼，怕不怕？

有朋友可能會說，互聯網電商購物可能確實流程比較多樣化，每個公司的流程不一樣。我們再舉個病人去醫院看病的例子，病人看病大體上基本步驟需要有：

掛號—> 診室看病—> 收費處繳費—> 藥房拿藥

但是有可能有的病人需要化驗、拍片子等等，他們在醫院就醫的流程可能是這樣的：

掛號—> 初診—> 影像科拍片—> 複診室—> 收費處繳費—> 藥房拿藥

所以就醫這個流程也是會根據病人情況的不同，步驟有所增加的。

那麼現在我們可以確定：假如一個流程的步驟不固定，爲了在流程中增加步驟時，不必修改原有已經開發好，經過測試的流程，我們需要讓整個流程中的各個步驟解耦，來增加流程的擴展性，這種時候就可以使用職責鏈模式啦，這個模式可以讓我們先設置流程鏈路中有哪些步驟，再去執行。

用職責鏈模式實現流程

如果讓我們設計責任鏈應該怎麼設計呢？應該提供和實現哪些方法？怎麼使用它把流程裏的步驟串起來呢？這裏我們用職責鏈模式把就診看病這個場景中的流程步驟實現一遍給大家做個演示，購物下單的流程類似，咱們下去可以自己嘗試實現一遍，先學會職責鏈模式的結構做些 Mock 示例，掌握熟練了後面再嘗試着用它解決業務中的問題。

首先我們通過上面流程擴展的痛點可以想到，流程中每個步驟都應由一個處理對象來完成邏輯抽象、所有處理對象都應該提供統一的處理自身邏輯的方法，其次還應該維護指向下一個處理對象的引用，當前步驟自己邏輯處理完後，就調用下一個對象的處理方法，把請求交給後面的對象進行處理，依次遞進直到流程結束。

總結下來，實現責任鏈模式的對象最起碼需要包含如下特性：

如果抽象成 UML 類圖表示的話，差不多就是下面這個樣子。定義了一個職責鏈模式處理對象的接口Handler，由ConcreteHandler -- 具體處理對象的類型來實現。

觀察上圖以及上面對象特性的分析，其實是能看出 SetNext 和 Execute 這兩個行爲是每個 ConcreteHandler 都一樣的，所以這兩個可以交給抽象處理類型來實現，每個具體處理對象再繼承抽象類型，即可減少重複操作。

所以責任鏈模式的抽象和提煉可以進化成下圖這樣：

瞭解完職責鏈模式從接口和類型設計上應該怎麼實現後，我們進入代碼實現環節，職責鏈模式如果用純面向對象的語言實現起來還是很方便的，把上面的 UML 類圖直接翻譯成接口、抽象類，再搞幾個實現類就完事。

想把上面這個 UML 類圖翻譯成 Go 代碼還是有點難度的。這裏咱們提供一個用 Go 實現職責鏈模式完成醫院就診流程的代碼示例。

職責鏈 Go 代碼實現

雖然 Go 不支持繼承，不過我們還是能用類型的匿名組合來實現，下面以病人去醫院看病這個處理流程爲例提供一個具體示例。

看病的具體流程如下：

掛號—> 診室看病—> 收費處繳費—> 藥房拿藥

我們的目標是利用責任鏈模式，實現這個流程中的每個步驟，且相互間不耦合，還支持向流程中增加步驟。

先來實現職責鏈模式裏的公共部分—即模式的接口和抽象類

"本文使用的完整可運行源碼
去公衆號「網管叨bi叨」發送【設計模式】即可領取"
type PatientHandler interface {
 Execute(*patient) error
 SetNext(PatientHandler) PatientHandler
 Do(*patient) error
}
// 充當抽象類型，實現公共方法，抽象方法不實現留給實現類自己實現
type Next struct {
 nextHandler PatientHandler
}

func (n *Next) SetNext(handler PatientHandler) PatientHandler {
 n.nextHandler = handler
 return handler
}

func (n *Next) Execute(patient *patient) (err error) {
 // 調用不到外部類型的 Do 方法，所以 Next 不能實現 Do 方法
 if n.nextHandler != nil {
  if err = n.nextHandler.Do(patient); err != nil {
   return
  }

  return n.nextHandler.Execute(patient)
 }

 return
}

上面代碼中Next類型充當了模式中抽象類的角色，關於這個Next類型這裏再重點說明一下。

在我們的職責鏈的 UML 圖裏有說明Do方法是一個抽象方法，留給具體處理請求的類來實現，所以這裏Next類型充當抽象類型，只實現公共方法，抽象方法留給實現類自己實現。並且由於 Go 並不支持繼承，即使Next實現了Do方法，也不能達到在父類方法中調用子類方法的效果—即在我們的例子裏面用Next 類型的Execute方法調用不到外部實現類型的Do方法。

所以我們這裏選擇Next類型直接不實現Do方法，這也是在暗示這個類型是專門用作讓實現類進行內嵌組合使用的。

接下來我們定義職責鏈要處理的請求，再回看一下我們的 UML 圖，實現處理邏輯和請求傳遞的Do、Execute方法的參數都是流程中要處理的請求。這裏是醫院接診的流程，所以我們定義一個患者類作爲流程的請求。

//流程中的請求類--患者
type patient struct {
 Name              string
 RegistrationDone  bool
 DoctorCheckUpDone bool
 MedicineDone      bool
 PaymentDone       bool
}

然後我們按照掛號—> 診室看病—> 收費處繳費—> 藥房拿藥這個流程定義四個步驟的處理類，來分別實現每個環節的邏輯。

"本文使用的完整可運行源碼
去公衆號「網管叨bi叨」發送【設計模式】即可領取"
// Reception 掛號處處理器
type Reception struct {
 Next
}

func (r *Reception) Do(p *patient) (err error) {
 if p.RegistrationDone {
  fmt.Println("Patient registration already done")
  return
 }
 fmt.Println("Reception registering patient")
 p.RegistrationDone = true
 return
}

// Clinic 診室處理器--用於醫生給病人看病
type Clinic struct {
 Next
}

func (d *Clinic) Do(p *patient) (err error) {
 if p.DoctorCheckUpDone {
  fmt.Println("Doctor checkup already done")
  return
 }
 fmt.Println("Doctor checking patient")
 p.DoctorCheckUpDone = true
 return
}

// Cashier 收費處處理器
type Cashier struct {
 Next
}

func (c *Cashier) Do(p *patient) (err error) {
 if p.PaymentDone {
  fmt.Println("Payment Done")
  return
 }
 fmt.Println("Cashier getting money from patient patient")
 p.PaymentDone = true
 return
}

// Pharmacy 藥房處理器
type Pharmacy struct {
 Next
}


func (m *Pharmacy) Do (p *patient) (err error) {
 if p.MedicineDone {
  fmt.Println("Medicine already given to patient")
  return
 }
 fmt.Println("Pharmacy giving medicine to patient")
 p.MedicineDone = true
 return
}

處理器定義好了，怎麼給用他們串成患者就診這個流程呢？

func main() {
 receptionHandler := &Reception{}
 patient := &patient{Name: "abc"}
 // 設置病人看病的鏈路
 receptionHandler.SetNext(&Clinic{}).SetNext(&Cashier{}).SetNext(&Pharmacy{})
  receptionHandler.Execute(patient)
}

上面的鏈式調用看起來是不是很清爽，嘿嘿別高興太早，這裏邊有個 BUG— 即Recepiton接診掛號這個步驟提供的邏輯沒有調用到，所以我們這裏再定義個StartHandler 類型，它不提供處理實現只是作爲第一個Handler向下轉發請求

"本文使用的完整可運行源碼
去公衆號「網管叨bi叨」發送【設計模式】即可領取"
// StartHandler 不做操作，作爲第一個Handler向下轉發請求
type StartHandler struct {
 Next
}

// Do 空Handler的Do
func (h *StartHandler) Do(c *patient) (err error) {
 // 空Handler 這裏什麼也不做 只是載體 do nothing...
 return
}

這也是 Go 語法限制，公共方法Exeute並不能像面向對象那樣先調用this.Do 再調用this.nextHandler.Do 具體原因咱們上邊已經解釋過了，如果覺得不清楚的可以拿 Java 實現一遍看看區別，再琢磨一下爲啥 Go 裏邊不行。

所以整個流程每個環節都能被正確執行到，應該這樣把處理類串起來。

"本文使用的完整可運行源碼
去公衆號「網管叨bi叨」發送【設計模式】即可領取"
func main() {
 patientHealthHandler := StartHandler{}
 //
 patient := &patient{Name: "abc"}
 // 設置病人看病的鏈路
 patientHealthHandler.SetNext(&Reception{}).// 掛號
  SetNext(&Clinic{}). // 診室看病
  SetNext(&Cashier{}). // 收費處交錢
  SetNext(&Pharmacy{}) // 藥房拿藥
 //還可以擴展，比如中間加入化驗科化驗，圖像科拍片等等

 // 執行上面設置好的業務流程
 if err := patientHealthHandler.Execute(patient); err != nil {
  // 異常
  fmt.Println("Fail | Error:" + err.Error())
  return
 }
 // 成功
 fmt.Println("Success")
}

本文的完整源碼，已經同步收錄到我整理的電子教程裏啦，可向我的公衆號「網管叨 bi 叨」發送關鍵字【設計模式】領取。

總結

職責鏈模式所擁有的特點讓流程中的每個處理節點都只需關注滿足自己處理條件的請求進行處理即可，對於不感興趣的請求，會直接轉發給下一個節點對象進行處理。

另外職責鏈也可以設置中止條件，針對我們文中的例子就是在 Execute 方法里加判斷，一旦滿足中止後就不再繼續往鏈路的下級節點傳遞請求。Gin 的中間件的abort方法就是按照這個原理實現的，同時這也是職責鏈跟裝飾器模式的一個區別，裝飾器模式無法在增強實體的過程中停止，只能執行完整個裝飾鏈路。

後面大家可以看看針對那些可能未來經常會變的核心業務流程，可以在設計初期就考慮使用職責鏈來實現，減輕未來流程不停迭代時不好擴展的痛點。當然職責鏈也不是萬能的，對於那些固定的流程顯然是不適合的。咱們千萬不要手裏拿着錘子就看什麼都是釘子，所有的設計模式一定要用在合適的地方。

既然這裏提到了裝飾器，那麼下一期就寫寫裝飾器吧，不對，裝飾器算是代理模式的一個特殊應用，那就還是先介紹代理未來再介紹裝飾器吧，這樣閱讀體驗會更好一些。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/zCh12E10JM24EGTyFS7hPQ

猜你喜歡