1. 程式人生 > >設計模式之簡單工廠模式,工廠方法模式,抽象工廠模式

設計模式之簡單工廠模式,工廠方法模式,抽象工廠模式

在面向物件程式設計中, 最通常的方法是一個new操作符產生一個物件例項,new操作符就是用來構造物件例項的。但是在一些情況下, new操作符直接生成物件會帶來一些問題。舉例來說, 許多型別物件的創造需要一系列的步驟: 你可能需要計算或取得物件的初始設定; 選擇生成哪個子物件例項; 或在生成你需要的物件之前必須先生成一些輔助功能的物件。 在這些情況,新物件的建立就是一個 “過程”,不僅是一個操作,像一部大機器中的一個齒輪傳動。

模式的問題:你如何能輕鬆方便地構造物件例項,而不必關心構造物件例項的細節和複雜過程呢?

解決方案:建立一個工廠來建立物件

1.引言

1)還沒有工廠時代:假如還沒有工業革命,如果一個客戶要一款寶馬車,一般的做法是客戶去建立一款寶馬車,然後拿來用。
2)簡單工廠模式:後來出現工業革命。使用者不用去建立寶馬車。因為客戶有一個工廠來幫他建立寶馬.想要什麼車,這個工廠就可以建。比如想要320i系列車。工廠就建立這個系列的車。即工廠可以建立產品。
3)工廠方法模式時代:為了滿足客戶,寶馬車系列越來越多,如320i,523i,30li等系列一個工廠無法建立所有的寶馬系列。於是由單獨分出來多個具體的工廠。每個具體工廠建立一種系列。即具體工廠類只能建立一個具體產品。但是寶馬工廠還是個抽象。你需要指定某個具體的工廠才能生產車出來。

4)抽象工廠模式時代:隨著客戶的要求越來越高,寶馬車必須配置空調。於是這個工廠開始生產寶馬車和需要的空調。

最終是客戶只要對寶馬的銷售員說:我要523i空調車,銷售員就直接給他523i空調車了。而不用自己去建立523i空調車寶馬車.

這就是工廠模式。

2.分類

工廠模式主要是為建立物件提供過渡介面,以便將建立物件的具體過程遮蔽隔離起來,達到提高靈活性的目的。
工廠模式可以分為三類:

1)簡單工廠模式(Simple Factory)
2)工廠方法模式(Factory Method)
3)抽象工廠模式(Abstract Factory)

這三種模式從上到下逐步抽象,並且更具一般性。
GOF在《設計模式》一書中將工廠模式分為兩類:工廠方法模式(Factory Method)與抽象工廠模式(Abstract Factory)。

將簡單工廠模式(Simple Factory)看為工廠方法模式的一種特例,兩者歸為一類。

3.區別

工廠方法模式:
一個抽象產品類,可以派生出多個具體產品類。
一個抽象工廠類,可以派生出多個具體工廠類。
每個具體工廠類只能建立一個具體產品類的例項。
抽象工廠模式:
多個抽象產品類,每個抽象產品類可以派生出多個具體產品類。
一個抽象工廠類,可以派生出多個具體工廠類。
每個具體工廠類可以建立多個具體產品類的例項。
區別:
工廠方法模式只有一個抽象產品類,而抽象工廠模式有多個。
工廠方法模式的具體工廠類只能建立一個具體產品類的例項,而抽象工廠模式可以建立多個。
兩者皆可

4.簡單工廠模式

分佈說明引子:如果沒有工廠模式,從無到有。客戶自己建立寶馬車,然後拿來用。

public class BMW320 {
    public BMW320() {
        System.out.println("生產-->BMW320");
    }
}
public class BMW523 { 
    public BMW523() {
        System.out.println("生產-->BMW523");
    }
}
public class Client {

    public static void main(String[] args) {
        BMW320 bmw320 = new BMW320();
        BMW523 bmw523 = new BMW523();
    }
}

如果按照這種做法,客戶需要知道怎麼去建立一款車,客戶和車就緊密耦合在一起了.為了降低耦合,就出現了工廠類,把建立寶馬的操作細節都放到了工廠裡面去,客戶直接使用工廠的建立工廠方法,傳入想要的寶馬車型號就行了,而不必去知道建立的細節.這就是工業革命了:簡單工廠模式,即我們建立一個工廠類方法來製造新的物件。

