抽象工廠模式新解（Abstract Factory）

——探索設(shè)計(jì)模式系列之三

Terrylee，2005年12月12日

概述

在軟件系統(tǒng)中，經(jīng)常面臨著“一系列相互依賴的對(duì)象”的創(chuàng)建工作；同時(shí)由于需求的變化，往往存在著更多系列對(duì)象的創(chuàng)建工作。如何應(yīng)對(duì)這種變化？如何繞過(guò)常規(guī)的對(duì)象的創(chuàng)建方法（new），提供一種“封裝機(jī)制”來(lái)避免客戶程序和這種“多系列具體對(duì)象創(chuàng)建工作”的緊耦合？這就是我們要說(shuō)的抽象工廠模式。

意圖

提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無(wú)需指定它們具體的類。

模型圖

邏輯模型：

物理模型：

生活中的例子

抽象工廠的目的是要提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而不需要指定它們具體的類。這種模式可以汽車制造廠所使用的金屬?zèng)_壓設(shè)備中找到。這種沖壓設(shè)備可以制造汽車車身部件。同樣的機(jī)械用于沖壓不同的車型的右邊車門、左邊車門、右前擋泥板、左前擋泥板和引擎罩等等。通過(guò)使用轉(zhuǎn)輪來(lái)改變沖壓盤，這個(gè)機(jī)械產(chǎn)生的具體類可以在三分鐘內(nèi)改變。

抽象工廠之新解

虛擬案例

中國(guó)企業(yè)需要一項(xiàng)簡(jiǎn)單的財(cái)務(wù)計(jì)算：每月月底，財(cái)務(wù)人員要計(jì)算員工的工資。

員工的工資 = (基本工資 + 獎(jiǎng)金 - 個(gè)人所得稅)。這是一個(gè)放之四海皆準(zhǔn)的運(yùn)算法則。

為了簡(jiǎn)化系統(tǒng)，我們假設(shè)員工基本工資總是4000美金。

中國(guó)企業(yè)獎(jiǎng)金和個(gè)人所得稅的計(jì)算規(guī)則是:

         獎(jiǎng)金 = 基本工資(4000) * 10%

         個(gè)人所得稅 = (基本工資 + 獎(jiǎng)金) * 40%

我們現(xiàn)在要為此構(gòu)建一個(gè)軟件系統(tǒng)（代號(hào)叫Softo），滿足中國(guó)企業(yè)的需求。

案例分析

獎(jiǎng)金(Bonus)、個(gè)人所得稅(Tax)的計(jì)算是Softo系統(tǒng)的業(yè)務(wù)規(guī)則(Service)。

工資的計(jì)算(Calculator)則調(diào)用業(yè)務(wù)規(guī)則(Service)來(lái)計(jì)算員工的實(shí)際工資。

工資的計(jì)算作為業(yè)務(wù)規(guī)則的前端(或者客戶端Client)將提供給最終使用該系統(tǒng)的用戶(財(cái)務(wù)人員)使用。

