一、上篇回顧

上篇我們主要講述了簡單工廠模式和工廠模式。并且分析了每種模式的應(yīng)用場景和一些優(yōu)缺點(diǎn)，我們現(xiàn)在來回顧一下：

簡單工廠模式：一個工廠負(fù)責(zé)所有類型對象的創(chuàng)建，不支持無縫的新增新的類型對象的創(chuàng)建。

工廠模式：多個工廠負(fù)責(zé)多個類型對象的創(chuàng)建，每個工廠只負(fù)責(zé)具體類型對象的創(chuàng)建，支持無縫的新增類型對象的創(chuàng)建，需要實(shí)現(xiàn)工廠接口類和具體的類型對象類。

我們來簡單的對比下這2個模式的優(yōu)缺點(diǎn)：

模式名稱	優(yōu)點(diǎn)	缺點(diǎn)
簡單工廠模式	一個工廠負(fù)責(zé)所有對象的創(chuàng)建，簡單靈活	不符合高內(nèi)聚的原則，不支持無縫的擴(kuò)展
工廠模式	可以無縫的新增類型，每個工廠職責(zé)單一，符合高內(nèi)聚的原則	工廠類太多，難以維護(hù)。

工廠模式，很優(yōu)雅的解決了應(yīng)用程序使用對象時的無限new()的操作，同時降低了系統(tǒng)應(yīng)用之間的耦合性，提高了系統(tǒng)的可維護(hù)性和適應(yīng)性。

二、摘要

本文主要是針對創(chuàng)建型模式中的抽象工廠模式進(jìn)行講述，抽象工廠模式是在簡單工廠模式的基礎(chǔ)上擴(kuò)展而成的新模式，將簡單工廠中的對象的創(chuàng)建過程進(jìn)行了很優(yōu)雅的動態(tài)配置來完成無

縫的擴(kuò)展，當(dāng)然通過一些擴(kuò)展，可以構(gòu)建出可支持動態(tài)新增或者刪除對象的抽象工廠模式。本文將會給出具體的實(shí)現(xiàn)方案，相比工廠模式，抽象工廠模式是一個工廠負(fù)責(zé)多個對象的創(chuàng)建，返回

的具體的類型是這個對象的抽象類型。這樣，在客戶端引用的時候只需要使用這個工廠返回的對象類型，抽象工廠會自動根據(jù)對象的類型動態(tài)的創(chuàng)建這個類型對象的實(shí)例。大體的過程如下：

上面的圖片呢，主要是針對經(jīng)典的抽象工廠模式給出了一個實(shí)現(xiàn)草圖的模擬，而我們在實(shí)際的項(xiàng)目中可能并不希望給出這么多的抽象工廠工廠實(shí)現(xiàn)，我只想給出一個通用的抽象

工廠實(shí)現(xiàn)，通過靜態(tài)方法直接調(diào)用，返回我想要的對象類型的實(shí)例，而且這個對象類型是可以動態(tài)配置的，那么我們?nèi)绾巫龅侥兀窟@就是本篇需要討論的實(shí)現(xiàn)方案。本篇將會從

以下幾點(diǎn)進(jìn)行講述抽象工廠模式：

1、抽象工廠模式的簡單實(shí)例代碼-這里給出的是經(jīng)典的抽象工廠模式實(shí)例代碼。我們從經(jīng)典的實(shí)例代碼中可以看出這個工廠模式的一些缺點(diǎn)。

2、根據(jù)經(jīng)典工廠模式的缺點(diǎn)，我們給出改進(jìn)的方案，進(jìn)一步給出項(xiàng)目中可以使用的通用方案實(shí)現(xiàn)。

3、給出上篇中的通過委托來實(shí)現(xiàn)的工廠模式方案。

4、通過特性+反射的形式來動態(tài)的創(chuàng)建對象。

三、本文大綱

a、上篇回顧。

b、摘要。

c、本文大綱。

d、抽象工廠模式的特點(diǎn)及使用場景。

e、抽象工廠模式的實(shí)現(xiàn)方案。

f、抽象工廠模式使用總結(jié)。

g、系列進(jìn)度。

h、下篇預(yù)告。

四、抽象工廠模式的特點(diǎn)及使用場景

