小菜学设计模式——工厂方法模式

背景

    简单工厂模式最大的优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关类，对于客户端来说，去除了与具体产品的依赖。如果，项目需要扩展，新增一种产品需要简单工厂模式生产，那么工厂内部必须重写修改必要的逻辑判断，这对于面向接口编码是非常不愿意看到的，因为他违背了面向对象设计原则：开放封闭原则。

    那么如何我们才能解决这个问题呢？工厂方法模式的产生应该也是简单工厂模式的改进。

1、使用意图

    工厂方法模式实现时，客户端需要决定实例化化哪一个工厂方法来生产产品，换句话说，工厂方法模式就是仅仅把简单工厂模式的内部必要逻辑判断移到了客户端代码来进行，那么，以前是修改工厂类内部的逻辑判断，现在变成了修改客户端的业务逻辑，说实话，相对于简单工厂模式稍微好点，但是还是难以扩展。

2、生活实例

    生活处处是例子，只要有简单工厂模式的地方，自然可以调整为工厂方法模式。

3、Java 例子（框架、JDK 、JEE）

    还是说以前那个报表导出的例子，工厂方法模式的话应该这样写，建一个超级工厂接口，IExportFactory，里面声明一个抽象方法，这个方法就是生产对象，估计你也知道了，生产的对象肯定是所有产品的超类，那么，如果你想要一个PdfExport实例的话，需要定义一个 PdfExportFactory 实现 IExportFactory ，同时实现里面的方法，生产对应的PdfExport；那么客户端自己new 一个工厂，然后用工厂实例化对象；如果想要扩展一个产品，那么新增一个工厂类实现IExportFactory就可以了，呵呵，这个到底有什么好啊！

4、模式类图

    

5、模式优点

    谈不上什么优点，想想啊，简单工厂模式可以改进为静态工厂模式，就是把生产产品的方法设为静态的，而工厂方法呢？不可以，因为工厂方法模式重在方法，这个方法通过继承动态实现完成，所以可能是静态的。当然，工厂方法模式还可以改进为在一个工厂内部提供不同的方法来生成不同的产品，那么就可以避免过多的工厂类了，虽然这样子可以减少类，但是实际上它和简单工厂一样违背了开放封闭原则，如果后期扩展一个新的产品，那么必须在工厂内部中新增一个生产对应产品的方法。

6、与类似模式比较

    只能与简单工厂模式比较，因为抽象工厂还没没有深入学习，懂的不是很多；简单工厂模式和工厂方法模式没什么可说的，感觉代码就必须在if-else中度过。