大家好，我是網管，今天又上來給大家更新設計模式系列的文章啦，之前已經把四種建造型的設計模式更新齊全啦，沒有看過的小伙伴可以通過點擊上面和文章尾部的系列合集鏈接，進行查看。

在開始講今天的設計模式之前我先問個問題：“你們公司現狀有沒有用 OKR 管理季度或者雙月的個人目標、團隊目標嗎？” 現在越來越多公司開始用 OKR 代替 KPI 做目標管理，兩套目標管理系統的詳細區別我就不說了，因為我也說不清楚。。。哈哈！

我們可以簡單粗暴的理解為 OKR 是自底向上的制定目標，而 KPI 是上頭大老板直接給你拍個目標。但實際施行起來，可能，我是說可能哈，最關鍵的跟公司賺錢活下去的業務目標還是上頭老板直接拍給你，只留下一些類似自己/團隊/公司 積累、進步、成長這些不疼不癢的目標是讓員工自我決定，自底向上完成目標制定。

對于做研發的技術人員來說，個人、團隊、公司上的成長無非就是個人的技術再精進些、系統再優化優化、給公司技術積累增加點方法論實踐什么的，但是呢，你寫目標的時候不能寫的太 Low 了，比如 “重構什么什么流程、提高XXX” 大土話直接拽上去可不行，OKR 講究把話術說的讓別人看了就興奮，讓別人覺得：“我早就想到了一直等你們提出來細化啦”。。。這個別人就是你的直屬領導，因為你的OKR大概率只有它看，更高層的不太會看你的 OKR 。

有的人可能會問了，我來你這學設計模式呢，你跟我說半天 OKR 目標管理干啥？這你就不懂了，如果你能把流程重構這種看起來平平無奇的話細化成運用XXX設計模式重構XX流程，增加其無限擴展業務邏輯的能力、結合 XXX 設計模式減少XX業務重復開發率提升人效XXX，這樣給人的感覺是不是完全不一樣了，那這個設計模式是不是真的能達到你說的效果，如果你領導好幾年不寫代碼了，大概率它是不知道的，但是這些個設計模式在行業里很有名，但凡知道有設計模式這個東西的，都會覺得你這個目標定的很有水平。

當然我這里不是在教大家長袖善舞，而是怎么把一些理論的東西結合實踐表達出來，像 UML、GoF 23 種設計模式、DDD里的某些模式，這些在行業內經過長時間反復驗證行的通的方法論，拿出來就是會讓人覺得很專業、靠譜。

那能表達出來的前提是我們得會，真的得用心思考什么設計模式才能解決當下系統的痛點，接下來就進入咱們學習設計模式的正題。

那在這里我先拋出一個我自己總結的暴論：“模版、策略和職責鏈三個設計模式是解決業務系統流程復雜多變這個痛點的利器”，你可以延伸一下進一步理解成，這三個設計模式也是你在公司里卷 OKR 的利器。當然設計模式里并不是只有這三個是利器，只是這三個最基礎，會了之后思考問題馬上會不一樣，等完全掌握了再跟更復雜的設計模式結合起來使用也不遲，

今天這里給大家先來介紹模版模式，因為策略有些時候步驟里會應用上模版模式，我們就放到下一篇文章再分享。我們先來看下模版模式長什么樣，使用起來代碼該怎么寫，最后再給大家分析用模版模式怎么分析系統現在的問題、或者更進一步你下個季度的 OKR 該怎么定。

什么是模板模式

模版模式，有的也翻譯成模版方法模式，主要是因為這個模式里有個模版方法，不過后面實際應用的時候我會提到，這個模版方法在設計一些有客戶端和服務多次交互的場景里，其實也可以是虛擬的，我們自己形成意識設計API即可，不一定非要在設計模式的類實現里真實存在。

當要做一件事兒的時候，這件事兒的流程和步驟是固定好的，但是每一個步驟的具體實現方式是不一定的。這個時候就可以使用模板模式。

模版模式慣常的用法是，在一個方法模版方法中定義一個算法或者邏輯的流程和步驟，比如先調內部的方法A 再調內部方法B，滿足某個條件了不調方法 C 等等，而這個流程中每個步驟對應的方法都可以推遲到子類中去實現，這就給了程序在不改變大流程、步驟的情況下，完成相似性業務的能力。

模版模式實現起來非常簡單，用抽象類定義好步驟，提供步驟的默認實現，具體業務邏輯上每個步驟的實現差異交給子類去實現就可以。模版模式的結構用 UML 類圖可以這么表示

下面舉一個我們都見過的業務流程的例子，結合代碼實現讓大家更好地體會下模版模式怎么使用，如果是 Java 來實現模版模式的話真的是非常簡單，直接用抽線類和子類實現就完事了，網上資料有很多我就不多說，下面我用 Go 代碼實現一下模版設計模式，主要是因為 Go 不支持繼承，但是又有類型匿名嵌套實現差不多繼承的效果，所以代碼寫起來會繞點彎。

模板模式用法舉例

