Go 程序裏 if else 分支太多？試着用策略模式治理一下吧_kevinyan

上篇文章我給大家分享了設計模式中的模版模式，給大家講了用模版模式在項目開發時提煉流程、減少重複開發的技巧。同時，在上一篇文章我也分享了我總結的一個暴論，那就是“模板、策略和職責鏈三個設計模式是解決業務系統流程複雜多變這個痛點的利器”。

今天我們繼續接着一起學習一下策略模式，以及用 Go 代碼怎麼實現策略模式。

什麼是策略模式

策略模式是一種行為設計模式，通過策略模式，可以在運行時修改一個對象的行為。很多資料裏對它的定義是：

定義一類算法族，將每個算法分別封裝起來，讓他們可以互相替換，此模式讓算法的變化獨立於使用算法的客户端。

看完策略模式這個定義，你是不是也有一種看了等於沒看的感覺，我一開始看的時候也是這樣，下面我再用一些大白話給大家解釋一下。

白話策略模式

策略模式這個定義乍一看起來，還是挺抽象、挺難懂的，這裏説的算法並不是我們想找工作準備面試時每天要刷的那種算法；定義一類算法族中的算法族説的要完成的某項任務的歸類，舉個例子來説比如用户支付，就是個任務類。

算法族中的每個算法（即策略）則是説的完成這項任務的具體方式，結合我們的例子來説就是可以用支付寶也可以用微信支付這兩種方式 (算法) ，來完成我們定義的用户支付這項任務 (算法族)。

策略模式主要用於允許我們的程序在運行時動態更改一個任務的處理邏輯，常見的應用場景有針對軟件用户羣體的不同策略切換（用一個爛大街的詞兒表達就是千人千面）和業務流程兜底切換。

注意：這裏是為了大家好理解舉了支付這個例子，實際上運行時切換支付方式還是挺複雜的，實踐的時候你可以先從運行時切換通知用户的任務練起。

策略模式要解決的問題是，讓使用客户端跟具體執行任務的策略解耦，不管使用哪種策略完成任務，不需要更改客户端使用策略的方式。

上面説的這些使用策略模式完成任務的整個形態用 UML 圖表示出來，會比較清晰，策略模式的 UML 圖如下：

圖中，主要有四類角色：

客户端：這個客户端可以簡單理解成是發起任務調用的代碼。
抽象策略：就是上面定義中的算法族，是所有具體策略的通用接口，聲明瞭用於執行完成任務的方法。
具體策略：實現了抽象策略，定義了具體應該怎麼完成任務。
上下文：作為客户端和具體策略的中間層，達到客户端與具體策略解耦的效果，它維護指向具體策略的引用，且僅通過抽象策略中定義的接口與具體策略進行交流。常用的實現方式是通過組合

上面類圖裏一個細節，上下文對象引用具體策略類的時候，使用的是組合的方式，讓其私有屬性指向策略接口的具體實現，這樣就能完成在運行時修改執行任務的具體策略的效果（通過SetStrategy方法）。

光看上面的描述和UML圖，還是有點單薄，為了更容易理解，下面咱們再舉個更具體點的例子。

策略模式示例--實現支付策略

舉例環節，接着用我們上面用的用户支付這個任務為例子。比如説在購物 App 上買東西后要付錢，客户端使用微信支付、或者是其他三方在線支付。如果使用策略模式進行解耦，客户端都可以使用同樣的調用方式完成支付，甚至可以在微信支付不能使用時，讓應用無痛地切換到三方支付，來完成支付。

注意這裏的客户端是上面説的，調用上下文的代碼，不是手機APP。

在用代碼實現支付策略前，先用 UML 類圖梳理一下整個實現的大體結構：

PayBehavior：抽象策略，對支付任務進行接口抽象
WxPay 和 ThirdPay ：是具體的策略實現
PaxCtx：上下文對象在這裏有兩個作用，第一是協調自己持有的 PayBehavior 具體實現，完成支付的任務，第二是維護髮起支付需要的支付參數--即圖中的私有屬性payParams。

下面我們把這個 UML 圖轉化為代碼實現，首先是定義PayBehavior 策略的接口

type PayBehavior interface { OrderPay(px *PayCtx) }

有了接口後，我們來定義兩個策略的實現

``` // 具體支付策略實現 // 微信支付 "本文使用的完整可運行源碼去公眾號「網管叨bi叨」發送【設計模式】即可領取" type WxPay struct {} func(WxPay) OrderPay(px PayCtx) { fmt.Printf("Wx支付加工支付請求 %v\n", px.payParams) fmt.Println("正在使用Wx支付進行支付") }

// 三方支付 type ThirdPay struct {} func(ThirdPay) OrderPay(px PayCtx) { fmt.Printf("三方支付加工支付請求 %v\n", px.payParams) fmt.Println("正在使用三方支付進行支付") } ```

有了策略的實現後，還得有個上下文來協調它們，以及持有完成這個任務所必需的那些入參payParams

``` "本文使用的完整可運行源碼去公眾號「網管叨bi叨」發送【設計模式】即可領取" type PayCtx struct { // 提供支付能力的接口實現 payBehavior PayBehavior // 支付參數 payParams map[string]interface{} }

func (px *PayCtx) setPayBehavior(p PayBehavior) { px.payBehavior = p }

func (px *PayCtx) Pay() { px.payBehavior.OrderPay(px) }

func NewPayCtx(p PayBehavior) *PayCtx { // 支付參數，Mock數據 params := map[string]interface{} { "appId": "234fdfdngj4", "mchId": 123456, } return &PayCtx{ payBehavior: p, payParams: params, } } ```

所有這些代碼都準備好後，我們就可以試着運行程序調用它們了。

func main() { wxPay := &WxPay{} px := NewPayCtx(wxPay) px.Pay() // 假設現在發現微信支付沒錢，改用三方支付進行支付 thPay := &ThirdPay{} px.setPayBehavior(thPay) px.Pay() }

這個例子的實現還是比較簡單的，相信大家都能看懂，我覺得最重要的是理解這個代碼框架，後面自己結合實際在項目裏實現策略模式的時候，可以支持拿來套用。

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

下面我們再來説説策略模式和上篇文章學習的模板模式的區別和關聯使用。

策略模式和模板模式

策略模式和模版模式經常配合使用，策略模式是讓完成某個任務的具體方式可以相互切換，而模版模式則是針對一個流程的共性梳理出固定的執行步驟，具體步驟的執行方式下放給子類來實現。兩者解耦的維度不一樣，策略模式在抽象方法的實現裏，經常會用到模板模式。

還是拿我們上面的支付行為舉例子。上面策略模式定義了一個算法族（支付），以及多個具體算法實現（微信、三方支付），讓支付策略對客户端解耦。

上面咱們的示例代碼還是比較簡單的，通常完成支付時，還需要用參數生成簽名、驗證客户端傳過來的簽名、調用支付基礎服務進行預下單、下單等操作，但是每種支付基礎服務設計的接口和交互流程可能會有些小的差別，這個時候就可以用上簽名學的模版模式，統一支付任務內部的流程步驟，策略模式、模版模式相結合使用能讓我們寫的程序更健壯、更容易維護。

最後

好了今天的文章就到這裏了，如果你也想讓自己寫出更好的代碼，想用設計模式解決開發中的痛點，請持續關注後面這個系列的更新，覺得文章不錯就動動手點個在看和贊吧，我們下期再見。