針對(duì)中國(guó)企業(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    /// 計(jì)算中國(guó)個(gè)人獎(jiǎng)金
 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    /// 計(jì)算中國(guó)個(gè)人所得稅
 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

運(yùn)行程序，輸入的結(jié)果如下：

Chinese Salary is：2640

針對(duì)美國(guó)企業(yè)為系統(tǒng)建模

為了拓展國(guó)際市場(chǎng)，我們要把該系統(tǒng)移植給美國(guó)公司使用。

美國(guó)企業(yè)的工資計(jì)算同樣是: 員工的工資 = 基本工資 + 獎(jiǎng)金 - 個(gè)人所得稅。

但是他們的獎(jiǎng)金和個(gè)人所得稅的計(jì)算規(guī)則不同于中國(guó)企業(yè):

美國(guó)企業(yè)獎(jiǎng)金和個(gè)人所得稅的計(jì)算規(guī)則是:

        獎(jiǎng)金 = 基本工資 * 15 %

        個(gè)人所得稅 = (基本工資 * 5% + 獎(jiǎng)金 * 25%)  

根據(jù)前面為中國(guó)企業(yè)建模經(jīng)驗(yàn)，我們僅僅將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

 1using System;
 2
 3namespace AmericanSalary
 4{
 5    /**//// <summary>
 6    /// 計(jì)算美國(guó)個(gè)人獎(jiǎng)金
 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    /// 計(jì)算美國(guó)個(gè)人所得稅
 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

客戶端的調(diào)用代碼：

 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

運(yùn)行程序，輸入的結(jié)果如下：

American Salary is：2640

整合成通用系統(tǒng)

讓我們回顧一下該系統(tǒng)的發(fā)展歷程：

最初，我們只考慮將Softo系統(tǒng)運(yùn)行于中國(guó)企業(yè)。但隨著MaxDO公司業(yè)務(wù)向海外拓展， MaxDO需要將該系統(tǒng)移植給美國(guó)使用。

移植時(shí)，MaxDO不得不拋棄中國(guó)企業(yè)的業(yè)務(wù)規(guī)則類ChineseTax和ChineseBonus， 然后為美國(guó)企業(yè)新建兩個(gè)業(yè)務(wù)規(guī)則類: AmericanTax,AmericanBonus。最后修改了業(yè)務(wù)規(guī)則調(diào)用Calculator類。

結(jié)果我們發(fā)現(xiàn)：每當(dāng)Softo系統(tǒng)移植的時(shí)候，就拋棄原來(lái)的類?，F(xiàn)在，如果中國(guó)聯(lián)想集團(tuán)要購(gòu)買該系統(tǒng)，我們不得不再次拋棄AmericanTax,AmericanBonus，修改回原來(lái)的業(yè)務(wù)規(guī)則。

一個(gè)可以立即想到的做法就是在系統(tǒng)中保留所有業(yè)務(wù)規(guī)則模型，即保留中國(guó)和美國(guó)企業(yè)工資運(yùn)算規(guī)則。

通過(guò)保留中國(guó)企業(yè)和美國(guó)企業(yè)的業(yè)務(wù)規(guī)則模型，如果該系統(tǒng)在美國(guó)企業(yè)和中國(guó)企業(yè)之間切換時(shí)，我們僅僅需要修改Caculator類即可。

讓移植工作更簡(jiǎn)單

前面系統(tǒng)的整合問(wèn)題在于：當(dāng)系統(tǒng)在客戶在美國(guó)和中國(guó)企業(yè)間切換時(shí)仍然需要修改Caculator代碼。

一個(gè)維護(hù)性良好的系統(tǒng)應(yīng)該遵循“開(kāi)閉原則”。即：封閉對(duì)原來(lái)代碼的修改，開(kāi)放對(duì)原來(lái)代碼的擴(kuò)展（如類的繼承，接口的實(shí)現(xiàn)）

我們發(fā)現(xiàn)不論是中國(guó)企業(yè)還是美國(guó)企業(yè)，他們的業(yè)務(wù)運(yùn)規(guī)則都采用同樣的計(jì)算接口。 于是很自然地想到建立兩個(gè)業(yè)務(wù)接口類Tax，Bonus，然后讓AmericanTax、AmericanBonus和ChineseTax、ChineseBonus分別實(shí)現(xiàn)這兩個(gè)接口， 據(jù)此修正后的模型如下：

此時(shí)客戶端代碼如下：

 1
 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

為業(yè)務(wù)規(guī)則增加工廠方法

然而，上面增加的接口幾乎沒(méi)有解決任何問(wèn)題，因?yàn)楫?dāng)系統(tǒng)的客戶在美國(guó)和中國(guó)企業(yè)間切換時(shí)Caculator代碼仍然需要修改。

只不過(guò)修改少了兩處，但是仍然需要修改ChineseBonus,ChineseTax部分。致命的問(wèn)題是：我們需要將這個(gè)移植工作轉(zhuǎn)包給一個(gè)叫Hippo的軟件公司。 由于版權(quán)問(wèn)題，我們并未提供Softo系統(tǒng)的源碼給Hippo公司，因此Hippo公司根本無(wú)法修改Calculator，導(dǎo)致實(shí)際上移植工作無(wú)法進(jìn)行。

