簡單工廠模式

簡單工廠模式（Simple Factory Pattern）屬于類的創(chuàng)新型模式，又叫靜態(tài)工廠方法模式（Static FactoryMethod Pattern）,是通過專門定義一個類來負責創(chuàng)建其他類的實例，被創(chuàng)建的實例通常都具有共同的父類。

簡單工廠模式的UML圖：

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

• 工廠角色（Creator）：這是簡單工廠模式的核心，由它負責創(chuàng)建所有的類的內(nèi)部邏輯。當然工廠類必須能夠被外界調(diào)用，創(chuàng)建所需要的產(chǎn)品對象。
• 抽象（Product）產(chǎn)品角色：簡單工廠模式所創(chuàng)建的所有對象的父類，注意，這里的父類可以是接口也可以是抽象類，它負責描述所有實例所共有的公共接口。
• 具體產(chǎn)品（Concrete Product）角色：簡單工廠所創(chuàng)建的具體實例對象，這些具體的產(chǎn)品往往都擁有共同的父類。

簡單工廠模式深入分析

簡單工廠模式解決的問題是如何去實例化一個合適的對象。

簡單工廠模式的核心思想就是：有一個專門的類來負責創(chuàng)建實例的過程。

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

如果簡單工廠模式所涉及到的具體產(chǎn)品之間沒有共同的邏輯，那么我們就可以使用接口來扮演抽象產(chǎn)品的角色；如果具體產(chǎn)品之間有功能的邏輯或，我們就必須把這些共同的東西提取出來，放在一個抽象類中，然后讓具體產(chǎn)品繼承抽象類。為實現(xiàn)更好復用的目的，共同的東西總是應該抽象出來的。

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

簡單工廠模式使用場景分析及代碼實現(xiàn)

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

實現(xiàn)代碼

新建立一個食物的接口：

/*
 * 產(chǎn)品的抽象接口
 */
public interface Food {
    //獲得相應的食物
    public void get();
}

接下來建立具體的產(chǎn)品：麥香雞和薯條

/*
 * 麥香雞對抽象產(chǎn)品接口的實現(xiàn)
 */
public class McChicken implements Food{
    /*
     * 獲取一份麥香雞
     */
    public void get(){
        System.out.println("我要一份麥香雞");
    }
}

/*
 * 薯條對抽象產(chǎn)品接口的實現(xiàn)
 */
public class Chips implements Food{
    /*
     * 獲取一份薯條
     */
    public void get(){
        System.out.println("我要一份薯條");
    }
}

現(xiàn)在建立一個食物加工工廠：

public class FoodFactory {
    public static Food getFood(String type) throws Exception {
        if(type.equalsIgnoreCase("mcchicken")) {
            return McChicken.class.newInstance();
        } else if(type.equalsIgnoreCase("chips")) {
            return Chips.class.newInstance();
        } else {
            System.out.println("哎呀！找不到相應的實例化類啦！");
            return null;
        }
    }
}

最后測試：

public class SimpleFactoryTest {
    public static void main(String[] args) throws Exception {
        //實例化各種食物
        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();
        }
    }
}

簡單工廠模式的優(yōu)缺點分析

• 優(yōu)點：工廠類是整個模式的關鍵所在。它包含必要的判斷邏輯，能夠根據(jù)外界給定的信息，決定究竟應該創(chuàng)建哪個具體類的對象。用戶在使用時可以直接根據(jù)工廠類去創(chuàng)建所需的實例，而無需了解這些對象是如何創(chuàng)建以及如何組織的。有利于整個軟件體系結構的優(yōu)化。
• 缺點：由于工廠類集中了所有實例的創(chuàng)建邏輯，這就直接導致一旦這個工廠出了問題，所有的客戶端都會受到牽連；而且由于簡單工廠模式的產(chǎn)品室基于一個共同的抽象類或者接口，這樣一來，但產(chǎn)品的種類增加的時候，即有不同的產(chǎn)品接口或者抽象類的時候，工廠類就需要判斷何時創(chuàng)建何種種類的產(chǎn)品，這就和創(chuàng)建何種種類產(chǎn)品的產(chǎn)品相互混淆在了一起，違背了單一職責，導致系統(tǒng)喪失靈活性和可維護性。而且更重要的是，簡單工廠模式違背了“開放封閉原則”，就是違背了“系統(tǒng)對擴展開放，對修改關閉”的原則，因為當我新增加一個產(chǎn)品的時候必須修改工廠類，相應的工廠類就需要重新編譯一遍。
• 總結一下：簡單工廠模式分離產(chǎn)品的創(chuàng)建者和消費者，有利于軟件系統(tǒng)結構的優(yōu)化；但是由于一切邏輯都集中在一個工廠類中，導致了沒有很高的內(nèi)聚性，同時也違背了“開放封閉原則”。另外，簡單工廠模式的方法一般都是靜態(tài)的，而靜態(tài)工廠方法是無法讓子類繼承的，因此，簡單工廠模式無法形成基于基類的繼承樹結構。

