之前为大家介绍过一个很有趣的模式，简单工厂模式。而今天说的工厂方法模式其实是对简单工厂模式的进一步优化。

 

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

 

　　还是和简单工厂模式一样，写一个关于计算器的程序。

 

　　先来看看代码：

 

　　计算类：（其他具体计算类都继承该计算类）

 

图 1

 

　　计算类的子类：（包括加法计算类，减法计算类，除法计算类和乘法计算类）

 

图 2（乘法计算类）

 

图 3（除法计算类）

 

图 4（加法计算类）

 

图 5（减法计算类）

 

　　工厂接口：总工厂接口，其他计算类来实现该接口

 

图 6

 

　　实现计算类：实现了工厂接口，来分门别类来实例化具体计算类

 

图 7（实例化乘法类）

 

图 8（实例化减法类）

 

图 9（实例化加法类）

 

 

图 10（实例化减法类）

 

　　计算器类：实现case语句，包装了各个算法的实现

 

图 11

 

　　客户端代码：前台输入数据时走的程序

 

图 12

　　对比之前的简单工厂模式，可以知道，简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。但是如果要增加一个算法，那么就必须在工厂类中的case语句发生变化，增加一条判断，这样违背了开闭原则，就设计而言是不合理的。但是工厂模式却不会这样。

 

　　而针对计算器这么一个例子，其实个人而言相比工厂模式还是简单工厂模式来的更为合理。因为在客户端，我们能够获取的值是随着客户的心情的变化而变化的，无法具体了解客户到底是要生成哪个类。但是如果是类似于商场打折，每次的打折都是固定的，那么就可以在客户端固定写好试用哪种算法，而客户更改需求的话，就只要修改客户端的代码就可以了。这就是工厂模式的方便之处。

 

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

 

　　工厂模式克服了简单工厂违背开放-封闭原则的缺点，又保持了封装对象创建过程的优点。它们集中封装了对象的创建，使得要更换对象的时候，不需要做大的改动就可以实现，降低了客户程序与产品对象的耦合。工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且客服了它的缺点。但缺点是由于每加一个产品，就需要加一个产品工厂的类，增加了额外的开发量。