為此，我們考慮增加一個(gè)工具類(命名為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

不錯(cuò)，我們解決了一個(gè)大問(wèn)題，設(shè)想一下：當(dāng)該系統(tǒng)從中國(guó)企業(yè)移植到美國(guó)企業(yè)時(shí)，我們現(xiàn)在需要做什么？

答案是: 對(duì)于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)增加抽象工廠方法

很顯然，前面的解決方案帶來(lái)了一個(gè)副作用：就是系統(tǒng)不但增加了新的類Factory，而且當(dāng)系統(tǒng)移植時(shí)，移植工作僅僅是轉(zhuǎn)移到Factory類上，工作量并沒(méi)有任何縮減，而且還是要修改系統(tǒng)的源碼。 從Factory類在系統(tǒng)移植時(shí)修改的內(nèi)容我們可以看出: 實(shí)際上它是專屬于美國(guó)企業(yè)或者中國(guó)企業(yè)的。名稱上應(yīng)該叫AmericanFactory,ChineseFactory更合適.

解決方案是增加一個(gè)抽象工廠類AbstractFactory，增加一個(gè)靜態(tài)方法，該方法根據(jù)一個(gè)配置文件(App.config或者Web.config) 一個(gè)項(xiàng)(比如factoryName)動(dòng)態(tài)地判斷應(yīng)該實(shí)例化哪個(gè)工廠類，這樣，我們就把移植工作轉(zhuǎn)移到了對(duì)配置文件的修改。修改后的模型和代碼：

抽象工廠類的代碼如下：

 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)在美國(guó)企業(yè)和中國(guó)企業(yè)之間切換時(shí)，我們需要做什么移植工作？

答案是: 我們僅僅需要修改配置文件，將factoryName的值改為American。

修改配置文件的工作很簡(jiǎn)單，只要寫一篇幅配置文檔說(shuō)明書提供給移植該系統(tǒng)的團(tuán)隊(duì)(比如Hippo公司) 就可以方便地切換使該系統(tǒng)運(yùn)行在美國(guó)或中國(guó)企業(yè)。

最后的修正（不是最終方案）

前面的解決方案幾乎很完美，但是還有一點(diǎn)瑕疵，瑕疵雖小，但可能是致命的。

考慮一下，現(xiàn)在日本NEC公司決定購(gòu)買該系統(tǒng)，NEC公司的工資的運(yùn)算規(guī)則遵守的是日本的法律。如果采用上面的系統(tǒng)構(gòu)架，這個(gè)移植我們要做哪些工作呢?

1.      增加新的業(yè)務(wù)規(guī)則類JapaneseTax,JapaneseBonus分別實(shí)現(xiàn)Tax和Bonus接口。

2.      修改AbstractFactory的getInstance方法，增加else if(factoryName.equals("Japanese")){....

注意: 系統(tǒng)中增加業(yè)務(wù)規(guī)則類不是模式所能解決的，無(wú)論采用什么設(shè)計(jì)模式，JapaneseTax,JapaneseBonus總是少不了的。（即增加了新系列產(chǎn)品）

我們真正不能接受的是：我們?nèi)匀恍抟薷南到y(tǒng)中原來(lái)的類(AbstractFactory)。前面提到過(guò)該系統(tǒng)的移植工作，我們可能轉(zhuǎn)包給一個(gè)叫Hippo的軟件公司。 為了維護(hù)版權(quán)，未將該系統(tǒng)的源碼提供給Hippo公司，那么Hippo公司根本無(wú)法修改AbstractFactory，所以系統(tǒng)移植其實(shí)無(wú)從談起，或者說(shuō)系統(tǒng)移植總要開(kāi)發(fā)人員親自參與。

解決方案是將抽象工廠類中的條件判斷語(yǔ)句，用.NET中發(fā)射機(jī)制代替，修改如下：

 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

這樣，在我們編寫的代碼中就不會(huì)出現(xiàn)Chinese，American，Japanese等這樣的字眼了。

小結(jié)

