JAVA之工廠模式(靜态工廠模式（簡單工廠模式）、工廠方法模式、抽象工廠模式)

一、引子

話說十年前,有一個暴發戶,他家有三輛汽車——Benz 奔馳、Bmw 寶馬、Audi 奧迪,

還雇了司機為他開車。不過,暴發戶坐車時總是怪怪的:上 Benz 車後跟司機說“開奔馳車!”, 坐上 Bmw 後他說“開寶馬車!”,坐上 Audi 說“開奧迪車!”。你一定說:這人有病!直接說 開車不就行了?!

而當把這個暴發戶的行為放到我們程式設計中來時,會發現這是一個普遍存在的現象。 幸運的是,這種有病的現象在 OO(面向對象)語言中可以避免了。下面就以 Java 語言為 基礎來引入我們本文的主題:工廠模式。

二、分類

工廠模式主要是為建立對象提供過渡接口,以便将建立對象的具體過程屏蔽隔離起來,達到提高靈活性的目的。

工廠模式在《Java 與模式》中分為三類:

1)簡單工廠模式(Simple Factory)

2)工廠方法模式(Factory Method)

3)抽象工廠模式(Abstract Factory)

這三種模式從上到下逐漸抽象,并且更具一般性。

GOF 在《設計模式》一書中将工廠模式分為兩類:工廠方法模式(Factory Method)與抽象工廠模式(Abstract Factory)。将簡單工廠模式(Simple Factory)看為工廠方法模式的 一種特例,兩者歸為一類。

兩者皆可,在本文使用《Java 與模式》的分類方法。下面來看看這些工廠模式是怎麼 來“治病”的。

三、簡單工廠模式 簡單工廠模式又稱靜态工廠方法模式。重命名上就可以看出這個模式一定很簡單。它存在的目的很簡單:定義一個用于建立對象的接口。

先來看看它的組成:

1.1) 工廠類角色:這是本模式的核心,含有一定的商業邏輯和判斷邏輯。在java中它往往由 一個具體類實作。

2.2) 抽象産品角色:它一般是具體産品繼承的父類或者實作的接口。在java中由接口或者抽 象類來實作。

3.3) 具體産品角色:工廠類所建立的對象就是此角色的執行個體。在java中由一個具體類實作。 來用類圖來清晰的表示下的它們之間的關系。

那麼簡單工廠模式怎麼來使用呢?我們就以簡單工廠模式來改造暴發戶坐車的方式 ——現在暴發戶隻需要坐在車裡對司機說句:“開車”就可以了。

①、簡單工廠模式執行個體！

下面 歡迎暴發戶出場……

這便是簡單工廠模式了！

首先,使用了簡單工廠模式後,我們的程式不在“有病”,更加符合現實中的情況;而且 用戶端免除了直接建立産品對象的責任,而僅僅負責“消費”産品(正如暴發戶所為)。

下面我們從開閉原則(對擴充開放;對修改封閉)上來分析下簡單工廠模式。當暴發戶 增加了一輛車的時候,隻要符合抽象産品制定的合同,那麼隻要通知工廠類知道就可以被客 戶使用了。是以對産品部分來說,它是符合開閉原則的;但是工廠部分好像不太理想,因為 每增加一輛車,都要在工廠類中增加相應的業務邏輯或者判斷邏輯,這顯然是違背開閉原則 的。可想而知對于新産品的加入,工廠類是很被動的。對于這樣的工廠類(在我們的例子中 是為司機師傅),我們稱它為全能類或者上帝類。

我們舉的例子是最簡單的情況,而在實際應用中,很可能産品是一個多層次的樹狀結構。 由于簡單工廠模式中隻有一個工廠類來對應這些産品,是以這可能會把我們的上帝累壞了, 也累壞了我們這些程式員

于是工廠方法模式作為救世主出現了。

四、工廠方法模式 工廠方法模式去掉了簡單工廠模式中工廠方法的靜态屬性,使得它可以被子類繼承。這樣在簡單工廠模式裡集中在工廠方法上的壓力可以由工廠方法模式裡不同的工廠子類來分擔。你應該大緻猜出了工廠方法模式的結構,來看下它的組成:

1.1) 抽象工廠角色: 這是工廠方法模式的核心,它與應用程式無關。是具體工廠角色必須實作的接口或者必須繼承的父類。在 java 中它由抽象類或者接口來實作。