比如我們去銀行柜臺辦理業務，存款、取款、購買理財等這些業務的流程中都會有：取號、排位等號、處理業務、服務評價這幾個步驟，如果你是金葵花之類的VIP用戶，有可能有專屬窗口不用排隊，檢查用戶是不是VIP這樣步驟叫做鉤子方法。

// 本文使用的完整可運行源碼
// 去公眾號「網管叨bi叨」發送【設計模式】即可領取
type BankBusinessHandler interface {
 // 排隊拿號
 TakeRowNumber()
 // 等位
 WaitInHead()
 // 處理具體業務
 HandleBusiness()
 // 對服務作出評價
 Commentate()
 // 鉤子方法，
    // 用于在流程里判斷是不是VIP， 實現類似VIP不用等的需求
 checkVipIdentity() bool
}

模板方法，由于 Go 不支持抽象類和子類繼承，我們通過類型匿名嵌套來實現，由一個外層類型包裝組合BankBusinessHandler接口的實現達到與抽象類和子類繼承類似的效果。

// 本文使用的完整可運行源碼
// 去公眾號「網管叨bi叨」發送【設計模式】即可領取
type BankBusinessExecutor struct {
 handler BankBusinessHandler
}
// 模板方法，處理銀行業務
func (b *BankBusinessExecutor) ExecuteBankBusiness () {
 // 適用于與客戶端單次交互的流程
 // 如果需要與客戶端多次交互才能完成整個流程，
    // 每次交互的操作去調對應模板里定義的方法就好，并不需要一個調用所有方法的模板方法
 b.handler.TakeRowNumber()
 if !b.handler.CheckVipIdentity() {
  b.handler.WaitInHead()
 }
 b.handler.HandleBusiness()
 b.handler.Commentate()
}

模版模式里：存款、取款與銀行客戶業務這三者的關系，可以用下面的 UML 圖清晰地展示出來：

接下來我們就可以在子類里實現每個銀行客戶業務的邏輯啦，但是不管哪個業務，都脫離不了取號、等位、辦業務、評價服務的大流程。

下面用模板模式實現一下存款業務的流程，代碼如下：

"完整可運行源碼，私信給
公眾號「網管叨bi叨」發送【設計模式】即可領取"
type DepositBusinessHandler struct {
 *DefaultBusinessHandler
 userVip bool
}

// 通用的方法還可以抽象到BaseBusinessHandler里，組合到具體實現類里，減少重復代碼（實現類似子類繼承抽象類的效果）
func (*DepositBusinessHandler) TakeRowNumber() {
 fmt.Println("請拿好您的取件碼：" + strconv.Itoa(rand.Intn(100)) +
  " ，注意排隊情況，過號后順延三個安排")
}

func (dh *DepositBusinessHandler) WaitInHead() {
 fmt.Println("排隊等號中...")
 time.Sleep(5 * time.Second)
 fmt.Println("請去窗口xxx...")
}

func (*DepositBusinessHandler) HandleBusiness() {
 fmt.Println("賬戶存儲很多萬人民幣...")
}

func (dh *DepositBusinessHandler) CheckVipIdentity() bool {
 return dh.userVip
}


func (*DepositBusinessHandler) Commentate() {

 fmt.Println("請對我的服務作出評價，滿意請按0，滿意請按0，(～￣▽￣)～")
}

執行存款業務的流程則由外部包裝類定義的統一模板方法負責發起和調用每個步驟。

func NewBankBusinessExecutor(businessHandler BankBusinessHandler) *BankBusinessExecutor {
 return &BankBusinessExecutor {handler: businessHandler}
}

func main()  {
 dh := &DepositBusinessHandler{userVip: false}
 bbe := NewBankBusinessExecutor(dh)
 bbe.ExecuteBankBusiness()
}

上面實現存款業務流程的時候，我們會發現，像排隊取號，等位、服務評價這幾個方法，各個銀行業務的實現都一樣。 所以就可以把它們放在抽象類中可以進一步減少代碼的重復率。

但是 Go 不是完全面向對象的語言，不過我們可以用類型的匿名嵌套組合來實現相似的效果，把這幾個操作的方法交給DefaultBusinessHandler類型實現，再由具體實現類組合它，同樣能達到減少重復實現相同邏輯的效果。

"完整可運行源碼，私信給
公眾號「網管叨bi叨」發送【設計模式】即可領取"
type DefaultBusinessHandler struct {
}
func (*DefaultBusinessHandler) TakeRowNumber() {
 fmt.Println("請拿好您的取件碼：" + strconv.Itoa(rand.Intn(100)) +
  " ，注意排隊情況，過號后順延三個安排")
}

func (dbh *DefaultBusinessHandler) WaitInHead() {
 fmt.Println("排隊等號中...")
 time.Sleep(5 * time.Second)
 fmt.Println("請去窗口xxx...")
}

func (*DefaultBusinessHandler) Commentate() {

 fmt.Println("請對我的服務作出評價，滿意請按0，滿意請按0，(～￣▽￣)～")
}

