設計模式之歡迎來到設計模式世界（一）
親愛的朋友，歡迎你來到物件村，開始走進設計模式的世界。這裡的每個人都很熟練的使用設計模式，很快我和你們一起，都會學習的很好，通過設計模式，躋身上流社會。
計劃每一章節的學習，通過幾個篇幅來完成，理論+實踐的方式。書中很多地方用到了圖形表示，小編儘量用圖文的方式和大家互動。先用理論建立知識，再用圖形象地描述鞏固學習。每篇文章給出書中的思考題和大家互動，在後文給出答案。力爭讓沒讀過此書的朋友也能有個理解。小編第一次嘗試書本跟讀，希望大家多給意見，同大家一起進步。
記得大學的時候，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 arocket
好了，現在我們有鴨子超類，鴨子類，飛行行為實現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設計模式》以及《大話設計模式》，一同開啟新篇章。