抽象工廠可以說是三類工廠模式中使用最廣泛的，也是最受大家喜愛的模式之一，因?yàn)槌橄蠊S模式解決了一系列相互依賴的對象或者有組合關(guān)系的對象的創(chuàng)建過程。舉個簡單的例子來

說，我們以電腦的顯卡和風(fēng)扇來說吧，我們知道顯卡一般在玩游戲的時候，由于渲染圖形會產(chǎn)生大量的熱量，如果沒有好的風(fēng)扇那么可能無法達(dá)到好的散熱的效果，這個時候我們可以把顯卡和

風(fēng)扇的創(chuàng)建放在一個抽象工廠中進(jìn)行創(chuàng)建，因?yàn)檫@2個對象是具有依賴關(guān)系的對象，那么我們來給出這個例子的完整實(shí)例代碼：

先看看2個對象類型的接口和抽象工廠的接口定義

///
/// 定義顯卡抽象對象接口
///
public interface IDisplayCard
{
}

///
/// 定義顯卡風(fēng)扇抽象對象接口
///
public interface IDisplayFan
{
}

///
/// 定義顯卡設(shè)備抽象工廠接口
///
public interface IAbstractDriveFactory
{
IDisplayCard CreateDisplayCard();

IDisplayFan CreateDisplayFan();
}

我們來看看具體類型的實(shí)現(xiàn)和抽象工廠的具體實(shí)現(xiàn)。

///
/// 定義華碩顯卡的具體對象
///
public class DisplayCardAsus : IDisplayCard
{
}

///
/// 華碩顯卡配套風(fēng)扇
///
public class DisplayFanAsus : IDisplayFan
{
}

///
/// 華碩顯卡具體實(shí)現(xiàn)工廠
///
public class DriveFactoryAsus : IAbstractDriveFactory
{
IDisplayCard CreateDisplayCardAsus()
{
return new DisplayCardAsus();
}

IDisplayFan CreateDisplayFanAsus()
{
return new DisplayFanAsus();
}
}

通過上面的代碼，我們給出了抽象工廠的一個經(jīng)典實(shí)例的實(shí)現(xiàn)方案，當(dāng)然這不是我們開發(fā)中使用的實(shí)際形式，那么實(shí)際我們在項(xiàng)目中如何使用這個抽象工廠模式呢？我們一般是改進(jìn)的方

案去使用這個抽象工廠模式，我們?nèi)绾胃倪M(jìn)呢？對于目前的，如果我不光創(chuàng)建顯卡設(shè)備和配套的風(fēng)扇設(shè)備，我還想創(chuàng)建其他的類型的東西，這時候可能我們定義的抽象工廠就無法滿足具有相互

依賴或者組合關(guān)系的對象類型實(shí)例的創(chuàng)建工作了，那么我們?nèi)绾胃倪M(jìn)呢，這就是下面要講述的幾類方案。

五、抽象工廠模式的實(shí)現(xiàn)方案

5.1、通過配置文件來實(shí)現(xiàn)

• 我們先給出基于上面的經(jīng)典抽象工廠的一個改進(jìn)的方案，可以支持動態(tài)配置的抽象工廠，一個工廠負(fù)責(zé)動態(tài)的創(chuàng)建一些列的可動態(tài)配置的對象列表，我們?nèi)绾巫瞿?，我想一提到配置。大家都知道要么是通過XML文件來實(shí)現(xiàn)或者是通過泛型集合來做。我們這里可以提供的方案是這樣的，通過工廠初始化時從配置文件中讀取配置項(xiàng)，構(gòu)造一個字典，然后從這個字典中查詢要創(chuàng)建的類型是否在字典中，如果在字典中存在則創(chuàng)建這個類型的對象，否則返回NULL，我們這里通過泛型來實(shí)現(xiàn)。
• 我們來看看具體的代碼實(shí)現(xiàn)吧：

///
/// 定義抽象工廠接口
///
public interface IAbstractFactory
{
///
/// 通用的泛型對象創(chuàng)建工廠
///
///
///
T Create();
}

給出具體的實(shí)現(xiàn)這個接口的抽象工廠類

