《大话》之 三大工厂

简单工厂模式：

准确的来说，简单工厂并不算是一个模式，他只是工厂家族的一个特例，因为他不满足“开放封闭原则”，为什么这么说呢，有图来说明：

                        

从图上，我们可以清楚地看到，在整个抽象运算类下，分别将每种算法进行封装，然后需要那种算法的时候就通过简单工厂类实例化出一个具体对象来，通过多态返回父类的方式实现计算器，也就是直接调用一个算法类；而且当我们需要添加算法的时候，只要再添加一个算法类就好了，很简单，也很方便。 所以简单工厂的优点就是工厂泪中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。但是同时问题也就出现了，当我要增加功能的时候，我们肯定要给运算工厂类的方法里添加Case的分支，修改原有的类，那 这就不仅仅是对拓展开放了，对修改也就同样开放了，所以说它不满足开放封闭原则，算不得是一个模式。

当然，科学的力量是无限的，为了解决这个问题，相对应的模式就出现了，那就是工厂家族的二姐

工厂方法模式：

工厂方法个人简介：

内容：定义一个用于创建对象的接口，让子类决定实例化哪一个类。（工厂方法是一个类的实例化延迟到其子类），对于这个，我们可以清楚地从图中看出来，当我们要求算法实现的时候，选择依然存在，但是，我们是在客户端上决定要用什么算法工厂，然后让其实例化相对应的算法类。用户科学的话来说，就是工厂方法把简单工厂的内部逻辑判断转移到了客户端代码来进行。在这里，如果我们还是想要添加功能，根本不需要修改工厂类，只需要修改客户端就可以了

凡事都是有两面性的，工厂方法的确很好，但并不是没有缺点的： 那就是我们每增加一个功能或者产品都需要增加一个产品工厂的类，增加了额外的开发量

下面重磅来袭，工厂家族的大姐大  抽象工厂模式：

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

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

优点：

1.易于交换产品系列（由于具体共产类在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，他只需要改变具体工厂即可使用不同的产品配置）

2.他让具体的创建实例过程与客户端分离，客户端是通过过他们的抽象接口操纵是实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中

但是抽象工厂不便于增加功能，因为每一增加功能的话，他就需要改变抽象工厂类，与其他的所有抽象类，十分的糟糕，真是有利有弊，各有千秋

这也就教导们，在对的时候用对的模式，再合适的时候做合适的事，才是最正确的