最后那幅圖是最終版的系統(tǒng)模型圖。我們發(fā)現(xiàn)作為客戶端角色的Calculator僅僅依賴抽象類， 它不必去理解中國(guó)和美國(guó)企業(yè)具體的業(yè)務(wù)規(guī)則如何實(shí)現(xiàn)，Calculator面對(duì)的僅僅是業(yè)務(wù)規(guī)則接口Tax和Bonus。

Softo系統(tǒng)的實(shí)際開(kāi)發(fā)的分工可能是一個(gè)團(tuán)隊(duì)專門做業(yè)務(wù)規(guī)則，另一個(gè)團(tuán)隊(duì)專門做前端的業(yè)務(wù)規(guī)則組裝。 抽象工廠模式有助于這樣的團(tuán)隊(duì)的分工: 兩個(gè)團(tuán)隊(duì)通訊的約定是業(yè)務(wù)接口，由抽象工廠作為紐帶粘合業(yè)務(wù)規(guī)則和前段調(diào)用，大大降低了模塊間的耦合性，提高了團(tuán)隊(duì)開(kāi)發(fā)效率。

完完全全地理解抽象工廠模式的意義非常重大，可以說(shuō)對(duì)它的理解是你對(duì)OOP理解上升到一個(gè)新的里程碑的重要標(biāo)志。 學(xué)會(huì)了用抽象工廠模式編寫框架類，你將理解OOP的精華:面向接口編程.。

應(yīng)對(duì)“新對(duì)象”

抽象工廠模式主要在于應(yīng)對(duì)“新系列”的需求變化。其缺點(diǎn)在于難于應(yīng)付“新對(duì)象”的需求變動(dòng)。如果在開(kāi)發(fā)中出現(xiàn)了新對(duì)象，該如何去解決呢？這個(gè)問(wèn)題并沒(méi)有一個(gè)好的答案，下面我們看一下李建忠老師的回答：

“GOF《設(shè)計(jì)模式》中提出過(guò)一種解決方法，即給創(chuàng)建對(duì)象的操作增加參數(shù)，但這種做法并不能令人滿意。事實(shí)上，對(duì)于新系列加新對(duì)象，就我所知，目前還沒(méi)有完美的做法，只有一些演化的思路，這種變化實(shí)在是太劇烈了，因?yàn)橄到y(tǒng)對(duì)于新的對(duì)象是完全陌生的。”

實(shí)現(xiàn)要點(diǎn)

l         抽象工廠將產(chǎn)品對(duì)象的創(chuàng)建延遲到它的具體工廠的子類。

l         如果沒(méi)有應(yīng)對(duì)“多系列對(duì)象創(chuàng)建”的需求變化，則沒(méi)有必要使用抽象工廠模式，這時(shí)候使用簡(jiǎn)單的靜態(tài)工廠完全可以。

l         系列對(duì)象指的是這些對(duì)象之間有相互依賴、或作用的關(guān)系，例如游戲開(kāi)發(fā)場(chǎng)景中的“道路”與“房屋”的依賴，“道路”與“地道”的依賴。

l         抽象工廠模式經(jīng)常和工廠方法模式共同組合來(lái)應(yīng)對(duì)“對(duì)象創(chuàng)建”的需求變化。

l         通常在運(yùn)行時(shí)刻創(chuàng)建一個(gè)具體工廠類的實(shí)例，這一具體工廠的創(chuàng)建具有特定實(shí)現(xiàn)的產(chǎn)品對(duì)象，為創(chuàng)建不同的產(chǎn)品對(duì)象，客戶應(yīng)使用不同的具體工廠。

l         把工廠作為單件，一個(gè)應(yīng)用中一般每個(gè)產(chǎn)品系列只需一個(gè)具體工廠的實(shí)例，因此，工廠通常最好實(shí)現(xiàn)為一個(gè)單件模式。

l         創(chuàng)建產(chǎn)品，抽象工廠僅聲明一個(gè)創(chuàng)建產(chǎn)品的接口，真正創(chuàng)建產(chǎn)品是由具體產(chǎn)品類創(chuàng)建的，最通常的一個(gè)辦法是為每一個(gè)產(chǎn)品定義一個(gè)工廠方法，一個(gè)具體的工廠將為每個(gè)產(chǎn)品重定義該工廠方法以指定產(chǎn)品，雖然這樣的實(shí)現(xiàn)很簡(jiǎn)單，但它確要求每個(gè)產(chǎn)品系列都要有一個(gè)新的具體工廠子類，即使這些產(chǎn)品系列的差別很小。

