——探索設(shè)計模式系列之三
Terrylee，
概述
在軟件系統(tǒng)中，經(jīng)常面臨著“一系列相互依賴的對象”的創(chuàng)建工作；同時由于需求的變化，往往存在著更多系列對象的創(chuàng)建工作。如何應(yīng)對這種變化？如何繞過常規(guī)的對象的創(chuàng)建方法（new），提供一種“封裝機(jī)制”來避免客戶程序和這種“多系列具體對象創(chuàng)建工作”的緊耦合？這就是我們要說的抽象工廠模式。
意圖
提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。
模型圖
邏輯模型：
物理模型：
生活中的例子
抽象工廠的目的是要提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而不需要指定它們具體的類。這種模式可以汽車制造廠所使用的金屬沖壓設(shè)備中找到。這種沖壓設(shè)備可以制造汽車車身部件。同樣的機(jī)械用于沖壓不同的車型的右邊車門、左邊車門、右前擋泥板、左前擋泥板和引擎罩等等。通過使用轉(zhuǎn)輪來改變沖壓盤，這個機(jī)械產(chǎn)生的具體類可以在三分鐘內(nèi)改變。
抽象工廠之新解
虛擬案例
中國企業(yè)需要一項簡單的財務(wù)計算：每月月底，財務(wù)人員要計算員工的工資。
員工的工資 = (基本工資 + 獎金 - 個人所得稅)。這是一個放之四海皆準(zhǔn)的運算法則。
為了簡化系統(tǒng)，我們假設(shè)員工基本工資總是4000美金。
中國企業(yè)獎金和個人所得稅的計算規(guī)則是:
獎金 = 基本工資(4000) * 10%
個人所得稅 = (基本工資 + 獎金) * 40%
我們現(xiàn)在要為此構(gòu)建一個軟件系統(tǒng)（代號叫Softo），滿足中國企業(yè)的需求。
案例分析
獎金(Bonus)、個人所得稅(Tax)的計算是Softo系統(tǒng)的業(yè)務(wù)規(guī)則(Service)。
工資的計算(Calculator)則調(diào)用業(yè)務(wù)規(guī)則(Service)來計算員工的實際工資。
工資的計算作為業(yè)務(wù)規(guī)則的前端(或者客戶端Client)將提供給最終使用該系統(tǒng)的用戶(財務(wù)人員)使用。
針對中國企業(yè)為系統(tǒng)建模
根據(jù)上面的分析，為Softo系統(tǒng)建模如下：
則業(yè)務(wù)規(guī)則Service類的代碼如下：
1using System;
2
3namespace ChineseSalary
4{
5 /**//// <summary>
6 /// 公用的常量
7 /// </summary>
8 public class Constant
9{
10 public static double BASE_SALARY = 4000;
11 }
12} 1using System;
2
3namespace ChineseSalary
4{
5 /**//// <summary>
6 /// 計算中國個人獎金
7 /// </summary>
8 public class ChineseBonus
9{
10 public double Calculate()
11{
12 return Constant.BASE_SALARY * 0.1;
13 }
14 }
15}
16
客戶端的調(diào)用代碼：
1using System;
2
3namespace ChineseSalary
4{
5 /**//// <summary>
6 /// 計算中國個人所得稅
7 /// </summary>
8 public class ChineseTax
9{
10 public double Calculate()
11{
12 return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1)) * 0.4;
13 }
14 }
15}
16
運行程序，輸入的結(jié)果如下：
Chinese Salary is：2640
針對美國企業(yè)為系統(tǒng)建模
為了拓展國際市場，我們要把該系統(tǒng)移植給美國公司使用。
美國企業(yè)的工資計算同樣是: 員工的工資 = 基本工資 + 獎金 - 個人所得稅。
但是他們的獎金和個人所得稅的計算規(guī)則不同于中國企業(yè):
美國企業(yè)獎金和個人所得稅的計算規(guī)則是:
獎金 = 基本工資 * 15 %
個人所得稅 = (基本工資 * 5% + 獎金 * 25%)
根據(jù)前面為中國企業(yè)建模經(jīng)驗，我們僅僅將ChineseTax、ChineseBonus修改為AmericanTax、AmericanBonus。 修改后的模型如下：
則業(yè)務(wù)規(guī)則Service類的代碼如下：
1using System;
2
3namespace AmericanSalary
4{
5 /**//// <summary>
6 /// 公用的常量
7 /// </summary>
8 public class Constant
9{
10 public static double BASE_SALARY = 4000;
11 }
12}
13
客戶端的調(diào)用代碼： 1using System;
2
3namespace AmericanSalary
4{
5 /**//// <summary>
6 /// 計算美國個人獎金
7 /// </summary>
8 public class AmericanBonus
9{
10 public double Calculate()
11{
12 return Constant.BASE_SALARY * 0.1;
13 }
14 }
15}
16 1using System;
2
3namespace AmericanSalary
4{
5 /**//// <summary>
6 /// 計算美國個人所得稅
7 /// </summary>
8 public class AmericanTax
9{
10 public double Calculate()
11{
12 return (Constant.BASE_SALARY + (Constant.BASE_SALARY * 0.1)) * 0.4;
13 }
14 }
15}
16
1
2using System;
3
4namespace AmericanSalary
5{
6 /**//// <summary>
7 /// 客戶端程序調(diào)用
8 /// </summary>
9 public class Calculator
10{
11 public static void Main(string[] args)
12{
13 AmericanBonus bonus = new AmericanBonus();
14 double bonusValue = bonus.Calculate();
15
16 AmericanTax tax = new AmericanTax();
17 double taxValue = tax.Calculate();
18
19 double salary = 4000 + bonusValue - taxValue;
20
21 Console.WriteLine("American Salary is：" + salary);
22 Console.ReadLine();
23 }
24 }
25}
26
運行程序，輸入的結(jié)果如下：
American Salary is：2640
整合成通用系統(tǒng)
讓我們回顧一下該系統(tǒng)的發(fā)展歷程：
最初，我們只考慮將Softo系統(tǒng)運行于中國企業(yè)。但隨著MaxDO公司業(yè)務(wù)向海外拓展， MaxDO需要將該系統(tǒng)移植給美國使用。
移植時，MaxDO不得不拋棄中國企業(yè)的業(yè)務(wù)規(guī)則類ChineseTax和ChineseBonus， 然后為美國企業(yè)新建兩個業(yè)務(wù)規(guī)則類: AmericanTax,AmericanBonus。最后修改了業(yè)務(wù)規(guī)則調(diào)用Calculator類。
結(jié)果我們發(fā)現(xiàn)：每當(dāng)Softo系統(tǒng)移植的時候，就拋棄原來的類。現(xiàn)在，如果中國聯(lián)想集團(tuán)要購買該系統(tǒng)，我們不得不再次拋棄AmericanTax,AmericanBonus，修改回原來的業(yè)務(wù)規(guī)則。
一個可以立即想到的做法就是在系統(tǒng)中保留所有業(yè)務(wù)規(guī)則模型，即保留中國和美國企業(yè)工資運算規(guī)則。
通過保留中國企業(yè)和美國企業(yè)的業(yè)務(wù)規(guī)則模型，如果該系統(tǒng)在美國企業(yè)和中國企業(yè)之間切換時，我們僅僅需要修改Caculator類即可。
讓移植工作更簡單
前面系統(tǒng)的整合問題在于：當(dāng)系統(tǒng)在客戶在美國和中國企業(yè)間切換時仍然需要修改Caculator代碼。
一個維護(hù)性良好的系統(tǒng)應(yīng)該遵循“開閉原則”。即：封閉對原來代碼的修改，開放對原來代碼的擴(kuò)展（如類的繼承，接口的實現(xiàn)）
我們發(fā)現(xiàn)不論是中國企業(yè)還是美國企業(yè)，他們的業(yè)務(wù)運規(guī)則都采用同樣的計算接口。 于是很自然地想到建立兩個業(yè)務(wù)接口類Tax，Bonus，然后讓AmericanTax、AmericanBonus和ChineseTax、ChineseBonus分別實現(xiàn)這兩個接口， 據(jù)此修正后的模型如下：
此時客戶端代碼如下： 1為業(yè)務(wù)規(guī)則增加工廠方法
2using System;
3
4namespace InterfaceSalary
5{
6 /**//// <summary>
7 /// 客戶端程序調(diào)用
8 /// </summary>
9 public class Calculator
10{
11 public static void Main(string[] args)
12{
13 Bonus bonus = new ChineseBonus();
14 double bonusValue = bonus.Calculate();
15
16 Tax tax = new ChineseTax();
17 double taxValue = tax.Calculate();
18
19 double salary = 4000 + bonusValue - taxValue;
20
21 Console.WriteLine("Chinaese Salary is：" + salary);
22 Console.ReadLine();
23 }
24 }
25}
26
然而，上面增加的接口幾乎沒有解決任何問題，因為當(dāng)系統(tǒng)的客戶在美國和中國企業(yè)間切換時Caculator代碼仍然需要修改。
只不過修改少了兩處，但是仍然需要修改ChineseBonus,ChineseTax部分。致命的問題是：我們需要將這個移植工作轉(zhuǎn)包給一個叫Hippo的軟件公司。 由于版權(quán)問題，我們并未提供Softo系統(tǒng)的源碼給Hippo公司，因此Hippo公司根本無法修改Calculator，導(dǎo)致實際上移植工作無法進(jìn)行。
為此，我們考慮增加一個工具類(命名為Factory)，代碼如下：
1using System;
2
3namespace FactorySalary
4{
5 /**//// <summary>
6 /// Factory類
7 /// </summary>
8 public class Factory
9{
10 public Tax CreateTax()
11{
12 return new ChineseTax();
13 }
14
15 public Bonus CreateBonus()
16{
17 return new ChineseBonus();
18 }
19 }
20}
21
修改后的客戶端代碼：
1
2using System;
3
4namespace FactorySalary
5{
6 /**//// <summary>
7 /// 客戶端程序調(diào)用
8 /// </summary>
9 public class Calculator
10{
11 public static void Main(string[] args)
12{
13 Bonus bonus = new Factory().CreateBonus();
14 double bonusValue = bonus.Calculate();
15
16 Tax tax = new Factory().CreateTax();
17 double taxValue = tax.Calculate();
18
19 double salary = 4000 + bonusValue - taxValue;
20
21 Console.WriteLine("Chinaese Salary is：" + salary);
22 Console.ReadLine();
23 }
24 }
25}
26
不錯，我們解決了一個大問題，設(shè)想一下：當(dāng)該系統(tǒng)從中國企業(yè)移植到美國企業(yè)時，我們現(xiàn)在需要做什么？
答案是: 對于Caculator類我們什么也不用做。我們需要做的是修改Factory類，修改結(jié)果如下：
1using System;
2
3namespace FactorySalary
4{
5 /**//// <summary>
6 /// Factory類
7 /// </summary>
8 public class Factory
9{
10 public Tax CreateTax()
11{
12 return new AmericanTax();
13 }
14
15 public Bonus CreateBonus()
16{
17 return new AmericanBonus();
18 }
19 }
20}
21
為系統(tǒng)增加抽象工廠方法
很顯然，前面的解決方案帶來了一個副作用：就是系統(tǒng)不但增加了新的類Factory，而且當(dāng)系統(tǒng)移植時，移植工作僅僅是轉(zhuǎn)移到Factory類上，工作量并沒有任何縮減，而且還是要修改系統(tǒng)的源碼。 從Factory類在系統(tǒng)移植時修改的內(nèi)容我們可以看出: 實際上它是專屬于美國企業(yè)或者中國企業(yè)的。名稱上應(yīng)該叫AmericanFactory,ChineseFactory更合適.
解決方案是增加一個抽象工廠類AbstractFactory，增加一個靜態(tài)方法，該方法根據(jù)一個配置文件(App.config或者Web.config) 一個項(比如factoryName)動態(tài)地判斷應(yīng)該實例化哪個工廠類，這樣，我們就把移植工作轉(zhuǎn)移到了對配置文件的修改。修改后的模型和代碼：
抽象工廠類的代碼如下：
配置文件： 1using System;
2using System.Reflection;
3
4namespace AbstractFactory
5{
6 /**//// <summary>
7 /// AbstractFactory類
8 /// </summary>
9 public abstract class AbstractFactory
10{
11 public static AbstractFactory GetInstance()
12{
13 string factoryName = Constant.STR_FACTORYNAME.ToString();
14
15 AbstractFactory instance;
16
17 if(factoryName == "ChineseFactory")
18 instance = new ChineseFactory();
19 else if(factoryName == "AmericanFactory")
20 instance = new AmericanFactory();
21 else
22 instance = null;
23
24 return instance;
25 }
26
27 public abstract Tax CreateTax();
28
29 public abstract Bonus CreateBonus();
30 }
31}
1<?xml version="1.0" encoding="utf-8" ?>
2<configuration>
3 <appSettings>
4 <add key="factoryName" value="AmericanFactory"></add>
5 </appSettings>
6</configuration>
7
采用上面的解決方案，當(dāng)系統(tǒng)在美國企業(yè)和中國企業(yè)之間切換時，我們需要做什么移植工作？
答案是: 我們僅僅需要修改配置文件，將factoryName的值改為American。
修改配置文件的工作很簡單，只要寫一篇幅配置文檔說明書提供給移植該系統(tǒng)的團(tuán)隊(比如Hippo公司) 就可以方便地切換使該系統(tǒng)運行在美國或中國企業(yè)。
最后的修正（不是最終方案）
前面的解決方案幾乎很完美，但是還有一點瑕疵，瑕疵雖小，但可能是致命的。
考慮一下，現(xiàn)在日本NEC公司決定購買該系統(tǒng)，NEC公司的工資的運算規(guī)則遵守的是日本的法律。如果采用上面的系統(tǒng)構(gòu)架，這個移植我們要做哪些工作呢?
1. 增加新的業(yè)務(wù)規(guī)則類JapaneseTax,JapaneseBonus分別實現(xiàn)Tax和Bonus接口。
2. 修改AbstractFactory的getInstance方法，增加else if(factoryName.equals("Japanese")){....
注意: 系統(tǒng)中增加業(yè)務(wù)規(guī)則類不是模式所能解決的，無論采用什么設(shè)計模式，JapaneseTax,JapaneseBonus總是少不了的。（即增加了新系列產(chǎn)品）
我們真正不能接受的是：我們?nèi)匀恍抟薷南到y(tǒng)中原來的類(AbstractFactory)。前面提到過該系統(tǒng)的移植工作，我們可能轉(zhuǎn)包給一個叫Hippo的軟件公司。 為了維護(hù)版權(quán)，未將該系統(tǒng)的源碼提供給Hippo公司，那么Hippo公司根本無法修改AbstractFactory，所以系統(tǒng)移植其實無從談起，或者說系統(tǒng)移植總要開發(fā)人員親自參與。
解決方案是將抽象工廠類中的條件判斷語句，用.NET中發(fā)射機(jī)制代替，修改如下：
這樣，在我們編寫的代碼中就不會出現(xiàn) 1using System;
2using System.Reflection;
3
4namespace AbstractFactory
5{
6 /**//// <summary>
7 /// AbstractFactory類
8 /// </summary>
9 public abstract class AbstractFactory
10{
11 public static AbstractFactory GetInstance()
12{
13 string factoryName = Constant.STR_FACTORYNAME.ToString();
14
15 AbstractFactory instance;
16
17 if(factoryName != "")
18 instance = (AbstractFactory)Assembly.Load(factoryName).CreateInstance(factoryName);
19 else
20 instance = null;
21
22 return instance;
23 }
24
25 public abstract Tax CreateTax();
26
27 public abstract Bonus CreateBonus();
28 }
29}
30
小結(jié)
最后那幅圖是最終版的系統(tǒng)模型圖。我們發(fā)現(xiàn)作為客戶端角色的Calculator僅僅依賴抽象類， 它不必去理解中國和美國企業(yè)具體的業(yè)務(wù)規(guī)則如何實現(xiàn)，Calculator面對的僅僅是業(yè)務(wù)規(guī)則接口Tax和Bonus。
Softo系統(tǒng)的實際開發(fā)的分工可能是一個團(tuán)隊專門做業(yè)務(wù)規(guī)則，另一個團(tuán)隊專門做前端的業(yè)務(wù)規(guī)則組裝。 抽象工廠模式有助于這樣的團(tuán)隊的分工: 兩個團(tuán)隊通訊的約定是業(yè)務(wù)接口，由抽象工廠作為紐帶粘合業(yè)務(wù)規(guī)則和前段調(diào)用，大大降低了模塊間的耦合性，提高了團(tuán)隊開發(fā)效率。
完完全全地理解抽象工廠模式的意義非常重大，可以說對它的理解是你對OOP理解上升到一個新的里程碑的重要標(biāo)志。 學(xué)會了用抽象工廠模式編寫框架類，你將理解OOP的精華:面向接口編程.。
應(yīng)對“新對象”
抽象工廠模式主要在于應(yīng)對“新系列”的需求變化。其缺點在于難于應(yīng)付“新對象”的需求變動。如果在開發(fā)中出現(xiàn)了新對象，該如何去解決呢？這個問題并沒有一個好的答案，下面我們看一下李建忠老師的回答：
“GOF《設(shè)計模式》中提出過一種解決方法，即給創(chuàng)建對象的操作增加參數(shù)，但這種做法并不能令人滿意。事實上，對于新系列加新對象，就我所知，目前還沒有完美的做法，只有一些演化的思路，這種變化實在是太劇烈了，因為系統(tǒng)對于新的對象是完全陌生的。”
實現(xiàn)要點
l 抽象工廠將產(chǎn)品對象的創(chuàng)建延遲到它的具體工廠的子類。
l 如果沒有應(yīng)對“多系列對象創(chuàng)建”的需求變化，則沒有必要使用抽象工廠模式，這時候使用簡單的靜態(tài)工廠完全可以。
l 系列對象指的是這些對象之間有相互依賴、或作用的關(guān)系，例如游戲開發(fā)場景中的“道路”與“房屋”的依賴，“道路”與“地道”的依賴。
l 抽象工廠模式經(jīng)常和工廠方法模式共同組合來應(yīng)對“對象創(chuàng)建”的需求變化。
l 通常在運行時刻創(chuàng)建一個具體工廠類的實例，這一具體工廠的創(chuàng)建具有特定實現(xiàn)的產(chǎn)品對象，為創(chuàng)建不同的產(chǎn)品對象，客戶應(yīng)使用不同的具體工廠。
l 把工廠作為單件，一個應(yīng)用中一般每個產(chǎn)品系列只需一個具體工廠的實例，因此，工廠通常最好實現(xiàn)為一個單件模式。
l 創(chuàng)建產(chǎn)品，抽象工廠僅聲明一個創(chuàng)建產(chǎn)品的接口，真正創(chuàng)建產(chǎn)品是由具體產(chǎn)品類創(chuàng)建的，最通常的一個辦法是為每一個產(chǎn)品定義一個工廠方法，一個具體的工廠將為每個產(chǎn)品重定義該工廠方法以指定產(chǎn)品，雖然這樣的實現(xiàn)很簡單，但它確要求每個產(chǎn)品系列都要有一個新的具體工廠子類，即使這些產(chǎn)品系列的差別很小。
優(yōu)點
l 分離了具體的類。抽象工廠模式幫助你控制一個應(yīng)用創(chuàng)建的對象的類，因為一個工廠封裝創(chuàng)建產(chǎn)品對象的責(zé)任和過程。它將客戶和類的實現(xiàn)分離，客戶通過他們的抽象接口操縱實例，產(chǎn)品的類名也在具體工廠的實現(xiàn)中被分離，它們不出現(xiàn)在客戶代碼中。
l 它使得易于交換產(chǎn)品系列。一個具體工廠類在一個應(yīng)用中僅出現(xiàn)一次——即在它初始化的時候。這使得改變一個應(yīng)用的具體工廠變得很容易。它只需改變具體的工廠即可使用不同的產(chǎn)品配置，這是因為一個抽象工廠創(chuàng)建了一個完整的產(chǎn)品系列，所以整個產(chǎn)品系列會立刻改變。
l 它有利于產(chǎn)品的一致性。當(dāng)一個系列的產(chǎn)品對象被設(shè)計成一起工作時，一個應(yīng)用一次只能使用同一個系列中的對象，這一點很重要，而抽象工廠很容易實現(xiàn)這一點。
缺點
l 難以支持新種類的產(chǎn)品。難以擴(kuò)展抽象工廠以生產(chǎn)新種類的產(chǎn)品。這是因為抽象工廠幾口確定了可以被創(chuàng)建的產(chǎn)品集合，支持新種類的產(chǎn)品就需要擴(kuò)展該工廠接口，這將涉及抽象工廠類及其所有子類的改變。
適用性
在以下情況下應(yīng)當(dāng)考慮使用抽象工廠模式：
l 一個系統(tǒng)不應(yīng)當(dāng)依賴于產(chǎn)品類實例如何被創(chuàng)建、組合和表達(dá)的細(xì)節(jié)，這對于所有形態(tài)的工廠模式都是重要的。
l 這個系統(tǒng)有多于一個的產(chǎn)品族，而系統(tǒng)只消費其中某一產(chǎn)品族。
l 同屬于同一個產(chǎn)品族的產(chǎn)品是在一起使用的，這一約束必須在系統(tǒng)的設(shè)計中體現(xiàn)出來。
l 系統(tǒng)提供一個產(chǎn)品類的庫，所有的產(chǎn)品以同樣的接口出現(xiàn)，從而使客戶端不依賴于實現(xiàn)。
應(yīng)用場景
l 支持多種觀感標(biāo)準(zhǔn)的用戶界面工具箱（Kit）。
l 游戲開發(fā)中的多風(fēng)格系列場景，比如道路，房屋，管道等。
l ……
總結(jié)
總之，抽象工廠模式提供了一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，運用抽象工廠模式的關(guān)鍵點在于應(yīng)對“多系列對象創(chuàng)建”的需求變化。一句話，學(xué)會了抽象工廠模式，你將理解OOP的精華：面向接口編程。
源程序下載：/Files/Terrylee/AbstractFactory.rar
參考文獻(xiàn)
http://blog.dreambrook.com
《Java與模式》
《設(shè)計模式》
《Design Patterns Explained》