func (*DefaultBusinessHandler) CheckVipIdentity() bool {
 // 留給具體實現類實現
 return false
}

func NewBankBusinessExecutor(businessHandler BankBusinessHandler) *BankBusinessExecutor {
 return &BankBusinessExecutor {handler: businessHandler}
}

注意，上面的DefaultBusinessHandler并沒有實現我們想要留給具體子類實現的HandleBusiness方法，這樣 DefaultBusinessHandler 就不能算是BankBusinessHandler接口的實現，這么做是為了這個類型只能用于被實現類包裝，讓 Go 語言的類型檢查能夠幫我們強制要求，必須用存款或者取款這樣子類去實現HandleBusiness方法，整個銀行辦理業務的流程的程序才能運行起來。

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

模板模式的使用建議不一定非要有模版方法

這里，我們例子里這種定義模板方法的方式適用于與客戶端單次交互的流程

type BankBusinessExecutor struct {
 BankBusinessHandler
}

// 模板方法，處理銀行業務
func (b *BankBusinessExecutor) ExecuteBankBusiness () {
 b.TakeRowNumber()
 if !b.CheckVipIdentity() {// VIP 不用等位
  b.WaitInHead()
 }
 b.HandleBusiness()
 b.Commentate()
}

如果需要與客戶端多次交互才能完成整個流程，可以每個交互的操作去使用模板里定義的方法，這個時候，并不需要定義一個調用所有方法的模板方法，這種情況下，也可以理解成，整個流程用到的 RESTful API 接口組合扮演的就是模板方法的角色。

在互聯網里C端產品里的典型應用場景，比如：用戶經營類的活動API，所有活動都可以抽象成：展示活動信息、獎品信息、判斷用戶資格、參與活動、抽獎、查看中獎記錄、核銷獎品這些步驟。那么我們可以利用模板設計模式來對業務流程做抽象，實現各種用戶活動都能用一套統一的RESTful API 來支撐業務的效果。

模版與工廠結合使用

還有這里再說一點，在實際開發中，從來沒有哪個設計模式是可以獨立應用的，更多的時候是幾個設計模式聯合使用，群策群力、相輔相承來達到項目設計的效果。

而由模版模式把流程的實現邏輯推遲到子類，我們大概也能想到，創建模版子類這個工作交給工廠模式是再合適不過的了，具體使用哪種工廠？一般簡單工廠就好，項目剛開始的時候，一般情況下，業務需求和流程我們挖掘的還不夠全面，所以一開始的時候不要做太深度的提煉和抽象，等到確實需要的時候再升級到抽象工廠也未嘗不可。

模版模式的優缺點

模板方法模式的優點

利用模板方法將相同處理邏輯的代碼放到抽象父類中，可以提高代碼的復用性。

將不同的算法邏輯分離到不同的子類中，通過對子類的擴展增加新的行為，提高代碼的可擴展性。

把不變的行為寫在父類上，去除子類的重復代碼，提供了一個很好的代碼復用平臺，符合開閉原則。

模板方法模式的缺點

• 由于繼承關系自身的缺點，如果父類添加新的抽象方法，則所有子類都要改一遍。

模版模式這么好，那我們是不是所有流程都要應用上呢？肯定不是，它更適合于經過我們大量實踐后，能把某個核心流程提煉成固定步驟的時候再應用。如果提煉的不到位，就得頻繁增加或者修改流程里的步驟--也就是修改表示流程的 interface 或者抽象類里的方法。這個時候，如果現有業務中已經存在了多個該流程的實現類的話，那么它們都得做出相應調整才行。

模版模式與 OKR 的結合

學完模版模式后我們再來說說怎么用這個設計模式的思想為指導，讓你發現現有業務系統中需要改進的流程。 互聯網公司，某項業務剛開始，可以簡單粗暴，先上線，即使早期該業務相似流程多，代碼重復率高也沒事，等到跑個一段時間，這個業務流程確定要長期做下去，我們對其的理解和抽象提煉也到位后，就可以主動思考怎么通過模版模式對流程進行優化啦。

就像上面舉的那個很經典的例子，在大部分互聯網公司的產品生態里都會有一些促活、拉新、提升客單價的用戶活動，實現形式往往就是種樹、福袋開獎、轉盤開獎之類的，早期業務發展期因為這類活動形態有很多，程序員并不知道產品過兩天又回規劃出什么活動內容來，所以一般都是一個活動一組API、一組類。

那么這個時候你就可以嘗試用模版模式的思維模式，思考找出這些相似業務具有通用步驟，是不是把每個同類業務往這套模版上的步驟里套都能實現，如果不行的話，再繼續思考和提煉。

假設你在的公司正好是以 OKR 做續期管理的，那么你就可以把提煉核心流程、減少代碼重復開發量、提高相似業務上線效率這些方面作為目標，把他們寫到OKR里，這個過程中既提高了我們技術上的流程抽象設計能力，也向上管理了組織對我們的預期，是不是不失為一個向上管理的好方法呀。