產品相關的類:

public abstract class BMW {

    public BMW() {}
}
public class BMW320 extends BMW {

    public BMW320() {
        System.out.println("生產-->BMW320");
    }
}
public class BMW523 extends BMW {
    public BMW523() {
        System.out.println("生產-->BMW523");
    }
}

工廠類:

public class Factory {

    public BMW createBMW(int type) {
        switch (type) {
            case 320:
                return new BMW320();
            case 523:
                return new BMW523();
            default:
                break;
        }
        return null;
    }
}

客戶端:

public class Client {

    public static void main(String[] args) {
        Factory factory = new Factory();
        BMW bmw320 = factory.createBMW(320);
        BMW bmw523 = factory.createBMW(523);
    }
}

簡單工廠模式又稱靜態工廠方法模式。重新命名上就可以看出這個模式一定很簡單。它存在的目的很簡單:定義一個用於建立物件的介面。
先來看看它的組成:
1) 工廠類角色:這是本模式的核心,含有一定的商業邏輯和判斷邏輯,用來建立產品
2) 抽象產品角色:它一般是具體產品繼承的父類或者實現的介面。
3) 具體產品角色:工廠類所建立的物件就是此角色的例項。在Java中由一個具體類實現。

面我們從開閉原則(對擴充套件開放;對修改封閉)上來分析下簡單工廠模式。當客戶不再滿足現有的車型號的時候,想要一種速度快的新型車,只要這種車符合抽象產品制定的合同,那麼只要通知工廠類知道就可以被客戶使用了。所以對產品部分來說,它是符合開閉原則的;但是工廠部分好像不太理想,因為每增加一種新型車,都要在工廠類中增加相應的建立業務邏輯(createBMW(int type)方法需要新增case),這顯然是違背開閉原則的。可想而知對於新產品的加入,工廠類是很被動的。對於這樣的工廠類,我們稱它為全能類或者上帝類。
我們舉的例子是最簡單的情況,而在實際應用中,很可能產品是一個多層次的樹狀結構。由於簡單工廠模式中只有一個工廠類來對應這些產品,所以這可能會把我們的上帝累壞了,也累壞了我們這些程式設計師。
於是工廠方法模式作為救世主出現了。 工廠類定義成了介面,而每新增的車種型別,就增加該車種型別對應工廠類的實現,這樣工廠的設計就可以擴充套件了,而不必去修改原來的程式碼。

5.工廠方法模式

工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性,使得它可以被子類繼承。這樣在簡單工廠模式裡集中在工廠方法上的壓力可以由工廠方法模式裡不同的工廠子類來分擔。
工廠方法模式組成:
1)抽象工廠角色: 這是工廠方法模式的核心,它與應用程式無關。是具體工廠角色必須實現的介面或者必須繼承的父類。在java中它由抽象類或者介面來實現。
2)具體工廠角色:它含有和具體業務邏輯有關的程式碼。由應用程式呼叫以建立對應的具體產品的物件。
3)抽象產品角色:它是具體產品繼承的父類或者是實現的介面。在java中一般有抽象類或者介面來實現。
4)具體產品角色:具體工廠角色所建立的物件就是此角色的例項。在java中由具體的類來實現。
工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的“上帝類”。正如上面所說,這樣便分擔了物件承受的壓力;而且這樣使得結構變得靈活 起來——當有新的產品產生時,只要按照抽象產品角色、抽象工廠角色提供的合同來生成,那麼就可以被客戶使用,而不必去修改任何已有 的程式碼。可以看出工廠角色的結構也是符合開閉原則的!

程式碼如下:
產品類:

public abstract class BMW {
    public BMW() {}
}
public class BMW320 extends BMW {
    public BMW320() {
        System.out.println("製造-->BMW320");
    }
}
public class BMW523 extends BMW{

    public BMW523() {
        System.out.println("製造-->BMW523");
    }
}

工廠類:

public interface FactoryBWM {

    BMW createBMW();
}
public class FactoryBMW320 implements FactoryBWM {

    @Override
    public BMW320 createBMW() {
        return new BMW320();
    }
}
public class FactoryBMW523 implements FactoryBWM {

    @Override
    public BMW523 createBMW() {
        return new BMW523();
    }

}

客戶端:

