當我們掌握了Java的語法，當我們瞭解了面向對象的封裝、繼承、多態等特性，當我們可以用Swing、Servlet、JSP技術構建桌面以及Web應用，不意味着我們可以寫出面向對象的程序，不意味着我們可以很好的實現代碼複用，彈性維護，不意味着我們可以實現在維護、擴展基礎上的代碼複用。一把刀，可以使你制敵於無形而於江湖揚名，也可以只是一把利刃而使你切菜平靜。Java，就是這把刀，它的威力取決於你使用的方式。當我們陷入無盡無止重複代碼的泥沼，當我們面臨牽一髮而動全身的維護惡夢, 你應該想起“設計模式”這個行動祕笈。面向對象的精義，看似平淡，其實要經過艱苦實踐才能成功。而構造OO系統的隱含經驗於是被前人蒐集而成並冠以“設計模式”之名。我們應該在編碼行動初始就攜帶以它。接下來，讓我們步“四人組”先行者之後，用中國文字、用實際案例領略模式於我們代碼煥然一新的改變：
設計模式解讀之一： 策略模式
1. 模式定義
把會變化的內容取出並封裝起來，以便以後可以輕易地改動或擴充部分，而不影響不需要變化
的其他部分；
2. 問題緣起
當涉及至代碼維護時，爲了複用目的而使用繼承，結局並不完美。對父類的修改，會影響到子類型
。在超類中增加的方法，會導致子類型有該方法，甚至連那些不該具備該方法的子類型也無法免除。示
例，一個鴨子類型：
public abstract class Duck {
//所有的鴨子均會叫以及游泳，所以父類中處理這部分代碼
public void quack() {
System.out.println("Quack");
}
public void swim() {
System.out.println("All ducks float, even decoys.");
}
//因爲每種鴨子的外觀是不同的，所以父類中該方法是抽象的，由子類型自己完成。
public abstract void display();
}
public class MallardDuck extends Duck {
//野鴨外觀顯示爲綠頭
public void display() {
System.out.println("Green head.");
}
}
public class RedHeadDuck extends Duck {
//紅頭鴨顯示爲紅頭
public void display() {
System.out.println("Red head.");
}
}
public class RubberDuck extends Duck {
//橡皮鴨叫聲爲吱吱叫，所以重寫父類以改寫行爲
public void quack() {
System.out.println("Squeak");
}
//橡皮鴨顯示爲黃頭
public void display() {
System.out.println("Yellow head.");
}
}
上述代碼，初始實現得非常好。現在我們如果給Duck.java中加入fly()方法的話，那麼在子類型中
均有了該方法，於是我們看到了 會飛的橡皮鴨子，你看過嗎？當然，我們可以在子類中通過空實現重
寫該方法以解決該方法對於子類型的影響。但是父類中再增加其它的方法呢？
通過繼承在父類中提供行爲，會導致以下缺點：
a. 代碼在多個子類中重複;
b. 運行時的行爲不容易改變；
c. 改變會牽一髮動全身，造成部分子類型不想要的改變；
好啦，還是剛纔鴨子的例子，你也許想到使用接口，將飛的行爲、叫的行爲定義爲接口，然後讓
Duck的各種子類型實現這些接口。這時侯代碼類似於：
public abstract class Duck {
//將變化的行爲 fly() 以及quake()從Duck類中分離出去定義形成接口，有需求的子類中自行
去實現
public void swim() {
System.out.println("All ducks float, even decoys.");
}
public abstract void display();
}
//變化的 fly() 行爲定義形成的接口
public interface FlyBehavior {
void fly();
}
//變化的 quack() 行爲定義形成的接口
public interface QuackBehavior {
void quack();
}
//野鴨子會飛以及叫，所以實現接口 FlyBehavior, QuackBehavior
public class MallardDuck extends Duck implements FlyBehavior, QuackBehavior{
public void display() {
System.out.println("Green head.");
}
public void fly() {
System.out.println("Fly.");
}
public void quack() {
System.out.println("Quack.");
}
}
//紅頭鴨子會飛以及叫，所以也實現接口 FlyBehavior, QuackBehavior
public class RedHeadDuck extends Duck implements FlyBehavior, QuackBehavior{
public void display() {
System.out.println("Red head.");
}
public void fly() {
System.out.println("Fly.");
}
public void quack() {
System.out.println("Quack.");
}
}
//橡皮鴨不會飛，但會吱吱叫，所以只實現接口QuackBehavior
public class RubberDuck extends Duck implements QuackBehavior{
//橡皮鴨叫聲爲吱吱叫
public void quack() {
System.out.println("Squeak");
}
//橡皮鴨顯示爲黃頭
public void display() {
System.out.println("Yellow head.");
}
}
上述代碼雖然解決了一部分問題，讓子類型可以有選擇地提供一些行爲(例如 fly() 方法將不會出
現在橡皮鴨中).但我們也看到，野鴨子MallardDuck.java和紅頭鴨子RedHeadDuck.java的一些相同行爲
代碼不能得到重複使用。很大程度上這是從一個火坑跳到另一個火坑。
在一段程序之後，讓我們從細節中跳出來，關注一些共性問題。不管使用什麼語言，構建什麼應用
，在軟件開發上，一直伴隨着的不變的真理是：需要一直在變化。不管當初軟件設計得多好，一段時間
之後，總是需要成長與改變，否則軟件就會死亡。
我們知道，繼承在某種程度上可以實現代碼重用，但是父類(例如鴨子類Duck)的行爲在子類型中是
不斷變化的，讓所有子類型都有這些行爲是不恰當的。我們可以將這些行爲定義爲接口，讓Duck的各種
子類型去實現，但接口不具有實現代碼，所以實現接口無法達到代碼複用。這意味着，當我們需要修改
某個行爲，必須往下追蹤並在每一個定義此行爲的類中修改它，一不小心，會造成新的錯誤。
設計原則：把應用中變化的地方獨立出來，不要和那些不需要變化的代碼混在一起。這樣代碼變化
引起的不經意後果變少，系統變得更有彈性。
按照上述設計原則，我們重新審視之前的Duck代碼。
1) 分開變化的內容和不變的內容
Duck類中的行爲 fly(), quack(), 每個子類型可能有自己特有的表現，這就是所謂的變化的內
容。
Duck類中的行爲 swim() 每個子類型的表現均相同，這就是所謂不變的內容。
我們將變化的內容從Duck()類中剝離出來單獨定義形成接口以及一系列的實現類型。將變化的
內容定義形成接口可實現變化內容和不變內容的剝離。其實現類型可實現變化內容的重用。這些實現類
並非Duck.java的子類型，而是專門的一組實現類，稱之爲"行爲類"。由行爲類而不是Duck.java的子類
型來實現接口。這樣，才能保證變化的行爲獨立於不變的內容。於是我們有：
變化的內容：
//變化的 fly() 行爲定義形成的接口
public interface FlyBehavior {
void fly();
}
//變化的 fly() 行爲的實現類之一
public class FlyWithWings implements FlyBehavior {
public void fly() {
System.out.println("I'm flying.");
}
}
//變化的 fly() 行爲的實現類之二
public class FlyNoWay implements FlyBehavior {
public void fly() {
System.out.println("I can't fly.");
}
}
-----------------------------------------------------------------
//變化的 quack() 行爲定義形成的接口
public interface QuackBehavior {
void quack();
}
//變化的 quack() 行爲實現類之一
public class Quack implements QuackBehavior {
public void quack() {
System.out.println("Quack");
}
}
//變化的 quack() 行爲實現類之二
public class Squeak implements QuackBehavior {
public void quack() {
System.out.println("Squeak.");
}
}
//變化的 quack() 行爲實現類之三
public class MuteQuack implements QuackBehavior {
public void quack() {
System.out.println("<< Slience >>");
}
}
通過以上設計，fly()行爲以及quack()行爲已經和Duck.java沒有什麼關係，可以充分得到複用
。而且我們很容易增加新的行爲, 既不影響現有的行爲，也不影響Duck.java。但是，大家可能有個疑
問，就是在面向對象中行爲不是體現爲方法嗎？爲什麼現在被定義形成類(例如Squeak.java)？在OO中
，類代表的"東西"一般是既有狀態(實例變量）又有方法。只是在本例中碰巧"東西"是個行爲。既使是
行爲，也有屬性及方法，例如飛行行爲，也需要一些屬性記錄飛行的狀態，如飛行高度、速度等。
2) 整合變化的內容和不變的內容
Duck.java將 fly()以及quack()的行爲委託給行爲類處理。
不變的內容：
public abstract class Duck {
//將行爲類聲明爲接口類型，降低對行爲實現類型的依賴
FlyBehavior flyBehavior;
QuackBehavior quackBehavior;
public void performFly() {
//不自行處理fly()行爲，而是委拖給引用flyBehavior所指向的行爲對象
flyBehavior.fly();
}
public void performQuack() {
quackBehavior.quack();
}
public void swim() {
System.out.println("All ducks float, even decoys.");
}
public abstract void display();
}
Duck.java不關心如何進行 fly()以及quack(), 這些細節交由具體的行爲類完成。
public class MallardDuck extends Duck{
public MallardDuck() {
flyBehavior=new FlyWithWings();
quackBehavior=new Quack();
}
public void display() {
System.out.println("Green head.");
}
}
測試類：
public class DuckTest {
public static void main(String[] args) {
Duck duck=new MallardDuck();
duck.performFly();
duck.performQuack();
}
}
在Duck.java子類型MallardDuck.java的構造方法中，直接實例化行爲類型，在編譯的時侯便指
定具體行爲類型。當然，我們可以：
1) 我們可以通過工廠模式或其它模式進一步解藕(可參考後續模式講解);
2) 或做到在運行時動態地改變行爲。
3) 動態設定行爲
在父類Duck.java中增加設定行爲類型的setter方法，接受行爲類型對象的參數傳入。爲了降藕
，行爲參數被聲明爲接口類型。這樣，既便在運行時，也可以通過調用這二個方法以改變行爲。
public abstract class Duck {
//在剛纔Duck.java中加入以下二個方法。
public void setFlyBehavior(FlyBehavior flyBehavior) {
this.flyBehavior=flyBehavior;
}
public void setQuackBehavior(QuackBehavior quackBehavior) {
this.quackBehavior=quackBehavior;
}
//其它方法同，省略...
}
測試類：
public class DuckTest {
public static void main(String[] args) {
Duck duck=new MallardDuck();
duck.performFly();
duck.performQuack();
duck.setFlyBehavior(new FlyNoWay());
duck.performFly();
}
}
如果，我們要加上火箭助力的飛行行爲，只需再新建FlyBehavior.java接口的實現類型。而子
類型可通過調用setQuackBehavior(...)方法動態改變。至此，在Duck.java增加新的行爲給我們代碼所
帶來的困繞已不復存在。
該是總結的時侯了，讓我們從代碼的水中浮出來，做一隻在水面上自由遊動的鴨子吧:
3. 解決方案
MallardDuck 繼承 Duck抽象類； -> 不變的內容
FlyWithWings 實現 FlyBehavior接口； -> 變化的內容,行爲或算法
在Duck.java提供setter方法以裝配關係； -> 動態設定行爲
以上就是策略模式的實現三步曲。接下來，讓我們透過步驟看本質:
1) 初始，我們通過繼承實現行爲的重用，導致了代碼的維護問題。 -> 繼承, is a
2) 接着，我們將行爲剝離成單獨的類型並聲明爲不變內容的實例變量並通過 -> 組合, has a
setter方法以裝配關係；
繼承，可以實現靜態代碼的複用；組合，可以實現代碼的彈性維護；使用組合代替繼承，可以
使代碼更好地適應軟件開發完後的需求變化。
策略模式的本質：少用繼承，多用組合