【原創·教程·連載】《Android之大話設計模式》–設計模式 建立型模式 第一章：簡單原廠模式

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

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有些不滿的問道。“什麼規矩？當然不知道了啊。”，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和MM分別又加了幾份食品，有GG把訂單拿到前台交給了服務員，服務員清算了一下所有花費，GG當即暈倒^_^。看來一個月的生活費是確實的泡湯了，不過還是故作振作，微笑著來到眾美女中，和眾美女坐在那裡等著慢慢享用美食，而剩下的一切就交給服務員了…

簡單原廠模式解釋： 

       簡單原廠模式（Simple Factory Pattern）屬於類的創新型模式，又叫靜態Factory 方法模式（Static FactoryMethod Pattern）,是通過專門定義一個類來負責建立其他類的執行個體，被建立的執行個體通常都具有共同的父類。

簡單原廠模式的UML圖： 

       簡單原廠模式中包含的角色及其相應的職責如下：

       工廠角色（Creator）：這是簡單原廠模式的核心，由它負責建立所有的類的內部邏輯。當然工廠類必須能夠被外界調用，建立所需要的產品對象。

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

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

簡單原廠模式深入分析：

       簡單原廠模式解決的問題是如何去執行個體化一個合適的對象。

       簡單原廠模式的核心思想就是：有一個專門的類來負責建立執行個體的過程。

       具體來說，把產品看著是一系列的類的集合，這些類是由某個抽象類別或者介面派生出來的一個對象樹。而工廠類用來產生一個合適的對象來滿足客戶的要求。

       如果簡單原廠模式所涉及到的具體產品之間沒有共同的邏輯，那麼我們就可以使用介面來扮演抽象產品的角色；如果具體產品之間有功能的邏輯或，我們就必須把這些共同的東西提取出來，放在一個抽象類別中，然後讓具體產品繼承抽象類別。為實現更好複用的目的，共同的東西總是應該抽象出來的。

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

簡單原廠模式使用情境分析及代碼實現： 

       GG請自己的女朋友和眾多美女吃飯，但是GG自己是不會做飯的或者做的飯很不好，這說明GG不用自己去建立各種食物的對象；各個美女都有各自的愛好，到麥當勞後她們喜歡吃什麼直接去點就行了，麥當勞就是生產各種食物的工廠，這時候GG不用自己動手，也可以請這麼多美女吃飯，所要做的就是買單O(∩_∩)O哈哈~,其UML圖如下所示：

       實現代碼如下：

       建立立一個食物的介面：

package com.diermeng.designPattern.SimpleFactory;   /*  * 產品的抽象介面  */ public interface Food {     /*      * 獲得相應的食物      */     public void get(); }

接下來建立具體的產品：麥香雞和薯條

package com.diermeng.designPattern.SimpleFactory.impl; import com.diermeng.designPattern.SimpleFactory.Food;   /*  * 麥香雞對抽象產品介面的實現  */ public class McChicken implements Food{     /*      * 擷取一份麥香雞      */     public void get(){         System.out.println("我要一份麥香雞");     } }

package com.diermeng.designPattern.SimpleFactory.impl; import com.diermeng.designPattern.SimpleFactory.Food;   /*  * 薯條對抽象產品介面的實現  */ public class Chips implements Food{     /*      * 擷取一份薯條      */     public void get(){         System.out.println("我要一份薯條");     } }

現在建立一個食物加工工廠：

package com.diermeng.designPattern.SimpleFactory.impl; import com.diermeng.designPattern.SimpleFactory.Food;     public class FoodFactory {       public static Food getFood(String type) throws InstantiationException, IllegalAccessException, ClassNotFoundException {         if(type.equalsIgnoreCase("mcchicken")) {             return McChicken.class.newInstance();           } else if(type.equalsIgnoreCase("chips")) {             return Chips.class.newInstance();         } else {             System.out.println("哎呀！找不到相應的執行個體化類啦！");             return null;         }         } }

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

