工廠模式中有: 工廠方法(factory method) 抽象工廠(abstract factory).
這兩個模式沒有很明顯的區別,區別在於需要建立物件的複雜程度上。如果我們建立物件的方法變得複雜了,我們就可能要將上例中factory變成抽象類,將共同部分封裝在抽象類中,不同部分使用子類實現。
下面關於是在網路中查到關於工廠方法模式與抽象工廠模式的概述和區別：
工廠方法模式：
乙個抽象產品類，可以派生出多個具體產品類。
乙個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類只能建立乙個具體產品類的例項。
抽象工廠模式：
多個抽象產品類，每個抽象產品類可以派生出多個具體產品類。
乙個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類可以建立多個具體產品類的例項。
區別：工廠方法模式只有乙個抽象產品類，而抽象工廠模式有多個。
工廠方法模式的具體工廠類只能建立乙個具體產品類的例項，而抽象工廠模式可以建立多個。
抽象工廠是一種建立型模式，是為了解決例項化時所帶來的問題。
抽象工廠是一種建立型模式，是為了解決例項化時所帶來的問題。
我們先來看看是什麼問題，有的時候我們會遇到這種情況，我們需要一系列的物件。舉個例子，有一系列bmw汽車零部件的物件：輪子bmwwheel，油箱bmwoilbox，在乙個管理函式中呼叫它們，**如下
class bmwwheel ;
} class bmwoilbox ;
}public void manage()
如果現在需求變了，我們要用大眾一汽bora的零件，不用bmw的，那麼我們除了要再加上相應的零件物件外還要將manage函式中的物件更改為bora的零件物件。
那這時發現new會帶來了一些問題：實現依賴，不能應對具體例項化型別的變化。
如何解決這類問題呢？封裝變化點。（沒有變化的就不需要封裝）
工廠模式的緣起：
1、變化點在「物件建立」，因此就封裝「物件建立」
2、面向介面程式設計
簡單工廠問題：
1、不能應對「不同系列物件」的變化。如：我們要在上面的**中加上其他的物件就不能很好的應對了
2、使用物件導向國內的技術來封裝變化點
動機：在軟體系統中，經常面臨著「一系列相互依賴的物件」的建立工作；同時，由於需求的變化，往往存在更多系列物件的建立工作。面對這種問題，我們想繞過常規的物件建立方法，提供一種「封裝機制」來避免客戶程式和這種「多系列具體物件建立工作」的緊耦合。
對於「緊耦合」，我原來是不喜歡這個詞的，但是今天明白了，不是程式緊耦合不好，而是面對頻繁變化的需求，緊耦合會使程式的編寫變得很吃力。如果面對乙個不變的需求，松耦合和緊耦合在**編寫上應該是沒什麼區別的。
下面我們來看看如何使用抽象工廠模式完成對這種變化的封裝：
首先我們的需求是bmw的車輪和油箱，當然他們要繼承各自的基類，**如下
abstract class abstractwheel
}abstract class abstractoilbox
}class bmwwheel:abstractwheel
}class bmwoilbox:abstractoilbox
} 然後，我們在建立乙個生產這些零件的工廠，它繼承自乙個抽象工廠
//抽象工廠
abstract class abstractfactory
class bmwfactory:abstractfactory
public override abstractoilbox creatoilbox() }
現在我們在main函式中呼叫它們：
static void main(string args)
顯示結果：
create a bmwwheel
create a bmwoilbox
現在我們想不用bmw的零件，用bora的零件了，先寫一些bora零件的類：
class borawheel:abstractwheel
}class boraoilbox:abstractoilbox
} 然後我們再建立bora零件的工廠：
class borafactory:abstractfactory
public override abstractoilbox creatoilbox() }
再來看看如何在main函式中修改使其呼叫bora的零件；我們只要在將main中的factory物件例項化為bora的工廠borafactory就可以了：
static void main(string args)
結果如下：
create a borawheel
create a boraoilbox
abstract factory模式的幾個要點：
1、如果沒有應對「多系列物件構建」的需求變化，則沒有必要使用abstract factory模式。
2、「系列物件」指的是這項物件之間有相互依賴、或作用的關係。
3、abstract factory模式主要在於應對「新系列」的需求變動。缺點是難以應對「新物件」的需求變動。這一點應該注意，就像前面說的，如果我們現在要在加入其他系列的類，**的改動會很大。
4、abstract factory模式經常和factory method模式共同組合來應對「物件建立」的需求變化。
抽象工廠，Abstract Factory
抽象工廠的定義是 提供乙個介面用於建立一系列相關或依賴的物件，而不需要指定具體的類。其uml類圖的示例如下 在這個模式中，參與者包括 實現 public inte ce abstractfactory public class concretefactorya abstractfactory pub...
設計模式 AbstractFactory
回想工廠方法模式，大廳可能有多種風格，a和b的widget也可能是不同組別不同人進行開發。這種情況下乙個工廠類顯然對 結構，程式可維護性有影響。我們可以建立多個widgetfactory分別生成a,b類的widget。abstractfactory.h ifndef abstractfactory ...
抽象工廠（Abstract Factory）
抽象工廠 abstract factory 抽象工廠，提供乙個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。別名 kit結構 參與者 abstractfactory 宣告乙個建立抽象產品物件的操作介面。concretefactory 實現建立具體產品物件的操作。abstractprod...