C__工厂模式

最近一直在看设计模式，想把自己的学习笔记与大家分享一下，如果能帮助大家的话，我会非常高兴，同时也欢迎大家指出里面的不足。

园子里其实关于此类文章已经很多了，如果dudu感觉放在首页欠妥的话，可以调一下。

简单工厂模式（Simple Factory Pattern）介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。

因为它至少不是Gof23种设计模式之一。

但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导，所以我想有必要把它作为第一个讲一下。

引入：我们在编程的时候，每当"new"一个对象之后，这个对象就依赖于这个类了。

如果在后期的维护过程中由于某些原因需要修改一下这个类，则唯一的做法就是打开源代码，进行修改，修改所有与这个对象有关的操作。

这对我们是非常不利的。

问题出来了：对象不能应对“具体实例化类型”的变化解决思路：套用一下李建忠李老师的话，封装变化点，哪里变化，封装哪里。

在这个例子中，要实例化的类变了，就将实例化这个操作封装起来，我们可以把"new"这个操作移交一个具体的类，由它去负责根据我们的条件创建具体类的实例，也就是下面要说的“简单工厂模式”。

定义：专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类或接口。

简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。

意图：提供一个类，由它负责根据一定的条件创建某一具体类的实例参与者：∙工厂角色（Creator）是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。

工厂类可以被外界直接调用，创建所需的产品对象。

∙抽象产品角色（Product）是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。

具体产品角色（Concrete Product）继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。

工厂类返回的都是该角色的某一具体产品。

UML图：现实生活中例子：每次参加不同的聚会或者与不同的人见面，可能穿的衣服是不一样的，比如，你今天上午要与你的一个新客户见面，你可能会对你的老婆说：老婆，给拿件商务装（参数），我要去见我的一个客户，你老婆（工厂类）接到你的请求（商务装参数）后，从衣柜中取出一件商务装（具体产品），交给你。

整个过程就完成了。

分析：你可能根据不同的条件，要的衣服是不一样的，但要的衣服都是已经在你的衣柜中存在的。

并且，每件上衣它们都属于同一种抽象，即它们可以从一个抽象类或接口中继承，这此衣服各自都有一定特征，这些都是条件。

然后你要的时候，就可以向你老婆说一种特征，她就会根据这个特征为你服务了。

这就是典型的简单工厂模式的应用。

抽象产品类代码1///<summary>2///抽象产品类:上衣3///</summary>4public interface ICoat5 {6void GetYourCoat();7 }非常简单，是吧？这里我只是举一个仅仅能说明问题的例子，在具体的项目中，可能是很复杂的哦。

