策略模式
問題的描述：
需求：開發一個鴨子游戲，能游泳，有外觀，實現類圖如下：
增加的需求：
1. 加入飛行功能
2. 加入呱呱叫的功能。。。等等，暫時的解決方式如下：
上線後出現了些問題：
1. 所有的鴨子都能叫嗎？木頭鴨子呢？
2. 所有的鴨子都能飛嗎？木頭鴨子呢？橡皮鴨子呢？
總結下，使用繼承的缺點：
代碼在多個子類中重複
運行時的行爲不容易改變
很難知道鴨子的全部行爲
改變會牽一髮動全身，造成其他鴨子不想要的改變
。。。
好吧，我們引入接口來進一步修改，類圖如下：
問題已經解決了，但是鴨子子類有40多種，我們修改fly方法，難道修改40種樣本？以後的維護的坑有點大哦！
總結下，這種方式的缺點：
代碼在多個子類中重複
維護成本提高（有40個子鴨子類，要修改fly方法需要改40次？）
。。。
問題不斷，我們用設模式來解決這個問題，先看看定義：策略模式：定義算法族，分別封裝起來，它們之間可以互相替換，此模式讓算法的變化獨立於使用算法的客戶。
好，我們修改下，類圖如下：
我們用這個模式解決了：
1. 鴨子行爲的各種各樣性（子類行爲和超類沒有直接的關係了，添加刪除行爲不影響繼承體系）
2. 代碼重用，維護問題（子類太多時修改行爲特別麻煩，代碼重複，只修改算算法組就搞定）
3. 動態修改行爲（Setter和Getter方法來靈活配置行爲）
4. 。。。
這章我們學到的設計原則：
設計原則1： 封裝變化（找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起）。
設計原則2： 針對接口編程，而不是針對實現類
設計原則3： 多用組合，少用繼承