【大话】三大工厂模式

简单工厂模式：

     

简单工厂模式是不属于GOF设计模式之一的。它是工厂模式家族中最简单最实用的模式，​也可以理解为它是不同工厂模式的一个特殊实现。在简单工厂模式中，最重要的一个类就是工厂类，它负责根据外界给定的信息，决定究竟应该创建那个具体类的对象，通过实用工厂类，外界可以仅仅创建对象，告诉它要完成什么工作就可以了，而具体完成工作的方法是怎么实现的，外界不用管。这个工厂类可以直接被外界调用。

    举个例子就是：如果有一个人他要请人吃饭，但是他本身不会做饭，那么他只需要找一个饭店，告诉饭店我要什么样的菜和饭就可以了。在这里饭店就是一个工厂类。

  简单工厂的缺点就是：它把所有实例的创建模式都集中到一个类中，这就大大增加了一个类的“责任”，如果我们需要添加新的具体类，那么我们就必须得修改这个工厂类，这对系统的维护和扩展非常不利。违反了开放--封闭原则。

工厂方法模式：

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

工厂方法其实就是把简单工厂中条件分支判断的工厂类给抽象出来，把每个分支抽象出来成为一个子工厂类。而原来的工厂类成为了一个接口，这些子工厂类都去继承实现这个接口。这样，如果要增加新的算法，直接增加算法类和相应的算法具体工厂就可以了。不会对类进行修改，只是进行了扩展。具体如图：

工厂方法的优点是：既克服了简单工厂违背开放--封闭原则的缺点，又保持了封装对象创建过程的优点。

工厂方法的缺点是：工厂方法实现时，要判断实例化哪个工厂来实现运算类，也就是还是得要进行分支判断，现在如果增加算法虽然不修改类了，但是却变成了修改客户端，这也是一个非常大的缺点。

抽象工厂模式：

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

该怎么理解这句话呢？按着图说，当每一个抽象产品有多于一个的具体子类的时候，如图中的AbstractProductA和AbstractProductB这两个抽象产品都有多于一个的具体子类实现，那么工厂类应该怎么知道实例化哪个子类呢？抽象工厂用的就提供两个具体的工厂角色ConcreteFactory1和ConcreteFactory1分别对应两个具体产品角色ProductA和ProductB，每个具体工厂角色只负责某一个对应的产品角色的实例化。

由此，我们可以很明显的看出抽象工厂和工厂方法的不同：工厂方法是定义一个接口，实例化好多的具体工厂类，让这些类与具体的算法类一一对应。而抽象工厂是定义一个抽象的工厂类，让这个抽象工厂类泛化出具体工厂子类，来分别对应多个产品等级机构的每个具体产品类有针对性的实现。

抽象工厂的优点有：便于交换产品系列。还可以让具体的创建实例过程与客户端分离。（客户端是通过对抽象接口的操作来操纵实例）

抽象工厂的缺点有：虽然抽象工厂可以方便的交换产品的系列，比如换掉软件一开始使用的数据库。但是如果你的需求是功能的改变怎么办？如果真的是这样，那么抽象工厂会改变很多的类。这显然违背了开放--封闭原则。

改进：反射的应用

.在程序顶端写上using System.Reflection；来引用Reflection就可以使用反射。

.格式：Assembly.Load("程序集名称").CreateInstance("命名空间.类名称")
下面来举个例子：
常规的方法书写：IUser result=new SqlserverUser（）；
而反射的写法：IUser result=（IUser）Assembly.Load("抽象工厂模式").CreateInstance("抽象工厂模式.SqlserverUser“)。
这样一对比可以轻易的看出：用了反射以后，如果我们要更换数据库，可以将数据库名称作为变量来处理，而普通的获得实例的方法是不可以这样灵活的。

对于反射，只有具体的应用以后才能知道它到底好在哪里，我在这里也只是略微的提及一下，它可以用到很多设计模式中，帮助改善哪些有条件分支语句的代码的简化。