【原創·教程·連載】《Android之大話設計模式》–設計模式 建立型模式 第二章：Factory 方法法模式

<大話設計模式>本教程說明及著作權聲明

l 該文檔參考和使用了網路上的免費開放的圖片和內容，並以免費開放的方式發布,希望為移動互連網和智能手機時代貢獻綿薄之力！可以隨意轉載，但不得使用該文檔謀利。

l 如果對該文檔有任何疑問或者建議，請進入官方部落格

   http://www.cnblogs.com/guoshiandroid/留言或者直接與國士工作室聯絡（後附連絡方式），我們會謹慎參考您的建議並根據需要對本文檔進行修改，以造福更多開發人員！

l 《大話設計模式》的最新及完整內容會在國士工作室官方部落格定期更新，請訪問國士工作室部落格

http://www.cnblogs.com/guoshiandroid/擷取更多更新內容。

國士工作室是一支專註於Android平台企業級應用開發的技術團隊，致力於做中國最棒的Android應用程式開發機構，提供最棒的Android企業級應用開發培訓服務。

企業培訓和開發合作官方連絡方式：

     電話:18610086859

     Email:hiheartfirst@gmail.com

     QQ:1740415547

     QQ群：148325348

國士工作室 有你更美好！

 

  查看其他部分：本教程整體說明及章節索引

本文PDF下載連結

讓麥當勞的漢堡適合不同MM的不同口味

Factory 方法模式應用情境舉例： 

       “你知不知道大學的規矩啊？”，MM有些不滿的問道。“什麼規矩？當然不知道了啊。”，GG傻傻的說道，很明顯這個MM已經對GG的不懂事和不主動有些不滿了。“在大學裡，當兩個人確定戀愛關係時，都是要請女朋友同寢室的人去吃飯的”，MM帶著一些不滿又有一些撒嬌的口氣說道。“啊？我不知道哎，請眾美女吃飯我還求之不得呢，什麼時候有時間啊，確定是時間和地點，我隨叫隨到！”GG很激動很爽快的答應道。MM笑著抬頭看了一樣這個傻GG,“那好，讓我想想，我們…我們下周六下午有時間，要麼這樣，你帶我們去麥當勞吧”，“一言為定”，“那我們在下周六下午五點在中心商業街南邊的麥當勞分店見，聽說那邊的口味還不錯:-O”，“好的，只要你開心就好，不見不散”GG回答道，“不見不散！”MM就這樣嫣然一笑的歡天喜地的離開了。

       想想前幾天GG和MM因為非常偶然的因素相見的情景，GG再次湧起了一種無法言喻的幸福和激動。那一天，GG見到了MM，仿若晴天霹靂，整個地球在顫抖，她甜美而柔和的聲音、她極具古典氣息的是秀髮、她超棒的身材、她恰到好處的著裝、她極盡秀美而恬靜的嬌容、她似音樂般的舉止頓時令他徹底的迷醉了，彷彿整個世界只有她一人，彷彿一切都是為她而生的，突然，兩人目光交錯，眼神相遇…就這麼一見鐘情！GG想，到麥當勞也好，反正我不會做飯，再說了，即使會做也不能去做啊，眾口難調啊，更何況是一群美女，到麥當勞讓她們自個兒去挑吧^_^不過我這一個月的生活費怕是要泡湯了，難怪別人說大學裡最高的消費是花費的女朋友身上的消費~~~~(>_<)~~~~

       千呼萬喚，終於到了周六下午。被感情沖昏大腦的GG突然間變的不再那麼笨了，這次他提前預定了座位，是一個可以容納8個人的座位。而且具體告訴了MM座位的位置，這樣大家都清楚位置是比較好的，避免了到時候沒有位置的尷尬。趕往麥當勞路上的GG心潮澎湃但是有些擔心，畢竟要面對六個美女，而且女朋友也是剛認識幾天。“親愛的，現在到哪了？”手機中MM發過來了一條簡訊，GG一看時間，天啊，光顧著去傻想，還有幾分鐘就五點了，第一次如果都遲到那就太不好了，於是立即回複到，“寶貝兒，我就到了！”，因為麥當勞就在對面，抬頭就可以看到的。GG跑上了麥當勞的二樓的用餐處，見到諸位美女，緊張的還沒說不話來，“這是我男朋友”MM拽著GG的手臂說，“大家好，大家好”，GG緊張的說道。忙又補充到：“我們先點餐，大家自便，都不要客氣啊”，“我要吃雞翅”，“我要麥香魚套餐”，我要“板燒雞腿套餐”，我要“奶昔”，我要“薯條”，“我要漢堡”，“我也要漢堡”，“我和她們一眼都要要漢堡”，無語啊，GG當然不可能知道每個人的口味，無奈之下，只好把這三個美女帶到服務台前，和服務員說，除了要訂單上的東西外，在要三個漢堡，至於是什麼味道的漢堡，就直接讓這三個美女自己和服務員交流了

