問題描述
乙個介面（如下圖的product）可能有多種實現方式。程式邏輯在例項化這種型別/介面的具體類(如下圖的concreteproduct)的時候，如果直接使用的方式來撰寫；當需求變更的時候，程式需要使用另外乙個子類（例如subproduct）來替換該類的時候，所有使用的地方都需要修改。這種**的特徵是：沒有封裝好程式的乙個可能的「變化點」(即具體物件建立的可變性)。工廠方法模式把這種物件例項化的**封裝到乙個相對穩定的factory method中，讓乙個可能變化的邏輯(類如何例項化)對於客戶而言穩定不變。
工廠方法模式
如下圖所示，工廠方法模式為具體物件(concreteproduct)的建立提供乙個間接層，客戶端通過乙個穩定的物件建立介面(即工廠方法: product* concretecreator::createproduct())來例項化該物件。當程式邏輯需要使用乙個不同於concreteproduct的類來定義程式行為時，只需要修改concretecreator類的方法product* concretecreator::createproduct()的實現就可以了。雖然客戶端硬編碼了乙個factory method類(即concretecreator類)，相對於到處修改，這種硬編碼方式讓變化集中到了乙個變化點，讓程式的修改侷限在乙個可控的範圍。
討論
工廠方法模式的價值在於：
下面的**展示了mfc中使用本模式的乙個例子：createobject()本質上就是乙個工廠方法，可以建立乙個不帶引數的，支援動態建立的mfc物件。雖然沒有抽象基類，但是已經體現了工廠方法模式的本質：通過乙個穩定的介面來建立物件，返回乙個抽象型別；讓物件的建立者和物件的具體型別解耦。
#define _declare_dyncreate(class_name) \
_declare_dynamic(class_name) \
static cobject* pascal createobject();
#define implement_dyncreate(class_name, base_class_name) \
cobject* pascal class_name::createobject() \
\implement_runtimeclass(class_name, base_class_name, 0xffff, \
class_name::createobject) \
...
設計模式 1 工廠方法
1 概述 一 工廠方法模式 1 建立產品物件的工廠介面 2 子類物件決定例項化的具體物件 工廠不負責具體的物件建立 二 設計原則 1 開 閉 2 依賴倒置 無論工廠或者產品依賴於抽象而非具體的實現類 三 場合 1 子類可能很多,以後要不斷增加不同的子類實現 抽象工廠 生產抽象寶刀 public in...
設計模式（1） 工廠方法模式
工廠方法模式uml類圖如圖所示 說明 具體產品繼承抽象產品，具體工廠繼承抽象工廠，具體工廠依賴具體產品。具體例項 如下所示 其實是在簡單工廠模式例項 的基礎上對工廠類進行了一下抽象 抽象工廠類 public abstract class abstractfactory具體產品a工廠類 ublic c...
設計模式 1 工廠方法模式
簡單工廠模式有個問題是，類的建立是需要依賴工廠類的，如果要拓展程式，那麼需要對工廠類進行修改，這個增加了風險。工廠方法模式可以避免這種情況，方法建立乙個工廠介面和建立多個工廠類，理解如下 對了抽象方法a，b和c分別為其的兩個不同實現，現在建立工廠介面d，工廠介面d的實列類e和f分別對b和c進行實列化...