设计模式之工厂方法模式

设计模式之工厂方法模式

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

结合上篇说过的‘简单工厂模式’，接下来两种模式PK一下~

 

简单工厂VS工厂方法

    在之前的简单工厂里，如果要增加其他运算，比如求M数的N次方，或者求M数的N次方跟，这些功能的增加，在简单工厂里。要先取加‘求M数的N次方’功能类，然后去更改工厂方法，当中加‘case’语句来判断，现在用了工厂方法，加功能类没问题，再加相关的工厂类，这也没问题，但是还要去改客户端代码，这就等于不但没有简化难度，反而增加了很多类和方法，把复杂性增加了。

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

 

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

    这样整个工厂和产品体系其实都没有修改的变化，而只是扩展的变化，这就完全符合了开放-封闭原则的精神。工厂方法从这个角度来说，的确要比简单工厂模式方便。仔细观察就会发现，工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。如果加功能，本来是改工厂类，而现在是修改客户端代码。

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