package com.diermeng.designPattern.SimpleFactory.client; import com.diermeng.designPattern.SimpleFactory.Food; import com.diermeng.designPattern.SimpleFactory.impl.FoodFactory;   /*  * 測試用戶端  */ public class SimpleFactoryTest {     public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {           //執行個體化各種食物         Food mcChicken = FoodFactory.getFood("McChicken");         Food chips = FoodFactory.getFood("Chips");         Food eggs = FoodFactory.getFood("Eggs");           //擷取食物         if(mcChicken!=null){             mcChicken.get();         }         if(chips!=null){             chips.get();         }         if(eggs!=null){             eggs.get();         }         } }

輸出的結果如下：

哎呀！找不到相應的執行個體化類啦！ 我要一份麥香雞 我要一份薯條

簡單原廠模式的優缺點分析： 

       優點：工廠類是整個模式的關鍵所在。它包含必要的判斷邏輯，能夠根據外界給定的資訊，決定究竟應該建立哪個具體類的對象。使用者在使用時可以直接根據工廠類去建立所需的執行個體，而無需瞭解這些對象是如何建立以及如何組織的。有利於整個軟體體繫結構的最佳化。

      缺點：由於工廠類集中了所有執行個體的建立邏輯，這就直接導致一旦這個工廠出了問題，所有的用戶端都會受到牽連；而且由於簡單原廠模式的產品室基於一個共同的抽象類別或者介面，這樣一來，但產品的種類增加的時候，即有不同的產品介面或者抽象類別的時候，工廠類就需要判斷何時建立何種種類的產品，這就和建立何種種類產品的產品相互混淆在了一起，違背了單一職責，導致系統喪失靈活性和可維護性。而且更重要的是，簡單原廠模式違背了“開放封閉原則”，就是違背了“系統對擴充開放，對修改關閉”的原則，因為當我新增加一個產品的時候必須修改工廠類，相應的工廠類就需要重新編譯一遍。

      總結一下：簡單原廠模式分離產品的建立者和消費者，有利於軟體系統結構的最佳化；但是由於一切邏輯都集中在一個工廠類中，導致了沒有很高的內聚性，同時也違背了“開放封閉原則”。另外，簡單原廠模式的方法一般都是靜態，而靜態Factory 方法是無法讓子類繼承的，因此，簡單原廠模式無法形成基於基類的繼承樹結構。

簡單原廠模式的實際應用簡介： 

       作為一個最基本和最簡單的設計模式，簡單原廠模式卻有很非常廣泛的應用，我們這裡以Java中的JDBC操作資料庫為例來說明。

        JDBC是SUN公司提供的一套資料庫編程介面API，它利用Java語言提供簡單、一致的方式來訪問各種關係型資料庫。Java程式通過JDBC可以執行SQL語句，對擷取的資料進行處理，並將變化了的資料存回資料庫，因此，JDBC是Java應用程式與各種關係資料進行對話的一種機制。用JDBC進行資料庫訪問時，要使用資料庫廠商提供的驅動程式介面與資料庫管理系統進行資料互動。

用戶端要使用使用資料時，只需要和工廠進行互動即可，這就導致操作步驟得到極大的簡化，操作步驟按照順序依次為：註冊並載入資料庫驅動，一般使用Class.forName();建立與資料庫的連結Connection對象；建立SQL語句對象preparedStatement(sql)；提交SQL語句，根據實際情況使用executeQuery()或者executeUpdate()；顯示相應的結果；關閉資料庫。

溫馨提示： 

       嚴格意義上講，簡單原廠模式並不算是一種設計模式，簡單原廠模式更像是一種編程習慣，而這被廣泛的應用。但是因為簡單原廠模式在“高內聚”方面的欠缺，同時更致命的是違背了嚴格意義上的“開放封閉原則”，或者說只對“開放封閉原則”提供某種程度上的支援，這就使得每次新增加一個產品的時候是非常麻煩的，因為每當增加一種新的產品的時候，工廠角色必須知道這個產品，同時必須知道如何建立這個產品，還要以一種對用戶端有好的方式提供給用戶端使用。簡而言之，就是每增加一個新的產品就必須修改工廠角色的原始碼。所以簡單原廠模式是不利於構建容易發生變化的系統的。而“需求總是在變化”，“世界上沒有一個軟體是不變的”。所以使用簡單原廠模式的時候必須謹慎考慮。

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