簡單工廠模式的實際應用

作為一個最基本和最簡單的設計模式，簡單工廠模式卻有很非常廣泛的應用，我們這里以Java中的JDBC操作數(shù)據(jù)庫為例來說明。

JDBC是SUN公司提供的一套數(shù)據(jù)庫編程接口API，它利用Java語言提供簡單、一致的方式來訪問各種關系型數(shù)據(jù)庫。Java程序通過JDBC可以執(zhí)行SQL語句，對獲取的數(shù)據(jù)進行處理，并將變化了的數(shù)據(jù)存回數(shù)據(jù)庫，因此，JDBC是Java應用程序與各種關系數(shù)據(jù)進行對話的一種機制。用JDBC進行數(shù)據(jù)庫訪問時，要使用數(shù)據(jù)庫廠商提供的驅動程序接口與數(shù)據(jù)庫管理系統(tǒng)進行數(shù)據(jù)交互。

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

工廠方法模式

定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個類，工廠方法使一個類的實例化延遲到其子類。

代碼示例

interface IProduct {  
    public void productMethod();  
}  
  
class Product implements IProduct {  
    public void productMethod() {  
        System.out.println("產(chǎn)品");  
    }  
}  
  
interface IFactory {  
    public IProduct createProduct();  
}  
  
class Factory implements IFactory {  
    public IProduct createProduct() {  
        return new Product();  
    }  
}  
  
public class Client {  
    public static void main(String[] args) {  
        IFactory factory = new Factory();  
        IProduct prodect = factory.createProduct();  
        prodect.productMethod();  
    }  
}  

工廠模式：

首先需要說一下工廠模式。

工廠模式根據(jù)抽象程度的不同分為三種：簡單工廠模式（也叫靜態(tài)工廠模式）、本文所講述的工廠方法模式、以及抽象工廠模式。工廠模式是編程中經(jīng)常用到的一種模式。

它的主要優(yōu)點有：

• 可以使代碼結構清晰，有效地封裝變化。在編程中，產(chǎn)品類的實例化有時候是比較復雜和多變的，通過工廠模式，將產(chǎn)品的實例化封裝起來，使得調(diào)用者根本無需關心產(chǎn)品的實例化過程，只需依賴工廠即可得到自己想要的產(chǎn)品。
• 對調(diào)用者屏蔽具體的產(chǎn)品類。如果使用工廠模式，調(diào)用者只關心產(chǎn)品的接口就可以了，至于具體的實現(xiàn)，調(diào)用者根本無需關心。即使變更了具體的實現(xiàn)，對調(diào)用者來說沒有任何影響。
• 降低耦合度。產(chǎn)品類的實例化通常來說是很復雜的，它需要依賴很多的類，而這些類對于調(diào)用者來說根本無需知道，如果使用了工廠方法，我們需要做的僅僅是實例化好產(chǎn)品類，然后交給調(diào)用者使用。對調(diào)用者來說，產(chǎn)品所依賴的類都是透明的。

工廠方法模式：

通過工廠方法模式的類圖可以看到，工廠方法模式有四個要素：

