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

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

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

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

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

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

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

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

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

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

我們從兩個(gè)方面來思考這個(gè)問題：

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

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

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

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

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

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

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

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

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

圖片

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

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

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

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

步驟中有一個(gè)加載訂單支付策略，我們定義了 OrderPayStrategyContract 支付策略接口，由其實(shí)現(xiàn)類去真正發(fā)起對(duì)支付平臺(tái)的調(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)
}