設計模式之歡迎來到設計模式世界（一）

• 2019 年 12 月 25 日
• 筆記

親愛的朋友，歡迎你來到對象村，開始走進設計模式的世界。這裡的每個人都很熟練的使用設計模式，很快我和你們一起，都會學習的很好，通過設計模式，躋身上流社會。

計劃每一章節的學習，通過幾個篇幅來完成，理論+實踐的方式。書中很多地方用到了圖形表示，小編盡量用圖文的方式和大家互動。先用理論建立知識，再用圖形象地描述鞏固學習。每篇文章給出書中的思考題和大家互動，在後文給出答案。力爭讓沒讀過此書的朋友也能有個理解。小編第一次嘗試書本跟讀，希望大家多給意見，同大家一起進步。

記得大學的時候，C++的老師在教我們面向對象的是就是用的鴨子會飛、會叫的例子，沒想到《Head First 設計模式》里用的也是這個，沒看過太多的書，可能鴨子比較特殊吧。前幾個月，還出現各種鴨子的表情包，還有很出名的小黃鴨，讓我不禁讚歎，鴨子才是人類比較好的朋友呀。

那麼第一個問題來了，一家公司想要設計一款關於鴨子的遊戲，遊戲中會出現各種鴨子，一邊游泳戲水，一邊呱呱叫。遊戲的模型已經有了面向對象的思想，設計了一個鴨子的超類（Superclass），並讓各種鴨子繼承這個超類。現在想讓鴨子會飛，你會怎麼做呢？初始的鴨超類如下，隨着我們一步步學習，我們將這個超類一步步優化，敬請期待。

