大话设计模式----工厂方法模式

我们先来回顾一下简单工厂模式

http://blog.csdn.net/bless924295/article/details/78313146

这是我的关于工厂模式的博客，里面有一个关于运算的例题，我们今天还是用这个例题。

简单工厂模式UML类图：

·

我们再来看一下工厂方法模式关于运算类的UML类图：

好，我们把两张类图放在一起来看，首先，他们有很大的不同对不对，其次，你会发现其实工厂方法模式看起来更为麻烦，那我们为什么要用工厂方法模式呢？

首先，我们先来看一下简单工厂模式的优点。

简单工厂模式的最大的优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择，动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。

但是，假如说我们需要再加一个类，那么我们就需要在switch里再添加一个case，这不就修改类了？不就违背了开放-封闭原则（简单工厂模式）？？？

所以，工厂方法模式就来了。

我们先来明确工厂方法模式的定义：

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

我们来看一下工厂方法模式的结构图：

·

既然这个工厂类与分支耦合，那么我们就对它下手，根据依赖倒转原则，我们把工厂类抽象出一个接口，这个接口只有一个方法，就是创建抽象产品的工厂方法。然后，所有的要产生的具体类的工厂，就去实现这个接口，这样，一个简单工场模式的工厂类，变成了一个工场抽象接口和多个具体生成对象的工厂了。

工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断转移到了客户端代码来进行。你想要加功能，本来是改工厂类的，而现在是修改客户端！