一. 概述&場景分析
1. 設計模式分類
創建型模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式
結構型模式：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式
行爲模式：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式
2.要學模板方法設計模式，首先需要理解工廠模式（工廠模式是爲了解耦，將對象創建和使用過程完全分開）：
工廠模式可以分爲簡單工廠、工廠方法、抽象工廠，靜態工廠模式
工廠模式優缺點：
優點：代碼結構簡單；獲取產品的過程更加簡單；滿足了開閉原則，即對拓展開放，對修改關閉
缺點：拓展較繁瑣，要拓展時，需同時改動抽象工廠和工廠實現類
3. 模板方法設計模式
什麼是模板方法：
① 定義了一個操作中的算法的骨架，而將部分步驟的實現在子類中完成，模板方法模式使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
② 模板方法模式是所有模式中最爲常見的幾個模式之一，是基於繼承的代碼複用的基本技術，沒有關聯關係。 因此，在模板方法模式的類結構圖中，只有繼承關係。
核心設計要點：
AbstractClass : 抽象類，定義並實現一個模板方法。這個模板方法定義了算法的骨架，而邏輯的組成步驟在相應的抽象操作中，推遲到子類去實現
ConcreteClass : 實現實現父類所定義的一個或多個抽象方法
白話文解釋：定義一個抽象類，相同的方法自己寫（不是抽象方法），不同的寫個抽象方法留給子類實現(抽象方法)
場景分析：如下圖所示，即聚合支付平臺的支付回調代碼，多家支付回調通知參數報文都不相同，通知行爲(改狀態)是相同的
暫定異步回調流程爲：
① 解析報文（驗證簽名）
② 日誌收集（相同）
③ 如果解析報文成功的話，修改支付狀態爲已支付.返回不同的支付結果
此時，可以利用模板方法設計模式重構代碼！
二. 代碼實現
1. 定義抽象類（共同骨架），其中200響應碼是在實現中定義的，這裏判斷如果不爲200，則驗籤失敗，由於支付寶，微信，銀聯的返回失敗的結果都是不一樣的，則又定義一個抽象方法resultFail()讓子類去實現，同樣的也定義成功抽象方法resultSuccess()
2. 定義具體實現（第1步爲驗籤，第3步爲解析報文，返回結果，第2步爲相同行爲，在抽象類封裝好了，不需要實現）
① 支付寶回調實現
② 銀聯回調實現
3. 使用工廠模式獲取具體實現模版
附上SpringUtils工具類源碼：
4. 測試（分別測試支付寶和銀聯，則可以看到自定義的成功返回分別爲success和ok，後臺打印日誌也是遵循123步驟，注意，由於直接把支付寶和銀聯回調實現注入到spring容器，所以傳參的時候templateId一定要爲類名首字母小寫）
