《Android之大話設計模式》--設計模式 建立型模式 第一章：簡單工廠模式

《Android之大話設計模式》--設計模式 建立型模式 第一章：簡單工廠模式

簡單工廠模式 ⼀見鍾情的代價 
簡單工廠模式應用場景舉例： 
       「你知不知道大學的規矩啊？」，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）屬於類的創新型模式，又叫靜態工廠方法模
式（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();
        }
 
 
    }
}
輸出的結果以下：
哎呀！找不到相應的實例化類啦！
我要⼀份麥香雞
我要⼀份薯條
簡單工廠模式的優缺點分析： 
       優勢：工廠類是整個模式的關鍵所在。它包含必要的判斷邏輯，可以根據外界給定的信息，決
定究竟應該建立哪一個具體類的對象。用戶在使用時能夠直接根據工廠類去建立所需的實例，而無
需瞭解這些對象是如何建立以及如何組織的。有利於整個軟件體系結構的優化。
      缺點：因爲工廠類集中了全部實例的建立邏輯，這就直接致使⼀旦這個工廠出了問題，全部的
客戶端都會受到牽連；並且因爲簡單工廠模式的產品室基於⼀個共同的抽象類或者接口，這樣
⼀來，但產品的種類增長的時候，即有不一樣的產品接口或者抽象類的時候，工廠類就須要判斷何
時建立何種種類的產品，這就和建立何種種類產品的產品相互混淆在了⼀起，違背了單⼀職責，
致使系統喪失靈活性和可維護性。並且更重要的是，簡單工廠模式違背了「開放封閉原則」，就是違
背了「系統對擴展開放，對修改關閉」的原則，由於當我新增長⼀個產品的時候必須修改工廠類，相
應的工廠類就須要從新編譯⼀遍。
      總結⼀下：簡單工廠模式分離產品的建立者和消費者，有利於軟件系統結構的優化；可是因爲
⼀切邏輯都集中在⼀個工廠類中，致使了沒有很高的內聚性，同時也違背了「開放封閉原則」。另外
，簡單工廠模式的方法⼀般都是靜態的，而靜態工廠方法是沒法讓子類繼承的，所以，簡單工廠
模式沒法造成基於基類的繼承樹結構。
簡單工廠模式的實際應用簡介： 
       做爲⼀個最基本和最簡單的設計模式，簡單工廠模式卻有很很是普遍的應用，咱們這裏
以Java中的JDBC操做數據庫爲例來講明。
        JDBC是SUN公司提供的⼀套數據庫編程接口API，它利用Java語言提供簡單、⼀致的方式來
訪問各類關係型數據庫。Java程序經過JDBC能夠執行SQL語句，對獲取的數據進行處理，並將變
化了的數據存回數據庫，所以，JDBC是Java應用程序與各類關係數據進行對話的⼀種機制。
用JDBC進行數據庫訪問時，要使用數據庫廠商提供的驅動程序接口與數據庫管理系統進行數據

交互。

客戶端要使用使用數據時，只須要和工廠進行交互便可，這就致使操做步驟獲得極大的簡化，操 做步驟按照順序依次爲：註冊並加載數據庫驅動，⼀般使用Class.forName();建立與數據庫的鏈 接Connection對象；建立SQL語句對象preparedStatement(sql)；提交SQL語句，根據實際狀況使 用executeQuery()或者executeUpdate()；顯示相應的結果；關閉數據庫。 舒適提示：         嚴格意義上講，簡單工廠模式並不算是⼀種設計模式，簡單工廠模式更像是⼀種編程習慣，而 這被普遍的應用。可是由於簡單工廠模式在「高內聚」方面的欠缺，同時更致命的是違背了嚴格意義 上的「開放封閉原則」，或者說只對「開放封閉原則」提供某種程度上的支持，這就使得每次新增長⼀ 個產品的時候是很是麻煩的，由於每當增長⼀種新的產品的時候，工廠角色必須知道這個產品， 同時必須知道如何建立這個產品，還要以⼀種對客戶端有好的方式提供給客戶端使用。簡而言之 ，就是每增長⼀個新的產品就必須修改工廠角色的源代碼。因此簡單工廠模式是不利於構建容易 發生變化的系統的。而「需求老是在變化」，「世界上沒有⼀個軟件是不變的」。因此使用簡單工廠模 式的時候必須慎重考慮。 注意：該文檔參考和使用了網絡上的免費開放的圖片和內容，並以避免費開放的方式發佈,但願爲移 動互聯網和智能手機時代貢獻綿薄之力！能夠隨意轉載，但不得使用該文檔謀利。