前面已經介紹過簡單工廠模式和工廠方法模式，這裡繼續介紹第三種工廠模式－抽象工廠模式，還是以汽車的製造為例。
範例背景：
隨著客戶的要求越來越高，寶馬車需要不同配置的空調和引擎等配件。於是這個工廠開始生產空調和發動機，用來組裝汽車。這時候工廠有兩個系列的產品:空調和引擎。 BMW320系列配置A型號空調和A型號發動機，BMW230系列配置B型號空調和B型號發動機。
概念：
抽象工廠模式是工廠方法模式的升級版本，他用來創造一組相關或相互依賴的物件。例如BMW320系列使用空調型號A和引擎型號A，而BMW230系列使用空調型號B和引擎型號B，那麼使用抽象工廠模式，在為320系列生產相關配件時，就無需制定配件的型號，它會自動根據車型生產對應的配件型號A。
針對百度百科上對於抽象工廠模式的簡介，結合本例如下：
當每個抽象產品都有多於一個的具體子類的時候（空調有型號A和B兩種，發動機也有型號A和B兩種），工廠角色怎麼知道實例化哪一個子類別？例如每個抽象產品角色都有兩個具體產品（產品空調有兩個具體產品空調A和空調B）。抽象工廠模式提供兩個具體工廠角色（BMW320系列工廠和BMW230系列工廠），分別對應這兩個特定產品角色，每個特定工廠角色只負責某一個產品角色的實例化。每一個具體工廠類別只負責創建抽象產品的某一個具體子類別的實例。
抽象工廠模式代碼
產品類別：
//发动机以及型号
public interface Engine {
}
public class EngineA extends Engine{
public EngineA(){
System.out.println("制造-->EngineA");
}
}
public class EngineBextends Engine{
public EngineB(){
System.out.println("制造-->EngineB");
}
}
//空调以及型号
public interface Aircondition {
}
public class AirconditionA extends Aircondition{
public AirconditionA(){
System.out.println("制造-->AirconditionA");
}
}
public class AirconditionB extends Aircondition{
public AirconditionB(){
System.out.println("制造-->AirconditionB");
}
}創建工廠類別：
//创建工厂的接口
public interface AbstractFactory {
//制造发动机
public Engine createEngine();
//制造空调
public Aircondition createAircondition();
}
//为宝马320系列生产配件
public class FactoryBMW320 implements AbstractFactory{
@Override
public Engine createEngine() {
return new EngineA();
}
@Override
public Aircondition createAircondition() {
return new AirconditionA();
}
}
//宝马523系列
public class FactoryBMW523 implements AbstractFactory {
@Override
public Engine createEngine() {
return new EngineB();
}
@Override
public Aircondition createAircondition() {
return new AirconditionB();
}
}客戶:
public class Customer {
public static void main(String[] args){
//生产宝马320系列配件
FactoryBMW320 factoryBMW320 = new FactoryBMW320();
factoryBMW320.createEngine();
factoryBMW320.createAircondition();
//生产宝马523系列配件
FactoryBMW523 factoryBMW523 = new FactoryBMW523();
factoryBMW320.createEngine();
factoryBMW320.createAircondition();
}
}關於抽象工廠模式與工廠方法模式的區別，這裡就不說了，感覺多幾遍就能理解，還有很多提到的產品族、等級結構等概念，說了反而更難理解。
抽象工廠模式的起源
下面引用一段抽象工廠模式的起源：
抽象工廠模式的起源或最早的應用，是用於創建分屬於不同操作系統的視窗構建。例如：命令按鍵（Button）與文字框（Text)都是視窗構建，在UNIX作業系統的視窗環境和Windows作業系統的視窗環境中，這兩個建置有不同的本機實現，它們的細節有所不同。
在每個作業系統中，都有一個視窗建構組成的建構家族。這裡就是Button和Text組成的產品族。而每一個視窗構件都構成自己的等級結構，由一個抽象角色給予抽象的功能描述，而由具體子類別給出不同作業系統下的具體實作。
可以發現在上面的產品類別圖中，有兩個產品的等級結構，分別是Button等級結構和Text等級結構。同時有兩個產品族，也就是UNIX產品族和Windows產品族。 UNIX產品族由UNIX Button和UNIX Text產品構成；而Windows產品族則由Windows Button和Windows Text產品構成。
系統對產品物件的創建需求由一個工程的等級結構滿足，其中有兩個具體工程角色，即UnixFactory和WindowsFactory。 UnixFactory物件負責建立Unix產品族中的產品，而WindowsFactory物件負責建立Windows產品族中的產品。這就是抽象工廠模式的應用，抽象工廠模式的解決方案如下圖：
顯然，一個系統只能夠在某一個操作系統的視窗環境下運行，而不能同時在不同的操作系統上運行。所以，系統其實只能消費屬於同一個產品族的產品。
在現代的應用中，抽象工廠模式的使用範圍已經大大擴大了，不再要求系統只能消費某一個產品族了。
總結：
無論是簡單工廠模式，工廠方法模式，還是抽象工廠模式，他們都屬於工廠模式，在形式和特點上也是極為相似的，他們的最終目的都是為了解耦。在使用時，我們不必去在意這個模式到底工廠方法模式還是抽象工廠模式，因為他們之間的演變常常是令人琢磨不透的。經常你會發現，明明使用的工廠方法模式，當新需求來臨，稍加修改，加入了一個新方法後，由於類別中的產品構成了不同等級結構中的產品族，它就變成抽象工廠模式了；而對於抽象工廠模式，當減少一個方法使的提供的產品不再構成產品族之後，它就演變成了工廠方法模式。
所以，使用工廠模式時，只需要關心降低耦合度的目的是否達到了。
更多JAVA設計模式之抽象工廠模式相關文章請關注PHP中文網！
相關文章：