///
/// 具體的通用工廠實(shí)現(xiàn)
///
public class AbstractFactory : IAbstractFactory
{
private static readonly IDictionary<Type, Type> instances = null;

public static AbstractFactory()
{
//從具體的配置項(xiàng)中讀取，從配置文件中讀取或者通過某個方法來硬編碼實(shí)現(xiàn)等。
//這里推薦的做飯是從配置文件中讀取。
instances = new Dictionary<Type, Type>();
instances.Add(Type.GetType(“”), Type.GetType(“”));
instances.Add(Type.GetType(“”), Type.GetType(“”));
}
public T Create()
{
if (!instances.ContainsKey(typeof(T)))
return default(T);

Type typeInstance = instances[typeof(T)];

T obj = (T)Activator.CreateInstance(typeInstance);

return obj;
}
}

• 通過上面給出的代碼，基本上可以滿足一般項(xiàng)目的需求，大家當(dāng)然有好的思路和建議也可以提出，給出更好的改進(jìn)方案，下面我給出大概的配置文件格式，其實(shí)就是父子級節(jié)點(diǎn)，父級節(jié)點(diǎn)是負(fù)責(zé)創(chuàng)建的工廠
• 類，那么這個父節(jié)點(diǎn)下的子節(jié)點(diǎn)就是工廠要創(chuàng)建的具體的對象類型。

上圖中描述的思路，我們大概知道了，對應(yīng)這樣的一個支持多個具有依賴關(guān)系或者組合關(guān)系的對象的動態(tài)抽象工廠的實(shí)現(xiàn)，那么如果我們想實(shí)現(xiàn)支持多個具有依賴關(guān)系或者組合

關(guān)系的不同的創(chuàng)建形式的通用創(chuàng)建工廠時，我們?nèi)绾蝸碜瞿?？同上面的思路，只不過我們外部需要再添加一個字典，負(fù)責(zé)類型和抽象工廠的映射，即抽象工廠可以創(chuàng)建的字典列

表及抽象工廠具體實(shí)例類型之間的鍵值對關(guān)系，或者通過配置文件來組織父子級的關(guān)系。我們大概的看下配置文件的組織吧：

<?xml version="1.0" encoding="utf-8" ?>

那么具體的抽象工廠的代碼又如何組織呢？如下形式：

///
/// 具體的通用工廠實(shí)現(xiàn)
///
public class AbstractFactory : IAbstractFactory
{
///
/// 工廠與工廠能夠創(chuàng)建的對象類型字典之間的映射字典
///
private static readonly IDictionary<Type, Dictionary<Type, Type>> typeMapper = null;
private Type factoryType = null;

public static AbstractFactory()
{
//從具體的配置項(xiàng)中讀取，從配置文件中讀取或者通過某個方法來硬編碼實(shí)現(xiàn)等。
//這里推薦的做飯是從配置文件中讀取。
//根據(jù)配置文件中的ObjectInstance 節(jié)點(diǎn)放在對應(yīng)的工廠下的字典中
//每個工廠節(jié)點(diǎn)FactorySection 就會創(chuàng)建一個字典，并且將這個工廠能夠創(chuàng)建的類型放在這個字典中
typeMapper = new Dictionary<Type, Dictionary<Type, Type>>();
}

public AbstractFactory(string typeName)
{
this.factoryType = Type.GetType(typeName);
}
public T Create()
{
if(typeMapper.ContainsKey(this.factoryType))
return default(T);

Dictionary<Type, Type> instances = typeMapper[this.factoryType];

if (!instances.ContainsKey(typeof(T)))
return default(T);

Type typeInstance = instances[typeof(T)];

T obj = (T)Activator.CreateInstance(typeInstance);

return obj;
}
}

通過上面的代碼我們就給出了一個通用的抽象工廠的可行的解決方案。

5.2、通過委托來實(shí)現(xiàn)工廠模式

我們先要定義一個委托：

public delegate string DelegateFunctionHandler(string userName);

基于這個委托的工廠實(shí)現(xiàn)方案

///
/// 具體的通用工廠實(shí)現(xiàn)
///
public class DegelateFactory
{
private DelegateFunctionHandler handler = null;

public static DelegateFunctionHandler Create()
{
if (handler == null)
handler = new DelegateFunctionHandler(this.Test);

return handler;
}

public string Test(string name)
{
return “Test!”;
}

}