具体产品类代码1namespace SimpleFactory2{3///<summary>4///具体产品类：商务上衣5///</summary>6public class BusinessCoat:ICoat7 {8public void GetYourCoat()9 {10 Console.WriteLine("商务上衣");11 }12 }1314///<summary>15///具体产品类：时尚上衣16///</summary>17public class FashionCoat : ICoat18 {19///<summary>20///实现ICoat中定义的方法21///</summary>22///<returns></returns>23public void GetYourCoat()24 {25 Console.WriteLine("时尚上衣");26 }27 }28}简单工厂模式中最核心的部分：工厂类1namespace SimpleFactory2{3///<summary>4///简单工厂模式中的核心部分:工厂类5///</summary>6public class Factory7 {8public ICoat CreateCoat(string styleName)9 {10switch (styleName.Trim().ToLower())11 {12case"business":13return new BusinessCoat();14case"fashion":15return new FashionCoat();16default :17throw new Exception("还没有你要的那种衣服");18 }19 }20 }21}再看一下客户在调用的时候的代码1///<summary>2///客户类3///</summary>4class Client5 {6static void Main(string[] args)7 {//主函数中声明接口变量，工厂类对象，通过工厂类对象调用接口方法，8 ICoat food;9try10 {11 Factory factory = new Factory();//工厂类对象1213 Console.Write("我要的是时尚上衣\t");14 food = factory.CreateCoat("fashion");//工厂类对象调用接口方法15 food.GetYourCoat();1617 }18catch (Exception ex)19 {20 Console.WriteLine(ex.Message);21 }22 }23 }到这里，代码就完成了。

在客户端的代码中有我们就可以根据具体的参数，返回我们希望返回的对象，将"new"操作推迟到工厂类中实现。

这里，参数我直接写上了，我们其实可以将这个参数写到一个xml文件中，如app.config 文件中，动态的读出来，需要穿另外一种衣服了，只需要打开 app.config文件，修改里面的值就行了，不需要项目重新编译。

这样这个小程序就能够适应一定的变化了（在上传上去的代码中我会修改一下）。

其实它也是设计模式正要解决的问题，在不修改代码的情况下，使项目能够适应一定的客户需求变化。

注意，是一定的，并非全部。

优点：∙简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。

通过它，外界可以从直接创建具体产品对象的尴尬局面中摆脱出来。

∙外界与具体类隔离开来，偶合性低。

∙明确区分了各自的职责和权力，有利于整个软件体系结构的优化。

缺点：∙工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则∙虽然简单工厂模式能够适应一定的变化，但是它所能解决的问题是远远有限的。

它所能创建的类只能是事先教考虑到的，如果需要添加新的类，则就需要改变工厂类了。

（这个问题在下一个工厂方法模式将得到很好的解决）应用情景∙工厂类负责创建的对象比较少∙客户只知道传入了工厂类的参数，对于始何创建对象（逻辑）不关心介绍：在简单工厂模式中，我们提到，工厂方法模式是简单工厂模式的一个延伸，它属于Gof23中设计模式的创建型设计模式。

它解决的仍然是软件设计中与创建对象有关的问题。

它可以更好的处理客户的需求变化。

工厂方法模式（Factory Method Pattern）引入我们继续来说"new"的问题，我们在简单工厂模式中，将实例化对象的工作推迟到了专门负责创建对象的工厂类中，这样，在我们事先预知的情况下，可以根据我们的需要动态创建产品类。

但是，我们的预知是有限的，客户的变化可能是无限的。

所以，就出现了问题，一旦客户的变化超越了我们的预知，我们就必须修改我们的源代码了。

这是设计模式所不允许的，怎么办呢？工厂方法模式正是解决此类问题的。

问题：具体工厂类的创建工作不能满足我们的要求了，创建的工作变化了解决思路：哪里变化，封装哪里。

把具体工厂封装起来。

定义工厂方法模式又称为工厂模式，也叫虚拟构造器（Virtual Constructor）模式或者多态工厂模式（Polymorphic Factory）,在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。

意图定义一个用户创建对象的接口，让子类决定实例化哪一个类，工厂方法模式使一个类的实例化延迟到其子类。

参与者∙抽象产品角色（Product）定义产品的接口∙具体产品角色（ConcreteProduct）实现接口Product的具体产品类∙抽象工厂角色（Creator）声明工厂方法（FactoryMethod），返回一个产品∙真实的工厂（ConcreteCreator）实现FactoryMethod工厂方法，由客户调用，返回一个产品的实例工厂方法模式UML图现实生活中的例子为了方便大家理解，我仍然举穿衣服方面的一个例子。

这个例子与简单工厂模式中的那个例子有些不同。

据说清朝有个皇帝穿衣非常的奢侈，每种衣服（具体产品类）由一宫女（具体工厂类）专门负责，这样一来，每增加一种衣服（具体产品类），就要多出一个宫女（具体工厂类），但是他们各负其责，互不影响。

皇帝之所以这样做，是因为针对穿衣服这件事来说，可扩展性是非常强的（）。

分析实现的功能：可以根据皇帝的要求，动态的创建（由宫女去拿）已存在的具体产品（衣服），如果皇帝的要求太苛刻，这种衣服还没有，只需要增加一个宫女，一个衣服就能够满足他的要求了。

每个宫女只负责一种衣服（高内聚），要增加一种衣服，对于以前的所有宫女与衣服来说，都不会受到影响（设计模式中所期望的）。

说到这里，是不是明白了工厂方法模式所能解决的问题及其应用了？呵呵。

你一定在想，比简单工厂模式灵活性高吧。

抽象工厂角色代码1namespace FactoryMethod2{3///<summary>4///抽象工厂类,定义产品的接口5///</summary>6public interface IFactory7 {8 ICoat CreateCoat();9 }10}抽象产品角色代码1namespace FactoryMethod2{3///<summary>4///抽象产品类5///</summary>6public interface ICoat7 {8void ShowCoat();9 }10}具体工厂角色代码1namespace FactoryMethod2{3///<summary>4///具体工厂类:用于创建商务上衣类5///</summary>6public class BusinessFactory:IFactory7 {8public ICoat CreateCoat()//实现抽象工厂类的接口 9 {10return new BusinessCoat();11 }12 }1314///<summary>15///具体工厂类,用于创建时尚上衣16///</summary>17public class FashionFactory : IFactory18 {19public ICoat CreateCoat()20 {21return new FashionCoat();22 }23 }24}具体产品角色代码1namespace FactoryMethod2{3///<summary>4///具体产品类,商务上衣类5///</summary>6public class BusinessCoat:ICoat7 {8public void ShowCoat()9 {10 Console.WriteLine("这件是商务上衣");11 }12 }1314///<summary>15///具体产品类,时尚上衣类16///</summary>17public class FashionCoat : ICoat18 {19public void ShowCoat()20 {21 Console.WriteLine("这件是时尚上衣");22 }23 }24}25客户端代码1namespace FactoryMethod2{3///<summary>4///客户端代码5///</summary>6class Client7 {8static void Main(string[] args)9 {10//为了方便以后修改,将工厂类的类名写在应用程序配置文件中11string factoryName = ConfigurationManager.AppSettings["FactoryName"]; 1213 IFactory factory = (IFactory)Assembly.Load("ConcreteFactory").C reateInstance("FactoryMethod." + factoryName);15 ICoat coat = factory.CreateCoat();16//显示你要的上衣17 coat.ShowCoat();18 }19 }20}客户端代码需要注意的两个地方：1，把具体工厂类类名称写在了应用程序配置文件中，方便修改2，用到了反射，利用.NET提供的反射可以根据类名来创建它的实例，非常方便由反射想到的：下面这一段内容不是计划要写的。