Factory 方法法模式模式解釋： 

         Factory 方法模式（Factory Method Pattern）同樣屬於類的建立型模式又被稱為多態原廠模式(Polymorphic) 。Factory 方法模式的意義是定義一個建立產品對象的工廠介面，將實際建立工作延遲到子類當中。核心工廠類不再負責產品的建立，這樣核心類成為一個抽象工廠角色，僅負責具體工廠子類必須實現的介面，這樣進一步抽象化的好處是使得Factory 方法模式可以使系統在不修改具體工廠角色的情況下引進新的產品。

              英文定義為：Define an interface for creating an object, but let subclassesdecide which class to instantiate. Factory Method lets a class deferinstantiation to subclasses.

Factory 方法模式的UML圖： 

       Factory 方法模式中包含的角色及其相應的職責如下：

       抽象工廠（Creator）角色：Factory 方法模式的核心，任何工廠類都必須實現這個介面。

       具體工廠（ Concrete  Creator）角色: 具體工廠類是抽象工廠的一個實現，負責執行個體化產品對象。

       抽象（Product）產品角色：簡單原廠模式所建立的所有對象的父類，注意，這裡的父類可以是介面也可以是抽象類別，它負責描述所有執行個體所共有的公用介面。

       具體產品（Concrete Product）角色：簡單工廠所建立的具體執行個體對象，這些具體的產品往往都擁有共同的父類。

Factory 方法法模式深入分析：

       簡單原廠模式使用一個類負責所有產品的建立，雖然使得客服端和服務端相互分離，使得客服端不用關心產品的具體建立過程，用戶端唯一所要做的就是調用簡單工廠的靜態方法獲得想要的產品即可。但是，簡單原廠模式違背了嚴格意義上的“開放封閉原則”，這就使得一旦有一個新的產品增加就必須修改工廠類的原始碼，從而將新的產品的建立邏輯加入簡單工廠中供用戶端調用。Factory 方法法模式正是在簡單原廠模式的基礎上進一步抽象而來的。由於Factory 方法法模式的核心是抽象工廠角色，使用了物件導向的多態性，這就使得Factory 方法法模式即保持了簡單原廠模式的優點，又克服了簡單原廠模式違背“開放封閉原則”的缺點。

       Factory 方法法模式中核心工廠類不再提供所有的產品的建立工作，而是將具體的產品建立工作交給了子類去做。這時候的核心工廠類做什麼呢？做標準！核心工廠類只需要負責制定具體工廠需要實現的介面即可，至於具體的工作就留給了子類去建立了。

       在實際的的使用中，抽閑產品和具體產品之間往往是多層次的產品結構，如所示：

Factory 方法模式使用情境分析及代碼實現： 

       不同的美女同時要吃漢堡，但是不同的美女的有不同的口味，這是GG是不知道每個要吃漢堡美女的口味的，而且也沒有必要知道，如果真的知道了，自己的女朋友肯定會很不高興的~~~~(>_<)~~~~ 。這時候GG只需要帶著這些美女到服務台那裡，讓這些美女直接和服務人員講自己具體需要什麼口味漢堡就OK了。但是，不管這些妹妹需要的具體是什麼漢堡，結果一定還是一個漢堡。

       UML模型圖如下所示：

具體實現代碼如下：

       建立立一個食物的介面：

package com.diermeng.designPattern.FatoryMethod; /*  * 食物的抽象介面  */ public interface Food {     /*      * 擷取相應的食物      */     public void get(); }

建立一個食物工廠的介面：

package com.diermeng.designPattern.FatoryMethod; /*  * 食物的生產工廠的抽象介面  */ public interface FoodFactory {        /*         * 生產工廠生產出相應的食物         */        public Food getFood(); }

接下來建立具體的產品：牛肉漢堡和雞肉漢堡

