上一節(jié)給大家演示講解了訂單支付的業(yè)務(wù)流程中的各個步驟以及怎么在項(xiàng)目中進(jìn)行微信支付的對接。不過現(xiàn)實(shí)的商品支付中一般會在收銀臺頁面讓用戶選擇以什么方式支付--是微信、支付寶或者是其他的什么支付、信用卡支付等等。

所以一般項(xiàng)目接入支付通道的時候不會只接入一種支付通道。這么干除了能避免依賴單一渠道的風(fēng)險(xiǎn)外，更多的還是因?yàn)榛ヂ?lián)網(wǎng)公司常見的營銷玩法為了提高轉(zhuǎn)化率會高度依賴多渠道多場景支付，比如各種簽約支付、先用后付等等。

多場景支付的維護(hù)難度

隨著項(xiàng)目接入的支付渠道越來越多、支持的支付場景和營銷玩法越來越多，你的項(xiàng)目代碼該怎么開發(fā)呢？大多數(shù)情況下就是一個支付場景一個if 條件分支唄，甚至新接入的支付渠道也可以是一個大的 if 代碼分支、渠道的各種支付場景那就大分支里邊套小分支唄。

長此以往代碼的維護(hù)難度可想而之，到后期新加一個邏輯，為了保證上線不翻車，可能要把整個支付中的所有邏輯在測試階段都回歸一遍才敢上線。

那么有沒有什么辦法能讓這種代碼的發(fā)展別那么混亂，我希望給其中一個支付渠道的某類支付場景加了邏輯，測試時只回歸對應(yīng)的場景即可，有什么好辦法嗎？

這就是本節(jié)要給大家介紹的兩個設(shè)計(jì)模式：模版模式和策略模式，我們通過把兩種設(shè)計(jì)模式結(jié)合起來的使用來解決這些問題。

大家看一些開源或者設(shè)計(jì)好的項(xiàng)目的代碼時會覺得好像它用了設(shè)計(jì)模式A，看了一會兒它咋又像設(shè)計(jì)模式B了，咋跟我學(xué)的設(shè)計(jì)模式的教程都不一樣？我想說的是，有這種感覺就對了，用設(shè)計(jì)模式解決實(shí)際問題，通常是多種設(shè)計(jì)模式綜合使用才能解決問題，單一設(shè)計(jì)模式能解決的問題還是太有限了。

設(shè)計(jì)思路

接下來我們進(jìn)入正題，怎么使用模版模式和策略模式來設(shè)計(jì)項(xiàng)目，讓其以一個相對有序、可維護(hù)的發(fā)展趨勢來支撐多渠道多場景支付呢？

我們從兩個方面來思考這個問題：

• 這么多支付渠道，支付場景他們每次執(zhí)行過程中有哪些共同點(diǎn)--即可提煉出來的標(biāo)準(zhǔn)化步驟？
• 找流程步驟中的可切步驟，有沒有可能這個步驟的實(shí)現(xiàn)方式從A切換到了B，代碼解決的流程就從A切換成了B？

如果你分析一通，發(fā)現(xiàn)沒有？ 那不好意思，不是你分析的不對，就是這兩個模式確實(shí)用不上，那么咱就現(xiàn)有的代碼打打補(bǔ)丁，能用就行了，哈哈哈。

接下在咱再說一下為啥要兩種模式結(jié)合起來使用，其實(shí)很簡單，使用它們時的設(shè)計(jì)思路有以下幾點(diǎn)

• 模版限定流程的具體步驟（注：以下步驟請根據(jù)要實(shí)現(xiàn)的流程提煉出來，并不局限下面幾種）

1. 校驗(yàn)請求，檢查必要參數(shù)
2. 防抖防重，避免重復(fù)請求
3. 準(zhǔn)備流程中的必要參數(shù)：對于支付來說有訂單數(shù)據(jù)、用戶數(shù)據(jù)等
4. 發(fā)起流程的關(guān)鍵步驟：支付流程就是發(fā)起相應(yīng)的支付方式
5. 生成響應(yīng)

• 策略決定應(yīng)該怎么支付 （各種支付平臺的普通支付/簽約代扣/....)，返回給客戶端什么樣的結(jié)果。

設(shè)計(jì)實(shí)現(xiàn)

說了這么多，我估計(jì)大家都有點(diǎn)懵了，沒辦法首先要給大家解釋清楚多支付渠道的多支付場景這個業(yè)務(wù)形態(tài)，其次應(yīng)用上設(shè)計(jì)模式后代碼緯度都會讓整個代碼設(shè)計(jì)的理解難度會大幅增加。

針對咱們今天的流程場景，我畫了一個整個代碼設(shè)計(jì)的UML類圖：

圖片

首先我們定義接口 OrderPayTemplateContract，訂單支付的模版--對訂單支付執(zhí)行過程的抽象, 模版方法中決定流程步驟的執(zhí)行順序。

type OrderPayTemplateContract interface {
 CreateOrderPay() (interface{}, error) // 模版方法
 OrderPayHandlerContract
}

OrderPayTemplateContract 中的CreateOrderPay 方法為模版方法，即在它的內(nèi)部決定各個步驟的執(zhí)行順序，我們把流程步驟都放在了 OrderPayHandlerContract 接口中。

// OrderPayHandlerContract 訂單支付的處理器接口--對訂單支付各個主要步驟的抽象
type OrderPayHandlerContract interface {
// CheckRepetition 防重校驗(yàn)
 CheckRepetition() error
// ValidateOrder 檢驗(yàn)Order參數(shù)是否符合預(yù)期
 ValidateOrder() error
// LoadPayAndUserConfig 加載支付配置和支付平臺需要的一些用戶信息--比如微信的openID
 LoadPayAndUserConfig() error
// LoadOrderPayStrategy 加載訂單支付策略
 LoadOrderPayStrategy() error
// HandleOrderPay 發(fā)起支付
 HandleOrderPay() (interface{}, error)
}

步驟中有一個加載訂單支付策略，我們定義了 OrderPayStrategyContract 支付策略接口，由其實(shí)現(xiàn)類去真正發(fā)起對支付平臺的調(diào)用。

type OrderPayStrategyContract interface {
 // CreatePay 實(shí)現(xiàn)支付策略中有關(guān)創(chuàng)建支付的邏輯
 // 可以根據(jù)策略本身決定去怎么實(shí)現(xiàn) 創(chuàng)建訂單|設(shè)置簽約碼|......
 CreatePay(ctx context.Context, order *do.Order, payConfig *OrderPayConfig) (interface{}, error)
}