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叨」傳送關鍵字【設計模式】領取。

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

策略模式和模板模式

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

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

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

最後

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