策略模式(Strategy Pattern)
定義了算法族，分別封裝起來，讓它們之間可以互相替換，此模式讓算法的變化獨立於使用算法的客戶。
可怕的問題
對代碼所做的局部修改，影響層面可不是局部（會飛的橡皮鴨）
怎麼辦？
採用良好的OO軟件設計原則。
設計原則(第一個設計原則)
找出應用中可能需要變化之處，把他們獨立出來，不要和那些不需要變化的代碼混在一起。
換句話說，如果每次新的需求一來，都會使某方面的代碼發生變化，那麼可以確定這部分代碼需要抽取出來。——代碼變化引起的不經意後果變少，系統變得更有彈性。
設計原則
針對接口編程，而不是針對實現編程
針對實現編程：
// 聲明變量d爲Dog類型（是Animal的具體實現），會造成我們必須針對具體實現編碼
Dog d = new Dog();
d.bark();
針對接口/超類編程：
// 知道對象時狗，但是利用animal進行多態的調用
Animal animal = new Dog()
Animal.makeSound();
更棒的是，子類實例化的動作不再需要在代碼中硬編碼，例如：new Dog()，而是“在運行時才指定具體實現的對象”。
// 我們不知道實際的子類型是“什麼”….我們只關心它如何正確地進行makeSound()的動作就可以了。
a = getAnimal();
a.makeSound();
設計原則
多用組合，少用繼承。
設計模式讓你和其他開發人員之間有共享的詞彙，一旦懂得這些詞彙，和其他開發人員之間溝通就很容易，也會促使哪些不懂的程序員想開始學習設計模式。設計模式也可以把你的思考架構的層次提高到模式層面，而不是僅停留在瑣碎的對象上。
設計模式不會直接進入你的代碼中，而是先進入進的“大腦”中，一旦你現在腦海中裝入許多關於模式的知識，就能夠開始在新設計中採用它們，並當你的舊代碼變得如同攪和一團沒有彈性的時候，可以用他們重構代碼。
知道抽象、繼承、多態這些概念，並不會馬上變成好的面向對象設計者。設計大師關心的是建立彈性的設計，可以維護，可以應付變化。
