策略模式:
定義了算法族，分別封裝起來，讓他們之間可以互相替換，此模式讓算法的變化獨立於使用算法的客戶。
設計原則:
找出應用中可能需要變化之處，把它們獨立並"封裝"起來，不要和那些不變的代碼混在一起，以便以後可以輕易的改動或擴充此內容，而不影響不需要變化的其他部分。這樣做的好處是代碼變化引起的不經意後果變少，系統變得更有彈性。
針對接口編程Animmal dog = new Dog()，而不是針對實現編程Dog dog = new Dog()。
多用組合，少用繼承。這就是"有一個"比"是一個"更好的地方。
用例:
比如要想寫一個關於Duck的應用，裏面涉及到各種各樣的Duck，它們有共同的特徵（如：有腳、有翅膀。。。），同時也有不同的特徵（如：叫聲不同、飛行能力不同。。。），那麼該如何涉及呢？
思路：
首先創建一個Duck的超類，將相同的屬性（有腳、有翅膀）都封裝到這個超類，這一點是可以肯定的。但是我們如何處理不同的特徵呢？我想到了一下幾種思路：
1. 直接在Duck中實現兩個方法quack（）和fly（），但是這樣做就不能起到區分的作用了，所有的子類都會相同；
2. 在Duck類中創建一個抽象的方法，然後讓所有的子類都去實現這個方法，這樣做看似可以達到效果，但是如果duck的種類特別多呢？那樣每個子類都要去分別實現這個方 法，如果其中還有很多方法是相同的，那樣就會讓代碼顯示得臃腫，不方便維護，所以還是捨棄這種；
3. 創建一個FlyBehavier接口，然後再根據動作的不同分別去實現這個接口。然後在Duck超類中引用FlyBehavier的代理對象，在Duck的fly（）方法中去調用 flyBehavier.fly（），然後再提供一個 setFlyBehavier（）的方法去動態的設置FlyBehavier 的實例。這樣做的好處是我們只需要在Duck中去調用這個接口，而不需要去管它的具體實現，並且還實現了這些不同的部分與相同的部分的一個分離。
具體的實現UML：