package com.diermeng.designPattern.FatoryMethod.impl; import com.diermeng.designPattern.FatoryMethod.Food;   /*  * 牛肉漢堡  */ public class BeefBurger implements Food{     /*      * 擷取牛肉漢堡      */     public void get(){         System.out.println("獲得一份牛肉漢堡");     } }

package com.diermeng.designPattern.FatoryMethod.impl; import com.diermeng.designPattern.FatoryMethod.Food;   /*  * 雞肉漢堡  */ public class ChickenBurger implements Food{     /*      * 擷取雞肉漢堡      */     public void get(){         System.out.println("擷取一份雞肉漢堡");     } }

建立一個牛肉漢堡工廠：

package com.diermeng.designPattern.FatoryMethod.impl; import com.diermeng.designPattern.FatoryMethod.Food; import com.diermeng.designPattern.FatoryMethod.FoodFactory;   /*  *牛肉漢堡工廠  */ public class BeefBurgerFactory implements FoodFactory {     /*      * 生產出一份牛肉漢堡      * @see com.diermeng.designPattern.FatoryMethod.FoodFactory#getFood()      */     public Food getFood() {         return new BeefBurger();     }   }

       建立一個雞肉漢堡工廠：

package com.diermeng.designPattern.FatoryMethod.impl; import com.diermeng.designPattern.FatoryMethod.Food; import com.diermeng.designPattern.FatoryMethod.FoodFactory;   /*  * 肌肉漢堡工廠  */ public class ChickenBurgerFactory implements FoodFactory {     /*      * 生產出一份肌肉漢堡      * @see com.diermeng.designPattern.FatoryMethod.FoodFactory#getFood()      */     public Food getFood() {         return new ChickenBurger();     }   }

最後我們建立測試用戶端：

package com.diermeng.designPattern.FatoryMethod.client; import com.diermeng.designPattern.FatoryMethod.Food; import com.diermeng.designPattern.FatoryMethod.FoodFactory; import com.diermeng.designPattern.FatoryMethod.impl.BeefBurgerFactory; import com.diermeng.designPattern.FatoryMethod.impl.ChickenBurgerFactory;     /*  * 測試用戶端  */ public class FactoryMethodTest {     public static void main(String[] args) {         //獲得ChickenBurgerFactory         FoodFactory chickenBurgerFactory = new ChickenBurgerFactory();           //通過ChickenBurgerFactory來獲得ChickenBurger執行個體對象         Food ChickenBurger = chickenBurgerFactory.getFood();         ChickenBurger.get();             //獲得BeefBurgerFactory         FoodFactory beefBurgerFactory = new BeefBurgerFactory();           //通過BeefBurgerFactory來獲得BeefBurger執行個體對象         Food beefBurger = beefBurgerFactory.getFood();         beefBurger.get();       } }

輸出的結果如下：

擷取一份雞肉漢堡 獲得一份牛肉漢堡

Factory 方法模式的優缺點分析： 

       優點：Factory 方法類的核心是一個抽象工廠類，所有具體的工廠類都必須實現這個介面。當系統擴充需要添加新的產品對象時，僅僅需要添加一個具體對象以及一個具體工廠對象，原有工廠對象不需要進行任何修改，也不需要修改用戶端，這就很好的符合了“開放－封閉”原則。

      缺點：使用Factory 方法模式的時候，用戶端需要決定執行個體化哪一個具體的工廠。也就是說Factory 方法法模式把簡單原廠模式的內部判斷邏輯轉移到了用戶端代碼。而且使用該模式需要增加額外的代碼，這就導致工作量的增加。

Factory 方法模式的實際應用簡介： 

Factory 方法模式解決的是同一系列的產品的建立問題，而且很好的滿足了“開放封閉原則”，這需要建立同一系列產品的時候，使用Factory 方法模式往往比使用簡單原廠模式更好，尤其是對大型複雜的系統而言。

溫馨提示： 

       Factory 方法法模式解決了簡單原廠模式的不足。在增加一個產品時，只需要一個具體的產品和建立產品的工廠類就可以，具有非常好的可維護性。但是也正因為如此，增加了代碼量和工作量。不過瑕不掩瑜，因為增加的代碼量不是很大的。

注意：該文檔參考和使用了網路上的免費開放的圖片和內容，並以免費開放的方式發布,希望為移動互連網和智能手機時代貢獻綿薄之力！可以隨意轉載，但不得使用該文檔謀利。