介紹和實現：
策略模式的結構其實非常簡單，比模板方法模式簡單多了，它實質上就是乙個原則的體現，往低裡說就是裡式替換原則，往高裡說是依賴倒置原則，具體實現過程是這樣：有乙個介面a中有乙個抽象演算法方法a
有一組介面a的實現類a-? 用不同具體演算法實現了抽象演算法方法a
在客戶端裡先持有乙個演算法介面的引用，在要呼叫某個演算法方法時，你就給這個引用賦實現類的值，然後通過這個引用呼叫相應演算法方法就可以了
而模板方法模式有乙個抽象類a中有兩個方法（暫時忽略鉤子方法），抽象演算法方法a-abstruct，模板業務方法a-mode（模板方法中使用到了抽象演算法方法，所以其實這個模板方法現在還不能正常工作）
在客戶端裡要使用這個類時，繼承抽象類，並實現抽象演算法方法，然後例項化使用
共同點：
目的是一樣的，讓不同演算法實現的業務復用**
區別：形式看起來就是【策略模式】把【模板方法模式】中的模板方法獨立到另乙個類中，然後在使用的時候，再跟實現了的算法子類拼接到一起。（使用的時候拼接，使用者能知道自己在使用什麼模式）
【模板方法模式】在使用的時候，不用拼接，因為在繼承的時候已經是分開繼承的，兩個方法本來就在一起，你要用哪組就直接呼叫哪組就行了。（用的時候直接呼叫完整方法，使用者不知道是什麼模式實現的）
乙個混淆：
有時候策略模式中，實現類a-？中用不同具體演算法實現的抽象演算法方法a中可能有很多重複**，這個時候為了復用，就把這些重複**剝離出去，用的時候再呼叫，那剝離到哪兒呢，就剝離到介面a中，那這個時候介面a就必須是抽象類a了，在這個時候你會發現，策略模式的抽象類a中也有兩個方法，也是乙個抽象演算法方法和另乙個具體方法，看著是不是有點像模板方法模式，但其實完全不同：這裡的具體方法並不是模板方法，而是另乙個工具方法
另外還是有乙個業務類b和業務方法b，這個b才是意義上的模板方法
表面上看策略模式複雜，其實不然，策略模式就是最最簡單的面向介面程式設計的乙個例子，最最簡單的多型的乙個體現，從這個角度看，其實是非常簡單的
優缺點或者說兩個方法的適應場景：
看了很多，發現很多偏頗或者說一團漿糊的理解，即使是已經工作的程式設計師，所以我特地辯駁一下大部分人傾向於兩者差不多，懶得吐槽了
還有人甚至對兩種模式的界定都分不清，用不要拘泥於模式來搪塞，然後最後說創新了一種介於兩者之間的模式，其實就是這兩種中的一種，比較多的其實是使用了抽象類代替介面的策略模式
然後還有人認為兩者最大的區別是外界對方法修改的訪問許可權的區別，這個不能說沒有，但是這個點幾無價值
個人體會模板方法適合小專案，因為它的形式最簡單，用起來方便，但是它對演算法的復用比較不靈活，而且大量的繼承會產生大量冗餘**，也加重了系統負擔
策略模式適合大專案，它形式雖然複雜一些，但是管理規範，對演算法的復用也可以非常靈活（尤其是在使用抽象類代替介面時），甚至可以用多重演算法巢狀來進一步減少冗餘**，而且由採用類的組合，冗餘**也能減少很多
模板方法模式 策略模式區別聯絡
模板方法模式 定義 一系列演算法，子類延伸實現。著重點在於 子類去處理不同的方法實現。看下面例子。假如乙個支付 都包含三個部分 生成訂單 呼叫api發起支付 處理訂單 購物流程 模板方法基類 authorliangxing.zhu create 2018 9 15 since1.0.0 public...
模板模式同策略模式區別
模板方法 同 strategry pattern 區別 模板方法 定義乙個演算法的大綱，而由其子類定義其中某些步驟的內容。而其演算法的個別步驟可以有不同的實現細節。演算法結構依然維持不變。用繼承的方式改變演算法中的具體步驟，依賴程度高，演算法在父類 父類是抽象類 中實現，演算法的具體步驟在子類中實現...
模板模式同策略模式區別
模板方法 同 strategry pattern 區別 模板方法 定義乙個演算法的大綱，而由其子類定義其中某些步驟的內容。而其演算法的個別步驟可以有不同的實現細節。演算法結構依然維持不變。用繼承的方式改變演算法中的具體步驟，依賴程度高，演算法在父類 父類是抽象類 中實現，演算法的具體步驟在子類中實現...