2.2) 具體工廠角色:它含有和具體業務邏輯有關的代碼。由應用程式調用以建立對應的具體産品的對象。

3.3) 抽象産品角色:它是具體産品繼承的父類或者是實作的接口。在 java 中一般有抽象類 或者接口來實作。

4.4) 具體産品角色:具體工廠角色所建立的對象就是此角色的執行個體。在 java 中由具體的類來實作。

用類圖來清晰的表示下的它們之間的關系:

工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的“上帝類”。

正如上面所說,這樣便分擔了對象承受的壓力;而且這樣使得結構變得靈活起來——當有新 的産品(即暴發戶的汽車)産生時,隻要按照抽象産品角色、抽象工廠角色提供的合同來生 成,那麼就可以被客戶使用,而不必去修改任何已有的代碼。可以看出工廠角色的結構也是 符合開閉原則的!

我們還是老規矩,使用一個完整的例子來看看工廠模式各個角色之間是如何來協調的。 話說暴發戶生意越做越大,自己的愛車也越來越多。這可苦了那位司機師傅了,什麼車它都 要記得,維護,都要經過他來使用!于是暴發戶同情他說:看你跟我這麼多年的份上,以後 你不用這麼辛苦了,我給你配置設定幾個人手,你隻管管好他們就行了!于是,工廠方法模式的 管理出現了。代碼如下:

②工廠方法模式

有請暴發戶先生

可以看出工廠方法的加入,使得對象的數量成倍增長。當産品種類非常多時,會出現大 量的與之對應的工廠對象,這不是我們所希望的。因為如果不能避免這種情況,可以考慮使 用簡單工廠模式與工廠方法模式相結合的方式來減少工廠類:即對于産品樹上類似的種類 (一般是樹的葉子中互為兄弟的)使用簡單工廠模式來實作。

五、小結 工廠方法模式仿佛已經很完美的對對象的建立進行了包裝,使得客戶程式中僅僅處理抽

象産品角色提供的接口。那我們是否一定要在代碼中遍布工廠呢?大可不必。也許在下面情 況下你可以考慮使用工廠方法模式:

1) 當客戶程式不需要知道要使用對象的建立過程。

2) 客戶程式使用的對象存在變動的可能,或者根本就不知道使用哪一個具體的對象。 簡單工廠模式與工廠方法模式真正的避免了代碼的改動了?沒有。在簡單工廠模式中, 新産品的加入要修改工廠角色中的判斷語句;而在工廠方法模式中,要麼将判斷邏輯留在抽 象工廠角色中,要麼在客戶程式中将具體工廠角色寫死(就象上面的例子一樣)。而且産品 對象建立條件的改變必然會引起工廠角色的修改。

面對這種情況,Java 的反射機制與配置檔案的巧妙結合突破了限制——這在 Spring 中 完美的展現了出來。

六、抽象工廠模式

先來認識下什麼是産品族: 位于不同産品等級結構中,功能相關聯的産品組成的家族。

還是讓我們用一個例子來形象地說明一下吧。

BmwCar 和 BenzCar 就是兩個産品樹(産品層次結構);而BenzSportsCar 和 BmwSportsCar 就是一個産品族。他們都可以放到跑車家族中,是以功能 有所關聯。同理 BmwBussinessCar 和 BenzSportsCar 也是一個産品族。

回到抽象工廠模式的話題上。

可以說,抽象工廠模式和工廠方法模式的差別就在于需要建立對象的複雜程度上。而且 抽象工廠模式是三個裡面最為抽象、最具一般性的。

抽象工廠模式的用意為:給用戶端提供一個接口,可以建立多個産品族中的産品對象

而且使用抽象工廠模式還要滿足以下條件:

1.1) 系統中有多個産品族,而系統一次隻可能消費其中一族産品。

2.2) 同屬于同一個産品族的産品以其使用。

來看看抽象工廠模式的各個角色(和工廠方法的如出一轍):

1.1) 抽象工廠角色: 這是工廠方法模式的核心,它與應用程式無關。是具體工廠角色必須 實作的接口或者必須繼承的父類。在 java 中它由抽象類或者接口來實作。

2.2) 具體工廠角色:它含有和具體業務邏輯有關的代碼。由應用程式調用以建立對應的具體産品的對象。在 java 中它由具體的類來實作。

3.3) 抽象産品角色:它是具體産品繼承的父類或者是實作的接口。在 java 中一般有抽象類或者接口來實作。

③抽象工廠模式