一、借鑒說明 1.《Head First Design Patterns》（中文名《深入淺出設計模式》） 2.維基百科，策略模式，https://zh.wikipedia.org/wiki/%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F 二、策略模式 基礎知識 將一類相同的... ...
一、借鑒說明
1.《Head First Design Patterns》（中文名《深入淺出設計模式》）
2.維基百科，策略模式，https://zh.wikipedia.org/wiki/%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F
二、策略模式
- 基礎知識
將一類相同的演算法封裝起來，形成演算法族，只提供相同的介面給外界，同一演算法族內的演算法可以互相替換，外界使用時，沒有感覺什麼不同，即演算法族內的演算法獨立於使用者存在。
- 具體例子
學生Student和老師Teacher去學校School的方式有很多種：坐公交Bus，坐地鐵Subway，坐車Car等等。
因此就有了第一種情況：Student有goToSchoolByBus、goToSchoolBySubway、goToSchoolByCar函數，Teacher也有goToSchoolByBus、goToSchoolBySubway、goToSchoolByCar函數，UML如圖所示。但是這樣太過冗餘，這裡的冗餘具體是指："搭乘交通工具的方式"是可以共用的部分，不管是Student還是Teacher都是可以坐Bus、Subway、Car的。還有就是不靈活，如果以後突然有別的需求的話，例如走路Walk去學校的話，那麼Student和Teacher就要分別修改了，費時費力，還有可能帶來副作用（如出現意想不到的bug），因此，需要把可能變化的部分提取出來，將這部分做成演算法族。
因此，改進上述情況：Student、Teacher都有goToSchool函數，並持有一個IWay介面的引用，而將Bus、Subway、Car等相關的演算法封裝在IWay這一演算法族裡。這樣，方便統一管理，方便外界的統一調用，而且需要新增演算法的時候，只需要修改Way，並不影響原先的Student、Teacher。而且，也方便復用，假設有這樣的一種情況，studentA有眼疾，需要導盲犬dogA的幫助才能goToSchool，這時，Dog也擁有了goToSchool這一函數，也持有了一個IWay介面的引用。UML如圖所示：
- 什麼時候可以考慮使用策略模式
代碼里有會變化的部分，且該部分可以被提取出來（儘量使用"面向介面"，這樣有利於解耦）
- 具體的C#實現
設計模式（C#）的相關代碼我都放在git上：https://github.com/MGKING3/DesignPatternsUseCSharp
我使用的是VS2015，是整一個項目，下載即可以用，不時更新。
- 相關OO原則
1.封裝原則
2.多用組合（has-a），少用繼承（is-a）
3.儘量"面向介面"
