設計模式之工廠方法模式

define an inte***ce for creating an object, but let subclasses decide which class to instantiate. factory method lets a class defer instantiation to subclasses. （定義乙個用於建立物件的介面，讓子類決定例項化哪類。工廠方法使乙個類的例項化延遲到其子類。）

工廠方法的通用類圖如下圖所示:

在工廠方法模式中，抽象產品類product 負責定義產品的共性，實現對事物最抽象的定義； factory為抽象建立類，也就是抽象工廠，具體如何建立產品類是由具體的實現工廠concretefactory完成的，而concreteproduct則負責具體產品的實現。

良好的封裝性，**結構清晰。乙個物件建立是有條件約束的，如個呼叫者需要個具體的產品物件，只要知道這個產品的類名（或約束字串）就可以了，不用知道建立物件的艱辛過程，降模組間的鵲合。

工廠方法模式的擴充套件性非常優秀。在增加產品類的情況，只要適當地修改具體的工廠類或擴充套件乙個工廠類，就可以完成「擁抱變化」。

遮蔽產品類。這特點非常重要，產品類實現如何化，呼叫者都不需要關心，它只需要關心產品的介面，只要介面保持不變，系統中的上層模組就不要發生變化。因為產品類的例項工作是由工廠類負責的，乙個產品物件具體由哪個產品生成是由工廠類決定的。

工廠方法模式是典型的解藕框架。高層模組只需要知道產品的抽象類，其他的實現類都不用關心，符合迪公尺特法則，我不需要的就不要去交流；也符合依賴倒置原則，只依賴產品類的抽象：當然也符合黎克特制替換原則，使用產品子類替換產品父類，沒問題！

乙個具體工廠只能建立一種具體產品。

增加新產品時，還需增加相應的工廠類，系統類的個數將成對增加，增加了系統的複雜度和效能開銷。

引入的抽象類也會導致類結構的複雜化。

工廠方法模式的變種較多，我們來看乙個通用的寫法：

public
abstract
class
product
/**     * 抽象方法
*/public
abstract
void
method2()
;}

具體的產品類可以有多個，都繼承於抽象產品類

public class concreteproduct1 extends product }public class concreteproduct2 extends product

}

抽象工廠類負責定義產品物件的產生，**如下所示:

public abstract class factory

具體如何產生產品的物件是由具體的工廠類實現的，**如下所示:

public
class
concretefactory
extends
factory
catch
(exception e)
return
(t) product;
}}

具體呼叫:

factory factory=
newconcretefactory()
;product product = factory.
createproduct
(concreteproduct1.
class);
// 後續的業務邏輯
product.
method1()
;product.
method2()
;

這是乙個比較通用的模式,可以根據不同專案自行擴充套件。

在實際使用場景中，當乙個模組僅需要乙個工廠類時，沒有必要把它產生出來，使用靜態的方法就可以了，這時候就可以用簡單工廠模式，也叫靜態工廠方法模式，其uml類圖如下所示:

和工廠方法模式比較，我們在類圖中去掉了factory抽象類，同時把concretefactory的create方法設定為靜態型別，簡化了類的建立過程，其**如下：

public
class
concretefactory
catch
(exception e)
return
(t) product;
}}

具體呼叫：

product product = concretefactory.
createproduct
(concreteproduct1.
class);
// 後續的業務邏輯
product.
method1()
; product.
method2()
;

執行結果沒有發生變化，但是我們的類圖變簡單了，而且呼叫也比較簡單。在實際專案中，採用該方法的案例還是比較多的，其缺點是工廠類的擴充套件比較困難，

不符合開閉原則，但它仍然是乙個非常實用的設計模式。

設計模式之工廠方法模式

設計模式 工廠模式之工廠方法模式

設計模式之工廠方法模式

設計模式之工廠方法模式

相關推薦

設計模式工廠模式之工廠方法模式