收藏别人整理的 设计模式（设计模式(3): 抽象工厂模式 ）

.NET设计模式(3): 抽象工厂模式

抽象工厂模式（Abstract Factory Pattern）

引入：

在前面介绍的两个创建型模式里面，我们解决的都是有关"new"的问题，用它们来避免显式指定类创建对象。我写的也非常简单易懂，相信看过的朋友们都应该对简单工厂模式、工厂方法模式的意图、所能解决的问题及适用情景有一定的了解了。但是若要达到灵活运用，什么时候用，怎样用合适还不是看一篇文章就能解决的问题。呵呵..这需要你对OO的理解程度，你的项目开发经验等等许多方面的积累。一起努力喔。。

好了，咱们言归正传，通过对这两个模式的了解，我们掌握一种思想，就是在创建一个对象时，需要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变动，项目的扩展。但是，我们在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时由于需求的变化，这“一系列相互依赖的对象”也要改变，如何应对这种变化呢？如何像简单工厂模式、工厂方法模式一样绕过常规的"new"，然后提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？可能有人会说，你也可以将这些对象一个一个通过工厂方法模式来解决呀？但是，我们试想，既然是一系列相互依赖的对象，它们是有联系的，每个对象都这样解决，你又如何来保证他们的联系呢？举一个例子：Windows桌面主题，当你更换一个桌面主题的时候，系统的开始按钮、任务栏、菜单栏、工具栏等等都变了，而且是一起变的，他们的色调都还很一致，难道类似这样的问题，怎么来解决呢？它的天敌就是抽象工厂模式。

意图：

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

参考者：

也就是该模式中的各个类或对象之间的关系：

抽象工厂（Abstract Factory)

声明生成一系列抽象产品的方法

具体工厂（Concrete Factory）

执行生成一系列抽象产品的方法，生成一系列具体的产品

抽象产品（Abstract Product）

为这一系列的某一种产品声明接口

具体产品（Product）

定义具体工厂生成的具体产品的对象，实现产品接口

客户（Client）

我们的应用程序客户端（不要理解成人），使用抽象产品和抽象工厂生成对象。

抽象工厂模式UML图

namespace AbstractFactory

2

抽象产品角色：

1namespace AbstractFactory

2

具体工厂角色：

1namespace AbstractFactory

2namespace AbstractFactory

2namespace AbstractFactory

2

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>

这样，代码就完成了。

[b]小结一下：

抽象工厂模式堪称gof23种设计模式精典模式之一，它能够解决诸如：通过显示指定类创建对象，紧耦合，对对象表示或实现的依赖等等一些问题，有关设计模式的设计原则，所能解决的问题，详见OO与设计模式的原则、目标 。

抽象工厂模式适用于对“一系列相互依赖的对象”的创建工作，这些对象是相互依赖的，是有联系的。如果仅为一个对象的创建则用简单工厂模式或工厂方法模式完全可以实现，没有必要用抽象工厂模式。

由于抽象工厂模式的客户端只依赖于抽象工厂，抽象产品，在初始化过程中仅用到一次具体工厂我们又把它放在了app.config中了，完全依赖接口，这样不仅在系统的扩展性方面好，而且可以提高团队开发效率。两个团队只要彼此了解定义的接口，抽象类，可以并行开发。举个例子，就拿博客园来说吧，我们在用自己的博客空间时，可以随时的换皮肤，这个换皮肤是不是典型的抽象工厂模式吗？如果是，它的各个角色又是什么呢？我认为是的。换一下皮肤，你博客页面上的各个样式都变了，而且这里各个样式都同属于你选定的这一个皮肤。而每个样式都又是独立的，它们组合起来就成了一款皮肤。我们来揪出来各个角色。

抽象工厂：皮肤

抽象产品：样式

具体工厂：某一款皮肤，皮肤名即为具体工厂的类名

具体产品：某一个样式。

虽然不存在这样的接口与类，但是它确实是抽象工厂模式的一个应用。抽象工厂制定都有哪些样式名，而具体工厂来实现这些样式名中的样式，而具体工厂中用到的各个样式都是一个具体产品。这也是我的理解，如兄弟们有不同的见解，欢迎发表意见，共同探讨。

确定过各个角色之后，就可以说一下为什么提高效率了。不论dudu在设计博客园时用什么工具或语言，它与泸江博客只要约定好所有用到的样式名就可以了。而泸江博客就可以根据要求单独去做每一款皮肤了。

优点：

隔离了具体类的生成，客户不需要知道怎样生成了每一个具体产品，什么时间生成的。它将客户与具体的类分离，依赖于抽象类，耦合性低。

一个产品族中的多个对象被设计成一起工作，它能够保证客户端始终只使用一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是非常实用的一种设计模式。

它有利于更换产品系列，由于客户端只依赖于抽象类，具体类也被写到应用程序配置文件中，更换产品系列时，只须更改一下具体工厂名就行了。

[b]缺点：[/b]

难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。

[b]应用情景：[/b]

同一个产品族的产品在一起使用时，而且它们之间是相互依赖的，不可分离

系统需要由相互关联的多个对象来构成

你想提供一组对象而不显示它们的实现过程，只显示它们的接口

系统不应当依赖某一些具体产品类。

[b]应用场景举例：[/b]

游戏开发中的多风格系列场景

系统更改皮肤

支持多种观感标准的用户界面工具箱（Kit）。

[b]参考资料 [/b]

《深入浅出设计模式(C#/Java版) 》 清华大学出版社

MSDN Webcast C#面向对象设计模式纵横谈 李建忠老师

源程序下载：

http://files.cnblogs.com/anlyren/AbstractFactory.rar