工廠返回一個委托類型的對象，當(dāng)然我上面為了簡單給出的test方法其實(shí)就是工廠內(nèi)部的方法，當(dāng)然這里還可以進(jìn)行相應(yīng)的改進(jìn)，也可以通過配置文件來完成，通過配置文件把相應(yīng)相

應(yīng)的委托事件方法，通過配置來通過工廠動態(tài)的創(chuàng)建。下面給出個思路吧，具體的實(shí)現(xiàn)我就不貼出來了：

也希望大家給出更好的實(shí)現(xiàn)思路和方案。希望能多多的交流。

六、抽象工廠模式使用總結(jié)

通過上面的實(shí)現(xiàn)方式和思路，我們來對比一下抽象工廠、工廠模式、簡單工廠模式之間的差異和相同點(diǎn)。

相同點(diǎn)：

1、都是為客戶調(diào)用程序與具體的對象類型之間提供了一個解耦作用，這里怎么說呢？其實(shí)就是應(yīng)用程序不關(guān)心這個對象是怎么出來的，只關(guān)系如何使用這個對象，而且以后就算對象發(fā)生變化，那么也不需

要修改用戶應(yīng)用程序的代碼。

2、提高了程序的可維護(hù)性和低耦合性。

異同點(diǎn)：

1、簡單工廠模式：是簡單的一些列沒有任何依賴關(guān)系的對象的創(chuàng)建，內(nèi)部包含復(fù)雜的邏輯關(guān)系，一半是通過配置或者參數(shù)來進(jìn)行創(chuàng)建對象，適合對象類型不多，并且不會經(jīng)常新增的情況下。

工廠模式：每個工廠負(fù)責(zé)具體類型對象的創(chuàng)建，提供了可以動態(tài)新增產(chǎn)品類型的創(chuàng)建，并不需要修改現(xiàn)有的程序就可以無縫的新增產(chǎn)品類型。

抽象工廠模式：支持動態(tài)的新增對象類型和新增工廠類型，實(shí)現(xiàn)多種依賴關(guān)系的對象或者組合關(guān)系的創(chuàng)建，適合現(xiàn)有項(xiàng)目中的對象創(chuàng)建過程。

2、簡單工廠模式：內(nèi)部邏輯復(fù)雜，不符合高內(nèi)聚的原則。

工廠模式：每次新增一個對象類型，就必須新增一個對應(yīng)的創(chuàng)建工廠，無疑這是一個非常大的工作量。

抽象工廠模式：是在簡單工廠模式的基礎(chǔ)上經(jīng)過改進(jìn)具有前2個模式的優(yōu)點(diǎn)，又屏蔽了他們的一些缺點(diǎn)。

當(dāng)然我們在具體的項(xiàng)目中，還是需要具體的情況具體分析，一般情況下，我們對于這種數(shù)據(jù)庫平滑遷移時，簡單工廠可能比其他2類工廠更容易做，也很靈活。

七、系列進(jìn)度。

創(chuàng)建型

1、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-單件模式

2、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-工廠模式

3、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-抽象工廠模式

4、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-創(chuàng)建者模式

5、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-原型模式

結(jié)構(gòu)型

1、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-組合模式

2、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-外觀模式

3、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-適配器模式

4、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-橋模式

5、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-裝飾模式

6、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-享元模式

7、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-代理模式

行為型

1、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-命令模式

2、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-觀察者模式

3、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-策略模式

4、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-職責(zé)模式

5、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-模板模式

6、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-中介者模式

7、系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-解釋器模式

八、下篇預(yù)告。

下篇將會針對創(chuàng)建者模式進(jìn)行講述，該模式也是創(chuàng)建型模式中最復(fù)雜的設(shè)計(jì)模式之一，該 模式是對一個對象的各個創(chuàng)建部分進(jìn)行劃分，最后創(chuàng)建出完整的對象，當(dāng)然這里面的實(shí)現(xiàn)方式可以說還是

那幾類思路，我將會給出幾個方案的關(guān)鍵代碼，希望大家多提寶貴意見，錯誤之處還請指出，請大家繼續(xù)支持。
轉(zhuǎn)自：https://www.cnblogs.com/hegezhou_hot/archive/2010/12/01/1893388.html文章來源地址http://www.zghlxwxcb.cn/news/detail-691362.html

到了這里，關(guān)于系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式-抽象工廠模式的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！