public class Client {
    public static void main(String[] args) {
        FactoryBMW320 factoryBMW320 = new FactoryBMW320();
        BMW320 bmw320 = factoryBMW320.createBMW();

        FactoryBMW523 factoryBMW523 = new FactoryBMW523();
        BMW523 bmw523 = factoryBMW523.createBMW();
    }
}

工廠方法模式彷彿已經很完美的對物件的建立進行了包裝,使得客戶程式中僅僅處理抽象產品角色提供的介面,但使得物件的數量成倍增長。當產品種類非常多時,會出現大量的與之對應的工廠物件,這不是我們所希望的。

6.抽象工廠模式

隨著客戶的要求越來越高,寶馬車需要不同配置的空調和發動機等配件。於是這個工廠開始生產空調和發動機,用來組裝汽車。這時候工廠有兩個系列的產品:空調和發動機。寶馬320系列配置A型號空調和A型號發動機,寶馬230系列配置B型號空調和B型號發動機。

概念:
抽象工廠模式是工廠方法模式的升級版本,他用來建立一組相關或者相互依賴的物件。比如寶馬320系列使用空調型號A和發動機型號A,而寶馬230系列使用空調型號B和發動機型號B,那麼使用抽象工廠模式,在為320系列生產相關配件時,就無需制定配件的型號,它會自動根據車型生產對應的配件型號A。
針對百度百科上對於抽象工廠模式的簡介,結合本例如下:

當每個抽象產品都有多於一個的具體子類的時候(空調有型號A和B兩種,發動機也有型號A和B兩種),工廠角色怎麼知道例項化哪一個子類呢?比如每個抽象產品角色都有兩個具體產品(產品空調有兩個具體產品空調A和空調B)。抽象工廠模式提供兩個具體工廠角色(寶馬320系列工廠和寶馬230系列工廠),分別對應於這兩個具體產品角色,每一個具體工廠角色只負責某一個產品角色的例項化。每一個具體工廠類只負責建立抽象產品的某一個具體子類的例項。

抽象工廠模式程式碼

產品類:

//發動機相關
public interface Engine {
}
public class EngineA implements Engine {
    public EngineA() {
        System.out.println("製造-->EngineA");
    }
}
public class EngineB implements Engine {
    public EngineB() {
        System.out.println("製造-->EngineB");
    }
}
public interface AirCondition {
}
public class AirConditionA implements AirCondition {
    public AirConditionA() {
        System.out.println("製造-->AirconditionA");
    }
}
public class AirConditionB implements AirCondition {
    public AirConditionB() {
        System.out.println("製造-->AirconditionB");
    }
}

建立工廠類:

public interface AbstractFactory {

    public Engine createEngine();

    public AirCondition createAirCondition();
}
public class FactoryBMW320 implements  AbstractFactory {

    @Override
    public Engine createEngine() {
        return new EngineA();
    }

    @Override
    public AirCondition createAirCondition() {
        return new AirConditionA();
    }
}
public class FactoryBMW523 implements AbstractFactory {

    @Override
    public Engine createEngine() {
        return new EngineB();
    }

    @Override
    public AirCondition createAirCondition() {
        return new AirConditionB();
    }
}

客戶端程式碼:

public class Client {

    public static void main(String[] args) {
        FactoryBMW320 factoryBMW320 = new FactoryBMW320();
        factoryBMW320.createEngine();
        factoryBMW320.createAirCondition();

        FactoryBMW523 factoryBMW523 = new FactoryBMW523();
        factoryBMW523.createEngine();
        factoryBMW523.createAirCondition();
    }
}

7.總結

無論是簡單工廠模式,工廠方法模式,還是抽象工廠模式,他們都屬於工廠模式,在形式和特點上也是極為相似的,他們的最終目的都是為了解耦。在使用時,我們不必去在意這個模式到底工廠方法模式還是抽象工廠模式,因為他們之間的演變常常是令人琢磨不透的。經常你會發現,明明使用的工廠方法模式,當新需求來臨,稍加修改,加入了一個新方法後,由於類中的產品構成了不同等級結構中的產品族,它就變成抽象工廠模式了;而對於抽象工廠模式,當減少一個方法使的提供的產品不再構成產品族之後,它就演變成了工廠方法模式。
所以,在使用工廠模式時,只需要關心降低耦合度的目的是否達到了。