.NET设计模式之简单工厂模式 （转载）

.NET设计模式(1): 简单工厂模式

文章来源：/article/4923305.html

最近一直在看设计模式，想把自己的学习笔记与大家分享一下，如果能帮助大家的话，我会非常高兴，同时也欢迎大家指出里面的不足。园子里其实关于此类文章已经很多了，如果dudu感觉放在首页欠妥的话，可以调一下。

简单工厂模式（Simple Factory Pattern）

介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导，所以我想有必要把它作为第一个讲一下。

引入：
我们在编程的时候，每当"new"一个对象之后，这个对象就依赖于这个类了。如果在后期的维护过程中由于某些原因需要修改一下这个类，则唯一的做法就是打开源代码，进行修改，修改所有与这个对象有关的操作。这对我们是非常不利的。
问题出来了：对象不能应对“具体实例化类型”的变化
解决思路：套用一下李建忠李老师的话，封装变化点，哪里变化，封装哪里。在这个例子中，要实例化的类变了，就将实例化这个操作封装起来，我们可以把"new"这个操作移交一个具体的类，由它去负责根据我们的条件创建具体类的实例，也就是下面要说的“简单工厂模式”。

[b]定义：
[/b]专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类或接口。简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。

意图：
提供一个类，由它负责根据一定的条件创建某一具体类的实例

[b]参与者： [/b]

工厂角色（Creator）
是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。
抽象产品角色（Product）
是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。
具体产品角色（Concrete Product）
继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。

[b]UML图：
[/b] public interface ICoat
5namespace SimpleFactory
2namespace SimpleFactory
2 class Client
5namespace FactoryMethod
2namespace FactoryMethod
2namespace FactoryMethod
2namespace FactoryMethod
2
客户端代码

1namespace FactoryMethod
2namespace 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>

这样，代码就完成了。

小结一下：
抽象工厂模式堪称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