设计模式总结—工厂三姐妹

 

工厂三姐妹是指简单工厂模式、工厂方法模式和抽象工厂模式。

 

简单工厂模式

简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例，实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。

 

对于简单工厂模式我们书上是通过一个加减乘除的运算来说明这个模式的，我们下来看下这个例子的类图：

简单工厂模式的最大优点在于工程类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。但是同样的它仍然存在着一些问题比如说如果我们需要增加各种运算时，需要增加相应的运算的子类、修改简单工厂类在switch中增加分支就可以了。我们不但对扩展开放了，并且也对原有的工程类进行了修改，所以这就违反了“开放-封闭原则”。在这种情况下工厂三姐妹之—工厂方法就出现了。

 

工厂方法模式

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

我们还拿简单工厂中的那个运算的例子来说。我们来看下运用了工厂方法模式的类图：

 

 

工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行的。还拿运算的例子来说，如果我想要增加一个求幂的运算，我们只需增加两个类，一个是求幂的运算类和一个求幂的工厂类然后在客户端进行修改就可以了，这样就完成符合了开放-封闭原则。

所以说工厂方法模式克服了简单工厂的违背开放-封闭原则的缺点，又保持了封装对象创建过程的优点，集中封装了对象的创建，使得要更换对象时，不需要做大的改动就可实现，降低了客户程序与产品对象耦合；工厂方法模式是简单工厂模式的进一步抽象和推广，由于使用的多态性，工厂方法模式保持了简单工厂模式的优点而且客服了它的缺点。工厂方法模式还可以再进一步的优化吗，我们在这里先卖个关子，回头再说这个问题。

 

抽象工厂模式

抽象工厂模式：提供了一个创建一系列相关或相互依赖对象的接口，而无需指定他们的类。

 

可以这样说抽象工厂模式是由工厂方法模式逐渐改善过来的，工厂方法模式是解决一个抽象产品的模式当抽象产品逐渐增加时仍然可以用工厂方法模式来处理，这时的处理就变成了抽象工厂模式了。我们通过数据库一开始只访问用户表运用了工厂方法模式到后来的不但访问用户表并且还访问部门表这两个类图，来说明抽象工厂模式是由工厂方法模式改善而来的。

 

 

 

抽象工厂模式好处是便是易于交换产品系统，由于具体工厂类，在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。另一个优点是，抽象工厂让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户端中。应该说抽象工厂模式将开放-封闭原则和依赖倒转原则很好了进行了应用。

 

如果我们想继续再增加一个抽象产品，如果还拿我们这个数据库例子说的话，想增加一个项目表，增加类这是在所难免的，但是我们还需要对使用项目表的类进行修改，这样就很麻烦了。有句话是这么说的“编程是门艺术，大批量的改动，显示是非常丑陋的做法”。在这种情况下我们采取的办法是用简单工厂来改进抽象工厂，我们用简单工厂来替换抽象工厂接口和具体的工厂。类图如下：

 

 这样的话就有效克服了大量改动多个类的问题，但是随着也出现了一个新的问题，我们都知道简单工厂中有switch判断的情况，我们发生功能的改动，switch中case也需要发送改动，与之前相比是简单了很多，但我们要精益求精，在这种情况下，出现了一个新的名词——反射。

 

反射是一个简单的.NET技术，反射技术听起来很玄乎，实际应用起来不是太难的。

对于反射应用，我们需要在程序顶端写上”using System.Reflection;”来引用Reflection。

反射的格式是：    Assembly.Load(“程序集名称”).CreateInstance(“命名空间.类名称”)

这样就可以对反射进行应用。

 

用反射就可以有效改善switch判断改动的情况，可以这么说，所有在用简单工厂的地方都可以考虑用反射技术来去除switch或if，解除分支判断代理的耦合。

我们前面讲工厂方法模式中卖的那个关子在这里就可以解决了，我们工厂方法模式中也存在着逻辑判断的问题，也可以用反射来解决，这样就可以使我们的工厂方法模式更加完美。