设计模式完成学业，我是一个研究躺在订单，有三种模式其名称中包含“工厂”这个词眼，。它们就是“工厂三姐妹”，以下我们通过计算器的演示样例来好好认识一下这姐妹三儿。
简单工厂模式：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvQ1lMX2hhcHB5Z2lybA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" >
简单工厂类中的代码：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvQ1lMX2hhcHB5Z2lybA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" >
从中我们能够看到。当用户请求进行加法运算时，仅仅需operationFactory.createOperate("+")，工厂就会自己主动给出一个加法类的实例，用户根本不用和详细的运算类打交道，对象的创建过程被封装起来了。
可是假设我们要加入一个幂运算，不仅要在运算类下加入幂运算的子类来扩展，还须要修改工厂类，加入新的case。这样对修改也开放了。简单工厂模式就是由于违背了开闭原则，而不能算得上一个真正的设计模式。
当工厂类负责创建的对象比較少且不再增减，客户仅仅知道传入工厂类的參数的情况下，使用简单工厂模式是个不错的选择。
工厂方法模式：
同简单工厂模式相比，我们能清晰地看到工厂类下多了详细运算的工厂子类，工厂类接口的任务不那么繁重了，仅仅有一个创建抽象产品的方法：
全部生产详细产品类的工厂。都要实现这个接口。client的代码变成了这种：
IFactory operFactory=new AddFactory();Operation oper=operFactory.CreateOperation();
这样就让子类去决定实例化详细的类了。分工更细了，责任到人。这时候，我们要加入幂运算仅仅需在工厂类和运算类下分别扩展一下，而不用改动代码了，弥补了简单工厂模式的不足之处。
当须要生产一系列的产品时，比方说有两种级别的计算器，一种是我们常见的算术型计算器，一种是科学型计算器。它们都能计算加减乘除，而工厂方法模式实现的仅仅是一种计算器。这个时候，就要用抽象工厂模式了，真可谓山外有山，人外有人。
抽象工厂模式：
(自己举得样例。有不妥之处。请谅解)
这样一来。客户能够更换产品的系列，想要算术型计算器，IFactory=new ArithmeticFactory()。想要科学型的，IFactory=new ScienceFactory()。
工厂方法模式与抽象工厂模式的差别事实上就是两句话：前者仅仅有一个抽象产品类。而后者有多个。前者的详细工厂类仅仅能创建一个详细产品类的实例，而抽象工厂模式能够创建多个。
纵观这三种模式，长江后浪推前浪。但不要以为抽象工厂模式就非常完美了，当我们要加入乘法运算呢？不仅有扩展还有修改。学习要灵活，这三姐妹能够互相帮助呀，能够让简单工厂模式来改进抽象工厂模式。事实上在全部用到简单工厂的地方，都能够考虑反射技术来去除switch或if，解除分支推断带来的耦合。
办法总比困难多的。
这姐妹三儿就介绍到这儿了。今天先混个脸熟。以后打交道的日子多着呢。
版权声明：本文博客原创文章，博客，未经同意，不得转载。