優(yōu)點(diǎn)

l         分離了具體的類。抽象工廠模式幫助你控制一個(gè)應(yīng)用創(chuàng)建的對(duì)象的類，因?yàn)橐粋€(gè)工廠封裝創(chuàng)建產(chǎn)品對(duì)象的責(zé)任和過(guò)程。它將客戶和類的實(shí)現(xiàn)分離，客戶通過(guò)他們的抽象接口操縱實(shí)例，產(chǎn)品的類名也在具體工廠的實(shí)現(xiàn)中被分離，它們不出現(xiàn)在客戶代碼中。

l         它使得易于交換產(chǎn)品系列。一個(gè)具體工廠類在一個(gè)應(yīng)用中僅出現(xiàn)一次——即在它初始化的時(shí)候。這使得改變一個(gè)應(yīng)用的具體工廠變得很容易。它只需改變具體的工廠即可使用不同的產(chǎn)品配置，這是因?yàn)橐粋€(gè)抽象工廠創(chuàng)建了一個(gè)完整的產(chǎn)品系列，所以整個(gè)產(chǎn)品系列會(huì)立刻改變。

l         它有利于產(chǎn)品的一致性。當(dāng)一個(gè)系列的產(chǎn)品對(duì)象被設(shè)計(jì)成一起工作時(shí)，一個(gè)應(yīng)用一次只能使用同一個(gè)系列中的對(duì)象，這一點(diǎn)很重要，而抽象工廠很容易實(shí)現(xiàn)這一點(diǎn)。

缺點(diǎn)

l         難以支持新種類的產(chǎn)品。難以擴(kuò)展抽象工廠以生產(chǎn)新種類的產(chǎn)品。這是因?yàn)槌橄蠊S幾口確定了可以被創(chuàng)建的產(chǎn)品集合，支持新種類的產(chǎn)品就需要擴(kuò)展該工廠接口，這將涉及抽象工廠類及其所有子類的改變。

適用性

在以下情況下應(yīng)當(dāng)考慮使用抽象工廠模式：

l         一個(gè)系統(tǒng)不應(yīng)當(dāng)依賴于產(chǎn)品類實(shí)例如何被創(chuàng)建、組合和表達(dá)的細(xì)節(jié)，這對(duì)于所有形態(tài)的工廠模式都是重要的。

l         這個(gè)系統(tǒng)有多于一個(gè)的產(chǎn)品族，而系統(tǒng)只消費(fèi)其中某一產(chǎn)品族。

l         同屬于同一個(gè)產(chǎn)品族的產(chǎn)品是在一起使用的，這一約束必須在系統(tǒng)的設(shè)計(jì)中體現(xiàn)出來(lái)。

l         系統(tǒng)提供一個(gè)產(chǎn)品類的庫(kù)，所有的產(chǎn)品以同樣的接口出現(xiàn)，從而使客戶端不依賴于實(shí)現(xiàn)。

應(yīng)用場(chǎng)景

l         支持多種觀感標(biāo)準(zhǔn)的用戶界面工具箱（Kit）。

l         游戲開(kāi)發(fā)中的多風(fēng)格系列場(chǎng)景，比如道路，房屋，管道等。

l         ……

總結(jié)

總之，抽象工廠模式提供了一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，運(yùn)用抽象工廠模式的關(guān)鍵點(diǎn)在于應(yīng)對(duì)“多系列對(duì)象創(chuàng)建”的需求變化。一句話，學(xué)會(huì)了抽象工廠模式，你將理解OOP的精華：面向接口編程。

 _____________________________________________________________________________

源程序下載：/Files/Terrylee/AbstractFactory.rar

參考文獻(xiàn)

http://blog.

《Java與模式》

《設(shè)計(jì)模式》

《Design  Patterns  Explained》