• 工廠接口。工廠接口是工廠方法模式的核心，與調(diào)用者直接交互用來提供產(chǎn)品。在實際編程中，有時候也會使用一個抽象類來作為與調(diào)用者交互的接口，其本質上是一樣的。
• 工廠實現(xiàn)。在編程中，工廠實現(xiàn)決定如何實例化產(chǎn)品，是實現(xiàn)擴展的途徑，需要有多少種產(chǎn)品，就需要有多少個具體的工廠實現(xiàn)。
• 產(chǎn)品接口。產(chǎn)品接口的主要目的是定義產(chǎn)品的規(guī)范，所有的產(chǎn)品實現(xiàn)都必須遵循產(chǎn)品接口定義的規(guī)范。產(chǎn)品接口是調(diào)用者最為關心的，產(chǎn)品接口定義的優(yōu)劣直接決定了調(diào)用者代碼的穩(wěn)定性。同樣，產(chǎn)品接口也可以用抽象類來代替，但要注意最好不要違反里氏替換原則。
• 產(chǎn)品實現(xiàn)。實現(xiàn)產(chǎn)品接口的具體類，決定了產(chǎn)品在客戶端中的具體行為。

前文提到的簡單工廠模式跟工廠方法模式極為相似，區(qū)別是：簡單工廠只有三個要素，他沒有工廠接口，并且得到產(chǎn)品的方法一般是靜態(tài)的。因為沒有工廠接口，所以在工廠實現(xiàn)的擴展性方面稍弱，可以算所工廠方法模式的簡化版，關于簡單工廠模式，在此一筆帶過。

適用場景

不管是簡單工廠模式，工廠方法模式還是抽象工廠模式，他們具有類似的特性，所以他們的適用場景也是類似的。

首先，作為一種創(chuàng)建類模式，在任何需要生成復雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是復雜對象適合使用工廠模式，而簡單對象，特別是只需要通過new就可以完成創(chuàng)建的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統(tǒng)的復雜度。

其次，工廠模式是一種典型的解耦模式，迪米特法則在工廠模式中表現(xiàn)的尤為明顯。假如調(diào)用者自己組裝產(chǎn)品需要增加依賴關系時，可以考慮使用工廠模式。將會大大降低對象之間的耦合度。

再次，由于工廠模式是依靠抽象架構的，它把實例化產(chǎn)品的任務交由實現(xiàn)類完成，擴展性比較好。也就是說，當需要系統(tǒng)有比較好的擴展性時，可以考慮工廠模式，不同的產(chǎn)品用不同的實現(xiàn)工廠來組裝。

典型應用

要說明工廠模式的優(yōu)點，可能沒有比組裝汽車更合適的例子了。場景是這樣的：汽車由發(fā)動機、輪、底盤組成，現(xiàn)在需要組裝一輛車交給調(diào)用者。假如不使用工廠模式，代碼如下：

class Engine {  
    public void getStyle(){  
        System.out.println("這是汽車的發(fā)動機");  
    }  
}  
class Underpan {  
    public void getStyle(){  
        System.out.println("這是汽車的底盤");  
    }  
}  
class Wheel {  
    public void getStyle(){  
        System.out.println("這是汽車的輪胎");  
    }  
}  
public class Client {  
    public static void main(String[] args) {  
        Engine engine = new Engine();  
        Underpan underpan = new Underpan();  
        Wheel wheel = new Wheel();  
        ICar car = new Car(underpan, wheel, engine);  
        car.show();  
    }  
}  

可以看到，調(diào)用者為了組裝汽車還需要另外實例化發(fā)動機、底盤和輪胎，而這些汽車的組件是與調(diào)用者無關的，耦合度太高。并且非常不利于擴展。另外，本例中發(fā)動機、底盤和輪胎還是比較具體的，在實際應用中，可能這些產(chǎn)品的組件也都是抽象的，調(diào)用者根本不知道怎樣組裝產(chǎn)品。假如使用工廠方法的話，整個架構就顯得清晰了許多。

interface IFactory {  
    public ICar createCar();  
}  
class Factory implements IFactory {  
    public ICar createCar() {  
        Engine engine = new Engine();  
        Underpan underpan = new Underpan();  
        Wheel wheel = new Wheel();  
        ICar car = new Car(underpan, wheel, engine);  
        return car;  
    }  
}  
public class Client {  
    public static void main(String[] args) {  
        IFactory factory = new Factory();  
        ICar car = factory.createCar();  
        car.show();  
    }  
}  

使用工廠方法后，調(diào)用端的耦合度大大降低了。

并且對于工廠來說，是可以擴展的，以后如果想組裝其他的汽車，只需要再增加一個工廠類的實現(xiàn)就可以。

無論是靈活性還是穩(wěn)定性都得到了極大的提高。

到此這篇關于Java簡單工廠和工廠方法模式詳細解析的文章就介紹到這了,更多相關Java工廠方法模式內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論