工厂方法模式

思考并回答以下问题：

简单工厂模式实现

简单工厂模式，以计算器为例，结构图如下。

工厂类是这样写的。

客户端的应用。

工厂方法模式实现

计算器的工厂方法模式实现的结构图是这样的。

先构建一个工厂接口。

然后加减乘除各建一个具体工厂去实现这个接口。

客户端的实现是这样的。

简单工厂vs.工厂方法

如果我现在需要增加其他运算，比如求M数的N次方，或者求M数的N次方根，这些功能的增加，在简单工厂里，我是先去加‘求M数的N次方’功能类，然后去更改工厂方法，当中加‘Case’语句来做判断，现在用了工厂方法，加功能类没问题，再加相关的工厂类，这也没问题，但要我再去更改客户端，这不等于不但没有减化难度，反而增加了很多类和方法，把复杂性增加了吗？为什么要这样？

这其实就是工厂方法模式和简单工厂的区别所在。简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。就像你的计算器，让客户端不用管该用哪个类的实例，只需要把‘+’给工厂，工厂自动就给出了相应的实例，客户端只要去做运算就可以了，不同的实例会实现不同的运算。但问题也就在这里，如你所说，如果要加一个‘求M数的N次方’的功能，我们是一定需要给运算工厂类的方法里加‘Case’的分支条件的，修改原有的类？这可不是好办法，这就等于说，我们不但对扩展开放了，对修改也开放了，这样就违背了开放-封闭原则。

工厂方法模式（Factory Method）结构图

既然这个工厂类与分支耦合，那么我就对它下手，根据依赖倒转原则，我们把工厂类抽象出一个接口，这个接口只有一个方法，就是创建抽象产品的工厂方法。然后，所有的要生产具体类的工厂，就去实现这个接口，这样，一个简单工厂模式的工厂类，变成了一个工厂抽象接口和多个具体生成对象的工厂，于是我们要增加‘求M数的N次方’的功能时，就不需要更改原有的工厂类了，只需要增加此功能的运算类和相应的工厂类就可以了。

这样整个工厂和产品体系其实都没有修改的变化，而只是扩展的变化，这就完全符合了开放-封闭原则的精神。

工厂方法从这个角度讲，的确要比简单工厂模式来得强。

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

雷锋工厂

雷锋类，拥有扫地、洗衣、买米等方法。

学雷锋的大学生’类，继承‘雷锋’。

然后客户端实现的代码是这样的。

现在假设你们有三个人要去代替他做这些事，实例化三个‘学雷锋的大学生’对象。

你们都是要毕业的，而帮助老人却是长期工作，所以‘社区志愿者’更合适，此时这样的写法就非常不合适了，因为我们需要更改多个实例化的地方。

其实老人不需要知道是谁来做好事，他只需知道是学雷锋的人来帮忙就可以了。所以还需增加一个继承‘雷锋’类的‘社区志愿者’类。

再写简单工厂类。

客户端的代码，如果要换，就只需换‘学雷锋的大学生’为‘社区志愿者’

需要在任何实例化的时候写出这个工厂的代码。这里有重复，也就有了坏味道。你再用工厂方法模式写一遍。

好的，那就需要雷锋工厂了。

“客户端调用的时候只需要这样就可以了。”

尽管如果要换成‘社区志愿者’也还是要修改代码，但是只需要修改一处就可以了。这是比较好的了。

工厂方法克服了简单工厂违背开放-封闭原则的缺点，又保持了封装对象创建过程的优点。

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

这还不是最佳的做法？那应该如何做呢？还有就是这样还是没有避免修改客户端的代码呀？

利用‘反射’可以解决避免分支判断的问题。