問題描述
一個系統通常由多個相互關聯的類/接口構成。如果這些相關類/接口存在不同版本的實現方式，如何保證這些不同版本的相關類能夠配套工作？當然可以用硬編碼的方式來保證，但是當這些相關類數目衆多，引用方式龐雜，硬編碼的方式並不容易，也不方便維護。抽象工廠模式提供一種直截了當的方式來確保這種相關性(類之間的配套關係)；通過一個具體的工廠類，程序員能夠方便的選擇一組配套的接口對象來配置該系統。
抽象工廠模式
如下圖所示，抽象工廠定義了一系列的工廠方法來創建本系統中相互關聯的產品(即接口ProductA, ProductB)。ConcreteFactory1或者ConcreteFacotry2能夠正確的選擇相關的具體類並形成配套(即ProductA1和ProductB1配套，ProductA2和ProductB2配套)。客戶端可以選擇ConcreteFactory1或者ConcreteFacotry2來配置軟件系統。同時，客戶端調用工廠方法(即CreateFactoryA()和CreateProductB())來創建相應的具體產品(即ProductA1,
ProductB1等)，讓客戶端和具體產品類型透明(因爲客戶端邏輯必須基於抽象類型ProductA & ProductB來構造，而不是基於ProductA1 & ProductB1來構造)。
討論
和工廠方法模式比較起來，可以說工廠方法模式就是抽象工廠模式的退化版本；但是抽象工廠模式更關注於如何配置多個相關對象，如何保證所創建出來的相關接口能夠配套工作。抽象工廠模式很容易的實現了產品的系列化，用ConcreteFactory2替換ConcreteFactory1就可以得到另外一套產品。
抽象工廠通常由工廠方法模式來構造，也可以由原型模式來構建。由於原型模式本身的動態可配置性，使用原型模式來實現抽象工廠模式的時候，不需要爲每個產品系列都定義一個具體的工廠類。