public class Duck {      public Duck() {        }        // 游泳      public void swim() {          System.out.println("I can swim");      }        // 呱呱叫      public void quack() {        }        // 顯示      public void display() {        }        // 飛行      public void fly() {        }  }  

我第一個冒出來的想法就是繼承，我也算是寫了幾年程序的老鳥了，沒想到也只能想到這麼low的想法，用繼承來解決問題。在繼承中加入fly()方法。好啦，現在所有的鴨子都會飛了，包括玩具鴨，天吶，這是什麼情況，難道你還要給玩具鴨裝發動機么。要知道，並不是所有的鴨子都會飛的呀。如果以後還有一隻木頭鴨，啥都不會，怎麼辦呢。或者說以後鴨子變異了，多了功能，也並不是所有的鴨子都需要有的功能呢。這就引出了繼承的弊端，給大家留的第一個思考題，繼承會有哪些缺點呢？期待在留言區看到你的答案（答案下期揭曉）。以下哪幾個是缺點：

• A 代碼在多個子類中重複
• B 運行時的行為不容易改變
• C 我們不能讓鴨子跳舞
• D 很難知道所有鴨子的全部行為
• E 鴨子不能同時又飛又叫
• F 改變會牽一髮動全身，造成其他鴨子不想要的改變

所以，我們還是不能用繼承來解決剛提出來的問題。有些鴨子會飛，有些鴨子會叫，有些啥都不會，鴨子行為太過於繁雜，不能一以貫之。這就引出了我們需要接觸到的設計原則「找到應用中可能需要變化之處，並把它們獨立出來，不要和那些不需要變化的代碼混在一起」這樣，代碼變化引起的不經意後果變少，系統變得更有彈性。在剛才的例子中，我們就把鴨子會飛以及會叫的屬性的分開，組建一個新類來表示。

第二個重點來了，如何設計那組實現飛行和呱呱叫的行為的類呢。那就把鴨子的行為放在分開的類中，此類專門提供某行為接口的實現，這樣鴨子類就不再需要知道行為的實現細節。鴨子的子類將實現接口，不會綁死在鴨子的子類中，做一些沒必要的事情。這就是我們需要說的第二個設計原則「針對接口編程，而不是實現編程」

我們利用接口代表每個行為，在這裡用FlyBehavior與QuackBehavior分別表示飛行行為和呱呱叫行為，並且行為的每個實現都將實現其中的一個接口。這樣的好處就是飛行和呱呱叫的動作可以被其他對象復用，復用的同時這些行為徹底和鴨子類無關。前文說到的，鴨子還想增加其他的行為，也可以通過此方式來進行，既不會影響到既有的行為類，也不會影響到使用到飛行行為的鴨子類。整合之前鴨子的行為，在實踐中就是把飛行和呱呱叫方法在之前的超類中刪除，通過接口來實現，進行分離。

飛行和呱呱叫接口如下：

// 飛行接口  public interface FlyBehavior {      public void fly();  }    // 呱呱叫接口  public interface QuackBehavior {      public void quack();  }  

相應的實現類如下：

// 飛行類  public class FlyWithWings implements FlyBehavior {        @Override      public void fly() {          // 實現鴨子的飛行          System.out.println("I'm flying!!!");      }    }    // 呱呱叫類  public class Quack implements QuackBehavior {        @Override      public void quack() {          // 實現鴨子的呱呱叫          System.out.println("Quack");      }    }  

如果鴨子要動態設定行為呢？什麼意思，就是說「模型鴨想飛，利用火箭動力飛」。在我們現有的設計中，難不倒我們。我們可以在鴨子子類中通過設定方法「setter method」的方式來設定鴨子的行為，而不用在構造器中實例化。構造器中模型鴨不會飛，通過設定鴨子的行為，把火箭動力行為設定好，相當於把鴨子加了一個bug，設定好之後再給鴨子去飛。

// 在超類中添加動態設置的行為  public void setFlyBehavior(FlyBehavior fb) {      flyBehavior = fb;  }    public void setQuackBehavior(QuackBehavior qb) {      quackBehavior = qb;  }    // 通過一個測試類進行測試反饋  public class MiniDuckSimulator {      public static void main(String[] args) {          Duck mallard = new MallardDuck();          // 這裡調用MallardDuck繼承來的performQuack()，進而委託給該對象的QuackBehavior對象處理，          // 也就是說，調用繼承來的QuackBehavior的quack(),performFly同理          mallard.performQuack();          mallard.performFly();            Duck model = new ModelDuck();          // 第一次調用，不會飛          model.performFly();          // 調用繼承來的setter方法，把火箭動力飛行的行為定到模型鴨中，模型鴨能一飛衝天          model.setFlyBehavior(new FlyRocketPowered());          // 這樣就成功的改變了行為          model.performFly();      }  }    // 運行結果，我們實現了火箭助力飛行  Quack  I'm flying!!!  I can't fly  I'm flying with a  rocket  

好了，現在我們有鴨子超類，鴨子類，飛行行為實現FlyBehavior接口，呱呱叫行為實現QuackBehavior接口。之前繼承的想法，就是IS-A（是一個）的關係，現在通過封裝行為，實現接口，變成了HAS-A（有一個）的關係，將兩個類結合起來，就成為了一個組合（composition）。區別顯而易見，鴨子的行為是通過對象的「組合」來的，而不是「繼承」而來。恭喜你，掌握了第三個設計原則「多用組合，少用繼承」。使用組合建立系統具有很大的彈性，只要組合的行為對象符合正確的接口標準，那就可以「在運行時動態的改變行為」。

簡單的學到這裡，其實已經在無形之中引出了一個設計模式「策略模式」，他定義了算法族，分別封裝起來，讓它們之間互相替換，此模式讓算法的變化獨立於使用算法的客戶。有了這個策略模式，系統不需要擔心遇到任何改變，通過上述的操作，就能靈活應對，神不神奇，意不意外，驚不驚喜。

現在對之前的理論做個簡單的總結：首先我們先用鴨子舉個例子，引出超類Duck，子類的概念；第二，因為鴨子需要各自有行為，呱呱叫，飛行行為，我們設計出接口QuackBehavior和FlyBehavior，實現類FlyWithWings（實現鴨子飛行）等其他行為和Quack（實現鴨子呱呱叫等其他叫聲）；第三，我們需要鴨子有火箭般的速度，繼而引出FlyRocketPowered的行為，方便鴨子動態設定。自此三個步驟，把今天的行為實現，得出了三個設計原則和一個設計模式。最終的Duck類如下

public abstract class Duck {      // 為行為接口類型聲明兩個引用變量，所有 鴨子類都繼承他們      FlyBehavior flyBehavior;      QuackBehavior quackBehavior;        public Duck() {        }        public void setFlyBehavior(FlyBehavior fb) {          flyBehavior = fb;      }        public void setQuackBehavior(QuackBehavior qb) {          quackBehavior = qb;      }        abstract void display();        public void performQuack() {          // 委託給呱呱叫行為類          quackBehavior.quack();      }        public void performFly() {          // 委託給飛行行為類          flyBehavior.fly();      }        public void swim() {          System.out.println("I can swim");      }  }  

代碼流程部分就到這裡，在學習的過程當中，還有很多類圖，很多思考以及總結等我去完善。這是第一篇，下面一篇會把這次的轉變通過圖文的方式做一個總結，小夥伴們先別急，學習是一個循序漸進的過程，小編會把代碼寫好，測試好，開源到GayHub上，同大家一起進步。

今天的內容就到這裡，歡迎各位拍磚！

為了讓小夥伴免去找資料的麻煩，公眾號回復設計模式，獲取最經典的兩本書籍《Head First設計模式》以及《大話設計模式》，一同開啟新篇章。

愛生活，愛學習，愛感悟，愛挨踢