.NET设计模式(3): 抽象工厂模式
2010-05-09 17:18
260 查看
抽象工厂模式（Abstract Factory Pattern）
引入：
在前面介绍的两个创建型模式里面，我们解决的都是有关"new"的问题，用它们来避免显式指定类创建对象。我写的也非常简单易懂，相信看过的朋友们都应该对简单工厂模式、工厂方法模式的意图、所能解决的问题及适用情景有一定的了解了。但是若要达到灵活运用，什么时候用，怎样用合适还不是看一篇文章就能解决的问题。呵呵..这需要你对OO的理解程度，你的项目开发经验等等许多方面的积累。一起努力喔。。
好了，咱们言归正传，通过对这两个模式的了解，我们掌握一种思想，就是在创建一个对象时，需要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变动，项目的扩展。但是，我们在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时由于需求的变化，这“一系列相互依赖的对象”也要改变，如何应对这种变化呢？如何像简单工厂模式、工厂方法模式一样绕过常规的"new"，然后提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？可能有人会说，你也可以将这些对象一个一个通过工厂方法模式来解决呀？但是，我们试想，既然是一系列相互依赖的对象，它们是有联系的，每个对象都这样解决，你又如何来保证他们的联系呢？举一个例子：Windows桌面主题，当你更换一个桌面主题的时候，系统的开始按钮、任务栏、菜单栏、工具栏等等都变了，而且是一起变的，他们的色调都还很一致，难道类似这样的问题，怎么来解决呢？它的天敌就是抽象工厂模式。
意图：
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
参考者：
也就是该模式中的各个类或对象之间的关系：
抽象工厂（Abstract Factory)
声明生成一系列抽象产品的方法
具体工厂（Concrete Factory）
执行生成一系列抽象产品的方法，生成一系列具体的产品
抽象产品（Abstract Product）
为这一系列的某一种产品声明接口
具体产品（Product）
定义具体工厂生成的具体产品的对象，实现产品接口
客户（Client）
我们的应用程序客户端（不要理解成人），使用抽象产品和抽象工厂生成对象。
抽象工厂模式UML图
抽象工厂模式在生活中的实例
咱们继续拿怎么穿衣服来说明这个抽象工厂模式。
就拿你来说吧。工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。咱们假设一种情况(现实中是不存在的,要不然,没法进入共产主义了,但有利于说明抽象工厂模式)，在你的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用OO的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
分析：
要好好去读上面那个实例，虽然有点绕嘴，其实只要用心去读，分清了抽象工厂模式的各个角色，对理解设计模式是非常重要的。理解头绪，然后接合简单工厂模式、工厂方法模式对工厂家族的了解，再加上抽象工厂模式的意图，头脑中差不多有一个雏型了吧。好了，咱们一起来分析一下。。
先把各个角色揪出来。
抽象工厂：虚拟的衣柜，它只是个概念而已。在项目中可能是一个接口或抽象类，定义规则，取出上衣，裤子。
具体工厂：具体的存在的衣柜，它用于存放某一种成套的衣服，换句话说，这种成套的衣服都是从这个衣柜中取出的。在项
目中继承于抽象工厂，实现抽象工厂中的方法，取出具体产品，某一件上衣，某一条裤子。
抽象产品：虚拟的衣服，也只是个概念。在项目中可能是多个接口或抽象类，定义规则，有什么特性，起什么作用。
具体产品：具体的实际存在的产品，它指的就是用于组装成某一套衣服的某一件上衣或裤子。它继承自某一个抽象产品。实
现抽象产品中制定的规则，特性。
它们之间怎么联系呢？客户在用的时候，依赖的又是什么呢？
客户在要的时候，首先要说出你要的什么系列的衣服，然后根据它的要求生成一个具体工厂的实例，剩下的工作就都是这个倒霉的具体工厂了，它会根据自己的实现生成一个上衣，生成一个裤子，然后把它交给客户。客户在这一过程中并不知道具体工厂都做了什么。也就是说，客户只依赖于抽象工厂和抽象产品了。在初始化的时候会用到一次具体工厂类名，我们根据.NET特有的反射机制又可以把这个在客户端唯一的具体的非抽象类放到一个应用程序配置文件中，防止它变化。
这就符合了设计模式中的“开放--封闭”原则，依赖倒转原则，里氏代换原则等等。
具体代码如下：
抽象工厂角色：
1
namespace AbstractFactory
2
{
3
//抽象工厂类,
4
public abstract class AbstractClothes
5
{
6
//抽象方法:创建一个上衣
7
abstract public AbstractCoat CreateCoat();
8
//抽象方法:创建一个裤子
9
abstract public AbstractTrousers CreateTrousers();
10
}
11
}
12
抽象产品角色：
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
/// 抽象产品----上衣抽象类
5
/// </summary>
6
public abstract class AbstractCoat
7
{
8
//性别属性
9
public abstract bool Sex
10
{
11
get;
12
}
13
14
//样式属性
15
public abstract string Style
16
{
17
get;
18
}
19
}
20
21
/**//// <summary>
22
/// 抽象产品----裤子抽象类
23
/// </summary>
24
public abstract class AbstractTrousers
25
{
26
//性别属性
27
public abstract bool Sex
28
{
29
get;
30
}
31
32
//样式属性
33
public abstract string Style
34
{
35
get;
36
}
37
}
38
}
39
具体工厂角色：
具体产品角色：（注意：我并没有把所有的具体产品类都列出来，由于简单，可以推想出剩余的产品类，详见附件）
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
/// 时尚男性上衣
5
/// </summary>
6
public class CoatA:AbstractFactory.AbstractCoat
7
{
8
private bool sex = true;
9
private string style = "时尚";
10
/**//// <summary>
11
/// 重写基类的Sex属性
12
/// </summary>
13
public override bool Sex
14
{
15
get
16
{
17
return sex;
18
}
19
}
20
21
/**//// <summary>
22
/// 重写基类的Style属性
23
/// </summary>
24
public override string Style
25
{
26
get
27
{
28
return style;
29
}
30
}
31
}
32
33
/**//// <summary>
34
/// 时尚男性裤子
35
/// </summary>
36
public class TrousersA : AbstractTrousers
37
{
38
private bool sex = true;
39
private string style = "时尚";
40
public override bool Sex
41
{
42
get
43
{
44
return sex;
45
}
46
}
47
public override string Style
48
{
49
get
50
{
51
return style;
52
}
53
}
54
}
55
}
客户端代码：
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
/// 创建衣服类
5
/// </summary>
6
public class CreateClothes
7
{
8
private AbstractCoat myCoat;
9
private AbstractTrousers myTrousers;
10
public CreateClothes(AbstractClothes clothes)
11
{
12
myCoat = clothes.CreateCoat();
13
myTrousers = clothes.CreateTrousers();
14
}
15
16
public void ShowMyClothes()
17
{
18
Console.WriteLine("My Clothes:");
19
string sex= myCoat.Sex ? "男" : "女";
20
//Console.WriteLine("Coat:{0} {1}", myCoat.Sex ? "男" : "女", myCoat.Style);
21
Console.WriteLine("Coat:{0} {1}", sex, myCoat.Style);
22
sex=myTrousers.Sex?"男":"女";
23
Console.WriteLine("Trousers:{0} {1}", sex, myTrousers.Style);
24
}
25
}
26
27
28
public class Client
29
{
30
static void Main(string[] args)
31
{
32
//创建一个工厂类的实例
33
string assemblyName = ConfigurationManager.AppSettings["assemblyName"];
34
string fullTypeName =string.Concat( ConfigurationManager.AppSettings["nameSpaceName"] ,".", ConfigurationManager.AppSettings["typename"]);
35
36
AbstractClothes factory = (AbstractClothes)Assembly.Load(assemblyName).CreateInstance(fullTypeName);
37
CreateClothes clothes = new CreateClothes(factory);
38
clothes.ShowMyClothes();
39
Console.Read();
40
}
41
}
42
}
43
app.config文件
1
<configuration>
2
<appSettings>
3
<!--一般情况下只需改第三个"typename"就行了,具体工厂类 -->
4
<add key="assemblyName" value="ConcreteFactory"/>
5
<add key="nameSpaceName" value="AbstractFactory"/>
6
<add key="typename" value="FashionManClothes"/>
7
</appSettings>
8
</configuration>
这样，代码就完成了。
小结一下：
抽象工厂模式堪称gof23种设计模式精典模式之一，它能够解决诸如：通过显示指定类创建对象，紧耦合，对对象表示或实现的依赖等等一些问题，有关设计模式的设计原则，所能解决的问题，详见OO与设计模式的原则、目标 。
抽象工厂模式适用于对“一系列相互依赖的对象”的创建工作，这些对象是相互依赖的，是有联系的。如果仅为一个对象的创建则用简单工厂模式或工厂方法模式完全可以实现，没有必要用抽象工厂模式。
由于抽象工厂模式的客户端只依赖于抽象工厂，抽象产品，在初始化过程中仅用到一次具体工厂我们又把它放在了app.config中了，完全依赖接口，这样不仅在系统的扩展性方面好，而且可以提高团队开发效率。两个团队只要彼此了解定义的接口，抽象类，可以并行开发。举个例子，就拿博客园来说吧，我们在用自己的博客空间时，可以随时的换皮肤，这个换皮肤是不是典型的抽象工厂模式吗？如果是，它的各个角色又是什么呢？我认为是的。换一下皮肤，你博客页面上的各个样式都变了，而且这里各个样式都同属于你选定的这一个皮肤。而每个样式都又是独立的，它们组合起来就成了一款皮肤。我们来揪出来各个角色。
抽象工厂：皮肤
抽象产品：样式
具体工厂：某一款皮肤，皮肤名即为具体工厂的类名
具体产品：某一个样式。
虽然不存在这样的接口与类，但是它确实是抽象工厂模式的一个应用。抽象工厂制定都有哪些样式名，而具体工厂来实现这些样式名中的样式，而具体工厂中用到的各个样式都是一个具体产品。这也是我的理解，如兄弟们有不同的见解，欢迎发表意见，共同探讨。
确定过各个角色之后，就可以说一下为什么提高效率了。不论dudu在设计博客园时用什么工具或语言，它与泸江博客只要约定好所有用到的样式名就可以了。而泸江博客就可以根据要求单独去做每一款皮肤了。
优点：
隔离了具体类的生成，客户不需要知道怎样生成了每一个具体产品，什么时间生成的。它将客户与具体的类分离，依赖于抽象类，耦合性低。
一个产品族中的多个对象被设计成一起工作，它能够保证客户端始终只使用一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是非常实用的一种设计模式。
它有利于更换产品系列，由于客户端只依赖于抽象类，具体类也被写到应用程序配置文件中，更换产品系列时，只须更改一下具体工厂名就行了。
[b]缺点：[/b]
难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。
[b]应用情景：[/b]
同一个产品族的产品在一起使用时，而且它们之间是相互依赖的，不可分离
系统需要由相互关联的多个对象来构成
你想提供一组对象而不显示它们的实现过程，只显示它们的接口
系统不应当依赖某一些具体产品类。
[b]应用场景举例：[/b]
游戏开发中的多风格系列场景
系统更改皮肤
支持多种观感标准的用户界面工具箱（Kit）。
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
///时尚男装
5
/// </summary>
6
public class FashionManClothes:AbstractClothes
7
{
8
public override AbstractFactory.AbstractCoat CreateCoat()
9
{
10
return new CoatA();
11
}
12
13
public override AbstractTrousers CreateTrousers()
14
{
15
return new TrousersA();
16
}
17
}
18
19
/**//// <summary>
20
/// 时尚女装
21
/// </summary>
22
public class FashionWomanClothes : AbstractClothes
23
{
24
public override AbstractCoat CreateCoat()
25
{
26
return new CoatB();
27
//throw new Exception("The method or operation is not implemented.");
28
}
29
public override AbstractTrousers CreateTrousers()
30
{
31
return new TrousersB();
32
//throw new Exception("The method or operation is not implemented.");
33
}
34
}
35
}
引入：
在前面介绍的两个创建型模式里面，我们解决的都是有关"new"的问题，用它们来避免显式指定类创建对象。我写的也非常简单易懂，相信看过的朋友们都应该对简单工厂模式、工厂方法模式的意图、所能解决的问题及适用情景有一定的了解了。但是若要达到灵活运用，什么时候用，怎样用合适还不是看一篇文章就能解决的问题。呵呵..这需要你对OO的理解程度，你的项目开发经验等等许多方面的积累。一起努力喔。。
好了，咱们言归正传，通过对这两个模式的了解，我们掌握一种思想，就是在创建一个对象时，需要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变动，项目的扩展。但是，我们在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时由于需求的变化，这“一系列相互依赖的对象”也要改变，如何应对这种变化呢？如何像简单工厂模式、工厂方法模式一样绕过常规的"new"，然后提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？可能有人会说，你也可以将这些对象一个一个通过工厂方法模式来解决呀？但是，我们试想，既然是一系列相互依赖的对象，它们是有联系的，每个对象都这样解决，你又如何来保证他们的联系呢？举一个例子：Windows桌面主题，当你更换一个桌面主题的时候，系统的开始按钮、任务栏、菜单栏、工具栏等等都变了，而且是一起变的，他们的色调都还很一致，难道类似这样的问题，怎么来解决呢？它的天敌就是抽象工厂模式。
意图：
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
参考者：
也就是该模式中的各个类或对象之间的关系：
抽象工厂（Abstract Factory)
声明生成一系列抽象产品的方法
具体工厂（Concrete Factory）
执行生成一系列抽象产品的方法，生成一系列具体的产品
抽象产品（Abstract Product）
为这一系列的某一种产品声明接口
具体产品（Product）
定义具体工厂生成的具体产品的对象，实现产品接口
客户（Client）
我们的应用程序客户端（不要理解成人），使用抽象产品和抽象工厂生成对象。
抽象工厂模式UML图
抽象工厂模式在生活中的实例
咱们继续拿怎么穿衣服来说明这个抽象工厂模式。
就拿你来说吧。工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。咱们假设一种情况(现实中是不存在的,要不然,没法进入共产主义了,但有利于说明抽象工厂模式)，在你的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用OO的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
分析：
要好好去读上面那个实例，虽然有点绕嘴，其实只要用心去读，分清了抽象工厂模式的各个角色，对理解设计模式是非常重要的。理解头绪，然后接合简单工厂模式、工厂方法模式对工厂家族的了解，再加上抽象工厂模式的意图，头脑中差不多有一个雏型了吧。好了，咱们一起来分析一下。。
先把各个角色揪出来。
抽象工厂：虚拟的衣柜，它只是个概念而已。在项目中可能是一个接口或抽象类，定义规则，取出上衣，裤子。
具体工厂：具体的存在的衣柜，它用于存放某一种成套的衣服，换句话说，这种成套的衣服都是从这个衣柜中取出的。在项
目中继承于抽象工厂，实现抽象工厂中的方法，取出具体产品，某一件上衣，某一条裤子。
抽象产品：虚拟的衣服，也只是个概念。在项目中可能是多个接口或抽象类，定义规则，有什么特性，起什么作用。
具体产品：具体的实际存在的产品，它指的就是用于组装成某一套衣服的某一件上衣或裤子。它继承自某一个抽象产品。实
现抽象产品中制定的规则，特性。
它们之间怎么联系呢？客户在用的时候，依赖的又是什么呢？
客户在要的时候，首先要说出你要的什么系列的衣服，然后根据它的要求生成一个具体工厂的实例，剩下的工作就都是这个倒霉的具体工厂了，它会根据自己的实现生成一个上衣，生成一个裤子，然后把它交给客户。客户在这一过程中并不知道具体工厂都做了什么。也就是说，客户只依赖于抽象工厂和抽象产品了。在初始化的时候会用到一次具体工厂类名，我们根据.NET特有的反射机制又可以把这个在客户端唯一的具体的非抽象类放到一个应用程序配置文件中，防止它变化。
这就符合了设计模式中的“开放--封闭”原则，依赖倒转原则，里氏代换原则等等。
具体代码如下：
抽象工厂角色：
1
namespace AbstractFactory
2
{
3
//抽象工厂类,
4
public abstract class AbstractClothes
5
{
6
//抽象方法:创建一个上衣
7
abstract public AbstractCoat CreateCoat();
8
//抽象方法:创建一个裤子
9
abstract public AbstractTrousers CreateTrousers();
10
}
11
}
12
抽象产品角色：
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
/// 抽象产品----上衣抽象类
5
/// </summary>
6
public abstract class AbstractCoat
7
{
8
//性别属性
9
public abstract bool Sex
10
{
11
get;
12
}
13
14
//样式属性
15
public abstract string Style
16
{
17
get;
18
}
19
}
20
21
/**//// <summary>
22
/// 抽象产品----裤子抽象类
23
/// </summary>
24
public abstract class AbstractTrousers
25
{
26
//性别属性
27
public abstract bool Sex
28
{
29
get;
30
}
31
32
//样式属性
33
public abstract string Style
34
{
35
get;
36
}
37
}
38
}
39
具体工厂角色：
具体产品角色：（注意：我并没有把所有的具体产品类都列出来，由于简单，可以推想出剩余的产品类，详见附件）
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
/// 时尚男性上衣
5
/// </summary>
6
public class CoatA:AbstractFactory.AbstractCoat
7
{
8
private bool sex = true;
9
private string style = "时尚";
10
/**//// <summary>
11
/// 重写基类的Sex属性
12
/// </summary>
13
public override bool Sex
14
{
15
get
16
{
17
return sex;
18
}
19
}
20
21
/**//// <summary>
22
/// 重写基类的Style属性
23
/// </summary>
24
public override string Style
25
{
26
get
27
{
28
return style;
29
}
30
}
31
}
32
33
/**//// <summary>
34
/// 时尚男性裤子
35
/// </summary>
36
public class TrousersA : AbstractTrousers
37
{
38
private bool sex = true;
39
private string style = "时尚";
40
public override bool Sex
41
{
42
get
43
{
44
return sex;
45
}
46
}
47
public override string Style
48
{
49
get
50
{
51
return style;
52
}
53
}
54
}
55
}
客户端代码：
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
/// 创建衣服类
5
/// </summary>
6
public class CreateClothes
7
{
8
private AbstractCoat myCoat;
9
private AbstractTrousers myTrousers;
10
public CreateClothes(AbstractClothes clothes)
11
{
12
myCoat = clothes.CreateCoat();
13
myTrousers = clothes.CreateTrousers();
14
}
15
16
public void ShowMyClothes()
17
{
18
Console.WriteLine("My Clothes:");
19
string sex= myCoat.Sex ? "男" : "女";
20
//Console.WriteLine("Coat:{0} {1}", myCoat.Sex ? "男" : "女", myCoat.Style);
21
Console.WriteLine("Coat:{0} {1}", sex, myCoat.Style);
22
sex=myTrousers.Sex?"男":"女";
23
Console.WriteLine("Trousers:{0} {1}", sex, myTrousers.Style);
24
}
25
}
26
27
28
public class Client
29
{
30
static void Main(string[] args)
31
{
32
//创建一个工厂类的实例
33
string assemblyName = ConfigurationManager.AppSettings["assemblyName"];
34
string fullTypeName =string.Concat( ConfigurationManager.AppSettings["nameSpaceName"] ,".", ConfigurationManager.AppSettings["typename"]);
35
36
AbstractClothes factory = (AbstractClothes)Assembly.Load(assemblyName).CreateInstance(fullTypeName);
37
CreateClothes clothes = new CreateClothes(factory);
38
clothes.ShowMyClothes();
39
Console.Read();
40
}
41
}
42
}
43
app.config文件
1
<configuration>
2
<appSettings>
3
<!--一般情况下只需改第三个"typename"就行了,具体工厂类 -->
4
<add key="assemblyName" value="ConcreteFactory"/>
5
<add key="nameSpaceName" value="AbstractFactory"/>
6
<add key="typename" value="FashionManClothes"/>
7
</appSettings>
8
</configuration>
这样，代码就完成了。
小结一下：
抽象工厂模式堪称gof23种设计模式精典模式之一，它能够解决诸如：通过显示指定类创建对象，紧耦合，对对象表示或实现的依赖等等一些问题，有关设计模式的设计原则，所能解决的问题，详见OO与设计模式的原则、目标 。
抽象工厂模式适用于对“一系列相互依赖的对象”的创建工作，这些对象是相互依赖的，是有联系的。如果仅为一个对象的创建则用简单工厂模式或工厂方法模式完全可以实现，没有必要用抽象工厂模式。
由于抽象工厂模式的客户端只依赖于抽象工厂，抽象产品，在初始化过程中仅用到一次具体工厂我们又把它放在了app.config中了，完全依赖接口，这样不仅在系统的扩展性方面好，而且可以提高团队开发效率。两个团队只要彼此了解定义的接口，抽象类，可以并行开发。举个例子，就拿博客园来说吧，我们在用自己的博客空间时，可以随时的换皮肤，这个换皮肤是不是典型的抽象工厂模式吗？如果是，它的各个角色又是什么呢？我认为是的。换一下皮肤，你博客页面上的各个样式都变了，而且这里各个样式都同属于你选定的这一个皮肤。而每个样式都又是独立的，它们组合起来就成了一款皮肤。我们来揪出来各个角色。
抽象工厂：皮肤
抽象产品：样式
具体工厂：某一款皮肤，皮肤名即为具体工厂的类名
具体产品：某一个样式。
虽然不存在这样的接口与类，但是它确实是抽象工厂模式的一个应用。抽象工厂制定都有哪些样式名，而具体工厂来实现这些样式名中的样式，而具体工厂中用到的各个样式都是一个具体产品。这也是我的理解，如兄弟们有不同的见解，欢迎发表意见，共同探讨。
确定过各个角色之后，就可以说一下为什么提高效率了。不论dudu在设计博客园时用什么工具或语言，它与泸江博客只要约定好所有用到的样式名就可以了。而泸江博客就可以根据要求单独去做每一款皮肤了。
优点：
隔离了具体类的生成，客户不需要知道怎样生成了每一个具体产品，什么时间生成的。它将客户与具体的类分离，依赖于抽象类，耦合性低。
一个产品族中的多个对象被设计成一起工作，它能够保证客户端始终只使用一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是非常实用的一种设计模式。
它有利于更换产品系列，由于客户端只依赖于抽象类，具体类也被写到应用程序配置文件中，更换产品系列时，只须更改一下具体工厂名就行了。
[b]缺点：[/b]
难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。
[b]应用情景：[/b]
同一个产品族的产品在一起使用时，而且它们之间是相互依赖的，不可分离
系统需要由相互关联的多个对象来构成
你想提供一组对象而不显示它们的实现过程，只显示它们的接口
系统不应当依赖某一些具体产品类。
[b]应用场景举例：[/b]
游戏开发中的多风格系列场景
系统更改皮肤
支持多种观感标准的用户界面工具箱（Kit）。
1
namespace AbstractFactory
2
{
3
/**//// <summary>
4
///时尚男装
5
/// </summary>
6
public class FashionManClothes:AbstractClothes
7
{
8
public override AbstractFactory.AbstractCoat CreateCoat()
9
{
10
return new CoatA();
11
}
12
13
public override AbstractTrousers CreateTrousers()
14
{
15
return new TrousersA();
16
}
17
}
18
19
/**//// <summary>
20
/// 时尚女装
21
/// </summary>
22
public class FashionWomanClothes : AbstractClothes
23
{
24
public override AbstractCoat CreateCoat()
25
{
26
return new CoatB();
27
//throw new Exception("The method or operation is not implemented.");
28
}
29
public override AbstractTrousers CreateTrousers()
30
{
31
return new TrousersB();
32
//throw new Exception("The method or operation is not implemented.");
33
}
34
}
35
}
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- .NET设计模式（3）：抽象工厂模式（Abstract Factory）
- .NET设计模式(2):1.2 抽象工厂模式(Abstract Factory)
- .NET设计模式（3）：抽象工厂模式（Abstract Factory）（转）
- .NET设计模式(3): 抽象工厂模式
- .Net设计模式学习笔记（三）：抽象工厂模式（Abstract Factory）
- .NET设计模式-抽象工厂模式（Abstract Factory）
- .NET设计模式(3): 抽象工厂模式
- .NET设计模式：抽象工厂模式（Abstract Factory）
- .Net设计模式之抽象工厂模式（Abstract Factory）
- .Net设计模式之抽象工厂模式（转载）
- 【转载】.NET设计模式之抽象工厂模式（Abstract Factory）
- .NET设计模式(3): 抽象工厂模式
- .NET设计模式(2):1.2 抽象工厂模式(Abstract Factory)
- .NET设计模式（3）：抽象工厂模式（Abstract Factory）
- .NET设计模式（3）：抽象工厂模式（Abstract Factory）
- .NET设计模式之抽象工厂模式（Abstract Factory）
- .NET设计模式（3）：抽象工厂模式（Abstract Factory）
- .NET简谈设计模式之(抽象工厂模式)
- .NET设计模式(3): 抽象工厂模式
- .NET设计模式（3）：抽象工厂模式（Abstract Factory）