一、場景
舉個生活中常見的例子——組裝電腦,我們在組裝電腦的時候,通常需要選擇一系列的配件,比如CPU、硬盤、內存、主板、電源、機箱等。為討論使用簡單點,只考慮選擇CPU和主板的問題。
事實上,在選擇CPU的時候,面臨一系列的問題,比如品牌、型號、針腳數目、主頻等問題,只有把這些問題都確定下來,才能確定具體的CPU。
同樣,在選擇主板的時候,也有一系列問題,比如品牌、芯片組、集成芯片、總線頻率等問題,也只有這些都確定了,才能確定具體的主板。
選擇不同的CPU和主板,是每個客戶在組裝電腦的時候,向裝機公司提出的要求,也就是我們每個人自己擬定的裝機方案。
在最終確定這個裝機方案之前,還需要整體考慮各個配件之間的兼容性。比如:CPU和主板,如果使用Intel的CPU和AMD的主板是根本無法組裝的。因為Intel的CPU針腳數與AMD主板提供的CPU插口不兼容,就是說如果使用Intel的CPU根本就插不到AMD的主板中,所以裝機方案是整體性的,里面選擇的各個配件之間是有關聯的。
對于裝機工程師而言,他只知道組裝一臺電腦,需要相應的配件,但是具體使用什么樣的配件,還得由客戶說了算。也就是說裝機工程師只是負責組裝,而客戶負責選擇裝配所需要的具體的配件。因此,當裝機工程師為不同的客戶組裝電腦時,只需要根據客戶的裝機方案,去獲取相應的配件,然后組裝即可。
二、使用簡單工廠模式的解決方案
- 對于客戶,需要選擇CPU和主板,然后告訴工程師去組裝電腦
-
對于工程師,只知道CPU和主板的接口,不需要了解內部實現,我們使用簡單工程模式來實現
簡單工廠.png - 根據上圖,我們編寫源碼
public interface Cpu {
private calculate();
}
public class IntelCpu implements Cpu {
/**
* CPU的針腳數
*/
private int pins = 0;
public IntelCpu(int pins){
this.pins = pins;
}
@Override
public void calculate() {
// TODO Auto-generated method stub
System.out.println("Intel CPU的針腳數:" + pins);
}
}
public class IntelCpu implements Cpu {
/**
* CPU的針腳數
*/
private int pins = 0;
public IntelCpu(int pins){
this.pins = pins;
}
@Override
public void calculate() {
// TODO Auto-generated method stub
System.out.println("Intel CPU的針腳數:" + pins);
}
}
public interface Mainboard {
public void installCPU();
}
public class IntelMainboard implements Mainboard {
/**
* CPU插槽的孔數
*/
private int cpuHoles = 0;
/**
* 構造方法,傳入CPU插槽的孔數
* @param cpuHoles
*/
public IntelMainboard(int cpuHoles){
this.cpuHoles = cpuHoles;
}
@Override
public void installCPU() {
// TODO Auto-generated method stub
System.out.println("Intel主板的CPU插槽孔數是:" + cpuHoles);
}
}
public class AmdMainboard implements Mainboard {
/**
* CPU插槽的孔數
*/
private int cpuHoles = 0;
/**
* 構造方法,傳入CPU插槽的孔數
* @param cpuHoles
*/
public AmdMainboard(int cpuHoles){
this.cpuHoles = cpuHoles;
}
@Override
public void installCPU() {
// TODO Auto-generated method stub
System.out.println("AMD主板的CPU插槽孔數是:" + cpuHoles);
}
}
public class CpuFactory {
public static Cpu createCpu(int type){
Cpu cpu = null;
if(type == 1){
cpu = new IntelCpu(755);
}else if(type == 2){
cpu = new AmdCpu(938);
}
return cpu;
}
}
public class MainboardFactory {
public static Mainboard createMainboard(int type){
Mainboard mainboard = null;
if(type == 1){
mainboard = new IntelMainboard(755);
}else if(type == 2){
mainboard = new AmdMainboard(938);
}
return mainboard;
}
}
public class ComputerEngineer {
/**
* 定義組裝機需要的CPU
*/
private Cpu cpu = null;
/**
* 定義組裝機需要的主板
*/
private Mainboard mainboard = null;
public void makeComputer(int cpuType , int mainboard){
/**
* 組裝機器的基本步驟
*/
//1:首先準備好裝機所需要的配件
prepareHardwares(cpuType, mainboard);
//2:組裝機器
//3:測試機器
//4:交付客戶
}
private void prepareHardwares(int cpuType , int mainboard){
//這里要去準備CPU和主板的具體實現,為了示例簡單,這里只準備這兩個
//可是,裝機工程師并不知道如何去創建,怎么辦呢?
//直接找相應的工廠獲取
this.cpu = CpuFactory.createCpu(cpuType);
this.mainboard = MainboardFactory.createMainboard(mainboard);
//測試配件是否好用
this.cpu.calculate();
this.mainboard.installCPU();
}
}
public class Client {
public static void main(String[]args){
ComputerEngineer cf = new ComputerEngineer();
cf.makeComputer(1,1);
}
}
運行結果如下:
- 以上程序看起來實現了我們的需求,但有個問題,如果客戶選了Inter的Cpu和Amd的主板,那對于工程師來說,他只管組裝,但實際上這臺電腦是無法使用的,根本無法適配,這個問題我們應該如何去解決呢?
三、抽象工廠模式
每一個模式都是針對一定問題的解決方案。抽象工廠模式與工廠方法模式的最大區別就在于,工廠方法模式針對的是一個產品等級結構;而抽象工廠模式則需要面對多個產品等級結構。
在學習抽象工廠具體實例之前,應該明白兩個重要的概念:產品族和產品等級。
所謂產品族,是指位于不同產品等級結構中,功能相關聯的產品組成的家族。比如AMD的主板、芯片組、CPU組成一個家族,Intel的主板、芯片組、CPU組成一個家族。而這兩個家族都來自于三個產品等級:主板、芯片組、CPU。一個等級結構是由相同的結構的產品組成,示意圖如下:
顯然,每一個產品族中含有產品的數目,與產品等級結構的數目是相等的。產品的等級結構與產品族將產品按照不同方向劃分,形成一個二維的坐標系。橫軸表示產品的等級結構,縱軸表示產品族,上圖共有兩個產品族,分布于三個不同的產品等級結構中。只要指明一個產品所處的產品族以及它所屬的等級結構,就可以唯一的確定這個產品。
上面所給出的三個不同的等級結構具有平行的結構。因此,如果采用工廠方法模式,就勢必要使用三個獨立的工廠等級結構來對付這三個產品等級結構。由于這三個產品等級結構的相似性,會導致三個平行的工廠等級結構。隨著產品等級結構的數目的增加,工廠方法模式所給出的工廠等級結構的數目也會隨之增加。如下圖:
那么,是否可以使用同一個工廠等級結構來對付這些相同或者極為相似的產品等級結構呢?當然可以的,而且這就是抽象工廠模式的好處。同一個工廠等級結構負責三個不同產品等級結構中的產品對象的創建。
可以看出,一個工廠等級結構可以創建出分屬于不同產品等級結構的一個產品族中的所有對象。顯然,這時候抽象工廠模式比簡單工廠模式、工廠方法模式更有效率。對應于每一個產品族都有一個具體工廠。而每一個具體工廠負責創建屬于同一個產品族,但是分屬于不同等級結構的產品。
四、抽象工廠模式結構
抽象工廠模式是對象的創建模式,它是工廠方法模式的進一步推廣。
假設一個子系統需要一些產品對象,而這些產品又屬于一個以上的產品等級結構。那么為了將消費這些產品對象的責任和創建這些產品對象的責任分割開來,可以引進抽象工廠模式。這樣的話,消費產品的一方不需要直接參與產品的創建工作,而只需要向一個公用的工廠接口請求所需要的產品。
通過使用抽象工廠模式,可以處理具有相同(或者相似)等級結構中的多個產品族中的產品對象的創建問題。如下圖所示:
由于這兩個產品族的等級結構相同,因此使用同一個工廠族也可以處理這兩個產品族的創建問題,這就是抽象工廠模式。
根據產品角色的結構圖,就不難給出工廠角色的結構設計圖。
可以看出,每一個工廠角色都有兩個工廠方法,分別負責創建分屬不同產品等級結構的產品對象。
前面示例實現的CPU接口和CPU實現對象,主板接口和主板實現對象,都不需要變化。
前面示例中創建CPU的簡單工廠和創建主板的簡單工廠,都不再需要。
新加入的抽象工廠類和實現類:
public interface AbstractFactory {
/**
* 創建CPU對象
* @return CPU對象
*/
public Cpu createCpu();
/**
* 創建主板對象
* @return 主板對象
*/
public Mainboard createMainboard();
}
public class IntelFactory implements AbstractFactory {
@Override
public Cpu createCpu() {
// TODO Auto-generated method stub
return new IntelCpu(755);
}
@Override
public Mainboard createMainboard() {
// TODO Auto-generated method stub
return new IntelMainboard(755);
}
}
public class AmdFactory implements AbstractFactory {
@Override
public Cpu createCpu() {
// TODO Auto-generated method stub
return new IntelCpu(938);
}
@Override
public Mainboard createMainboard() {
// TODO Auto-generated method stub
return new IntelMainboard(938);
}
}
裝機工程師類跟前面的實現相比,主要的變化是:從客戶端不再傳入選擇CPU和主板的參數,而是直接傳入客戶已經選擇好的產品對象。這樣就避免了單獨去選擇CPU和主板所帶來的兼容性問題,客戶要選就是一套,就是一個系列。
public class ComputerEngineer {
/**
* 定義組裝機需要的CPU
*/
private Cpu cpu = null;
/**
* 定義組裝機需要的主板
*/
private Mainboard mainboard = null;
public void makeComputer(AbstractFactory af){
/**
* 組裝機器的基本步驟
*/
//1:首先準備好裝機所需要的配件
prepareHardwares(af);
//2:組裝機器
//3:測試機器
//4:交付客戶
}
private void prepareHardwares(AbstractFactory af){
//這里要去準備CPU和主板的具體實現,為了示例簡單,這里只準備這兩個
//可是,裝機工程師并不知道如何去創建,怎么辦呢?
//直接找相應的工廠獲取
this.cpu = af.createCpu();
this.mainboard = af.createMainboard();
//測試配件是否好用
this.cpu.calculate();
this.mainboard.installCPU();
}
}
客戶端:
public class Client {
public static void main(String[]args){
//創建裝機工程師對象
ComputerEngineer cf = new ComputerEngineer();
//客戶選擇并創建需要使用的產品對象
AbstractFactory af = new IntelFactory();
//告訴裝機工程師自己選擇的產品,讓裝機工程師組裝電腦
cf.makeComputer(af);
}
}
抽象工廠的功能是為一系列相關對象或相互依賴的對象創建一個接口。一定要注意,這個接口內的方法不是任意堆砌的,而是一系列相關或相互依賴的方法。比如上面例子中的主板和CPU,都是為了組裝一臺電腦的相關對象。不同的裝機方案,代表一種具體的電腦系列。
由于抽象工廠定義的一系列對象通常是相關或相互依賴的,這些產品對象就構成了一個產品族,也就是抽象工廠定義了一個產品族。
這就帶來非常大的靈活性,切換產品族的時候,只要提供不同的抽象工廠實現就可以了,也就是說現在是以一個產品族作為一個整體被切換。
在什么情況下應當使用抽象工廠模式
1.一個系統不應當依賴于產品類實例如何被創建、組合和表達的細節,這對于所有形態的工廠模式都是重要的。
2.這個系統的產品有多于一個的產品族,而系統只消費其中某一族的產品。
3.同屬于同一個產品族的產品是在一起使用的,這一約束必須在系統的設計中體現出來。(比如:Intel主板必須使用Intel CPU、Intel芯片組)
4.系統提供一個產品類的庫,所有的產品以同樣的接口出現,從而使客戶端不依賴于實現。
抽象工廠模式的起源
抽象工廠模式的起源或者最早的應用,是用于創建分屬于不同操作系統的視窗構建。比如:命令按鍵(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產品族中的產品。這就是抽象工廠模式的應用,抽象工廠模式的解決方案如下圖:
顯然,一個系統只能夠在某一個操作系統的視窗環境下運行,而不能同時在不同的操作系統上運行。所以,系統實際上只能消費屬于同一個產品族的產品。
在現代的應用中,抽象工廠模式的使用范圍已經大大擴大了,不再要求系統只能消費某一個產品族了。因此,可以不必理會前面所提到的原始用意。
抽象工廠模式的優點
分離接口和實現
客戶端使用抽象工廠來創建需要的對象,而客戶端根本就不知道具體的實現是誰,客戶端只是面向產品的接口編程而已。也就是說,客戶端從具體的產品實現中解耦。使切換產品族變得容易
因為一個具體的工廠實現代表的是一個產品族,比如上面例子的從Intel系列到AMD系列只需要切換一下具體工廠。
抽象工廠模式的缺點
- 不太容易擴展新的產品
如果需要給整個產品族添加一個新的產品,那么就需要修改抽象工廠,這樣就會導致修改所有的工廠實現類。