本文的概念內容來自深入淺出設計模式一書.
項目需求
有一家咖啡店, 供應咖啡和茶, 它們的工序如下:
咖啡:
茶:
可以看到咖啡和茶的制作工序是差不多的, 都是有4步, 其中有兩步它們兩個是一樣的, 另外兩步雖然具體內容不一樣, 但是都做做的同一類工作.
現在問題也有了, 當前的設計兩個類里面有很多重復的代碼, 那么應該怎樣設計以減少冗余呢?
初次嘗試
把共有的方法放到父類里面, 把不同的方法放到子類里面.
父類里面有一個抽象的prepareRecipe()方法[翻譯為准備烹飪方法/制作方法], 然后在不同的子類里面有不同的實現. 也就是說每個子類都有自己制作飲料的方法.
再仔細想想應該怎樣設計
可以發現兩個飲料的制作方法遵循了同樣的算法:
- 把水燒開
- 用開水沖咖啡或茶
- 把沖開的飲料放到杯里
- 添加適當的調料
現在我們來抽像prepareRecipe()方法:
1.先看看兩個飲料的差異:
兩種飲料都有四道工序, 兩個是完全一樣的, 另外兩個在具體的實現上是略有不同的, 但是還是同樣性質的工序.
這兩道不同的工序的本質就是沖飲料和添加調料, 所以prepareRecipe()可以這樣寫:
2. 把上面的方法放到超類里:
這個父類是抽象的, prepareRecipe()將會用來制作咖啡或者茶, 而且我不想讓子類去重寫這個方法, 因為制作工序(算法)是一定的.
只不過里面的第2部和第4部是需要子類自己來實現的. 所以brew()和addCondiments()是兩個抽象的方法, 而另外兩個方法則直接在父類里面實現了.
3. 最后茶和咖啡就是這個樣子的:
我們做了什么?
我們意識到兩種飲料的工序大體是一致的, 盡管某些工序需要不同的實現方法. 所以我們把這些飲料的制作方法歸納到了一個基類CaffeineBeverage里面.
CaffeineBeverage控制着整個工序, 第1, 3部由它自己完成, 第2, 4步則是由具體的飲料子類來完成.
初識模板方法模式
上面的需求種, prepareRecipe() 就是模板方法. 因為, 它首先是一個方法, 然后它還充當了算法模板的角色, 這個需求里, 算法就是制作飲料的整個工序.
所以說: 模板方法定義了一個算法的步驟, 並允許子類提供其中若干個步驟的具體實現.
捋一遍整個流程
1. 我需要做一個茶:
2. 然后調用茶的模板方法:
3. 在模板方法里面執行下列工序:
boildWater();
brew();
pourInCup();
addCondiments();
模板方法有什么好處?
不使用模板方法時:
- 咖啡和茶各自控制自己的算法.
- 飲料間的代碼重復.
- 改變算法需要修改多個地方
- 添加新飲料需要做很多工作.
- 算法分布在了不同的類里面
使用模板方法后:
- CaffeineBeverage這個父類控制並保護算法
- 父類最大化的代碼的復用
- 算法只在一個地方, 改變算法也只需改變這個地方
- 新的飲料只需實現部分工序即可
- 父類掌握着算法, 但是依靠子類去做具體的實現.
模板方法定義
模板方法在一個方法里定義了一套算法的骨架, 算法的某些步驟可以讓子類來實現. 模板方法讓子類重新定義算法的某些步驟而無需改變算法的結構.
類圖:
這個抽象類:
針對這個抽象類, 我們可以有一些擴展:
看這個hook方法, 它是一個具體的方法, 但是啥也沒做, 這種就叫做鈎子方法. 子類可以重寫該方法, 也可以不重寫.
模板方法里面的鈎子
所謂的鈎子, 它是一個在抽象類里面聲明的方法, 但是方法里面默認的實現是空的. 這也就給了子類"鈎進"算法某個點的能力, 當然子類也可以不這么做, 就看子類是否需要了.
看這個帶鈎子的飲料父類:
customerWantsCondiments()就是鈎子, 子類可以重寫它.
在prepareRecipe()方法里面, 通過這個鈎子方法的結果來決定是否添加調料.
下面是使用這個鈎子的咖啡:
C#代碼實現
不帶鈎子的父類:
using System; namespace TemplateMethodPattern.Abstractions { public abstract class CaffeineBeverage { public void PrepareRecipe() { BoilWater(); Brew(); PourInCup(); AddCondiments(); } protected void BoilWater() { Console.WriteLine("Boiling water"); } protected abstract void Brew(); protected void PourInCup() { Console.WriteLine("Pouring into cup"); } protected abstract void AddCondiments(); } }
咖啡和茶:
using System; using TemplateMethodPattern.Abstractions; namespace TemplateMethodPattern.Beverages { public class Coffee: CaffeineBeverage { protected override void Brew() { Console.WriteLine("Dripping Coffee through filter"); } protected override void AddCondiments() { Console.WriteLine("Adding Sugar and Milk"); } } } using System; using TemplateMethodPattern.Abstractions; namespace TemplateMethodPattern.Beverages { public class Tea: CaffeineBeverage { protected override void Brew() { Console.WriteLine("Steeping the tea"); } protected override void AddCondiments() { Console.WriteLine("Adding Lemon"); } } }
測試:
var tea = new Tea(); tea.PrepareRecipe();
帶鈎子的父類:
using System; namespace TemplateMethodPattern.Abstractions { public abstract class CaffeineBeverageWithHook { public void PrepareRecipe() { BoilWater(); Brew(); PourInCup(); if (CustomerWantsCondiments()) { AddCondiments(); } } protected abstract void Brew(); protected abstract void AddCondiments(); protected void BoilWater() { Console.WriteLine("Boiling water"); } protected void PourInCup() { Console.WriteLine("Pouring into cup"); } public virtual bool CustomerWantsCondiments() { return true; } } }
咖啡:
using System; using TemplateMethodPattern.Abstractions; namespace TemplateMethodPattern.Beverages { public class CoffeeWithHook: CaffeineBeverageWithHook { protected override void Brew() { Console.WriteLine("Dripping Coffee through filter"); } protected override void AddCondiments() { Console.WriteLine("Adding Sugar and Milk"); } public override bool CustomerWantsCondiments() { var answer = GetUserInput(); if (answer == "yes") { return true; } return false; } private string GetUserInput() { Console.WriteLine("Would you like milk and sugar with you coffee (y/n) ?"); var keyInfo = Console.ReadKey(); return keyInfo.KeyChar == 'y' ? "yes" : "no"; } } }
測試:
static void MakeCoffeeWithHook() { var coffeeWithHook = new CoffeeWithHook(); Console.WriteLine("Making coffee..."); coffeeWithHook.PrepareRecipe(); }
鈎子和抽象方法的區別?
抽象方法是算法里面必須要實現的一個方法或步驟, 而鈎子是可選實現的.
好萊塢設計原則
好萊塢設計原則就是: 別給我們打電話, 我們會給你打電話.
好萊塢原則可以防止依賴關系腐爛. 依賴關系腐爛是指高級別的組件依賴於低級別的組件, 它又依賴於高級別組件, 它又依賴於橫向組件, 又依賴於低級別組件....以此類推. 當腐爛發生的時候, 沒人會看懂你的系統是怎么設計的.
而使用好萊塢原則, 我們可以讓低級別組件鈎進一個系統, 但是高級別組件決定何時並且以哪種方式它們才會被需要. 換句話說就是, 高級別組件對低級別組件說: "別給我們打電話, 我們給你們打電話".
好萊塢原則和模板方法模式
模板方法里, 父類控制算法, 並在需要的時候調用子類的方法.
而子類從來不會直接主動調用父類的方法.
其他問題
好萊塢原則和依賴反轉原則DIP的的區別?
DIP告訴我們不要使用具體的類, 盡量使用抽象類. 而好萊塢原則則是讓低級別組件可以被鈎進算法中去, 也沒有建立低級別組件和高級別組件間的依賴關系.
三種模式比較:
模板方法模式: 子類決定如何實現算法中特定的步驟
策略模式: 封裝變化的行為並使用委托來決定哪個行為被使用.
工廠方法模式: 子類決定實例化哪個具體的類.
使用模板方法做排序
看看java里面數組的排序方法:
mergeSort就可以看做事模板方法, compareTo()就是需要具體實現的方法.
但是這個並沒有使用子類, 但是根據實際情況, 還是可以靈活使用的, 你需要做的就是實現Comparable接口即可., 這個接口里面只有一個CompareTo()方法.
具體使用C#就是這樣:
鴨子:
using System; namespace TemplateMethodPattern.ForArraySort { public class Duck : IComparable { private readonly string _name; private readonly int _weight; public Duck(string name, int weight) { _name = name; _weight = weight; } public override string ToString() { return $"{_name} weights {_weight}"; } public int CompareTo(object obj) { if (obj is Duck otherDuck) { if (_weight < otherDuck._weight) { return -1; } if (_weight == otherDuck._weight) { return 0; } } return 1; } } }
比較鴨子:
static void SortDuck() { var ducks = new Duck[] { new Duck("Duffy", 8), new Duck("Dewey", 2), new Duck("Howard", 7), new Duck("Louie", 2), new Duck("Donal", 10), new Duck("Huey", 3) }; Console.WriteLine("Before sorting:"); DisplayDucks(ducks); Array.Sort(ducks); Console.WriteLine(); Console.WriteLine("After sorting:"); DisplayDucks(ducks); } private static void DisplayDucks(Duck[] ducks) { foreach (Duck t in ducks) { Console.WriteLine(t); } }
效果:
其他鈎子例子
java的JFrame:
JFrame父類里面有一個update()方法, 它控制着算法, 我們可以使用paint()方法來鈎進到該算法的那部分.
父類里面JFrame的paint()啥也沒做, 就是個鈎子, 我們可以在子類里面重寫paint(), 上面例子的效果就是:
另一個例子Applet小程序:
這5個方法全是重寫的鈎子...
我沒看過winform或者wpf/sl的源碼, 我估計也應該有一些鈎子吧.
總結
好萊塢原則: "別給我們打電話, 我們給你打電話"
模板方法模式: 模板方法在一個方法里定義了一套算法的骨架, 算法的某些步驟可以讓子類來實現. 模板方法讓子類重新定義算法的某些步驟而無需改變算法的結構
該系列的源碼: https://github.com/solenovex/Head-First-Design-Patterns-in-CSharp