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

工厂方法模式

前一篇降到了简单工厂模式，也提到了简单工厂模式的缺点：违背了代码六大设计原则之一的开放封闭原则。为了解决这个问题，于是又引出一个新的设计模式：工厂方法模式。

* 工厂方法模式（Factory Method Partten）*：定义一个抽象类（对某个产品的抽象），让子类去继承实现一个具体的产品。同时定义一个抽象的工厂类，每个具体的产品对应一个具体的工厂类，在工厂类中创建产品的实例。 说简单一点，就是在简单工厂的基础上， 工厂类不再是一个类了，而是有一个抽象类，然后有多少产品，就再实现多少个对因的工厂类。 UML用例图如下：

比如， 在简单工厂中实现的示例代码中， 我们讲到了加减乘除法， 我们继续讲这个例子， 用抽象工厂去实现后， 它的UML用例图如下：

在这个例子中，工厂类不再是一个，而是加法对应了一个加法工厂类， 减法对应了一个减法工厂类。

简单工厂的代码为：

IOperation ope = SimpleFactory.create(SimpleFactory.ADD);
int result = ope.getResult(6,3);

使用工厂方法后， 业务代码变成了这样：

IFactory factory = new AddFactory();//创建对应计算方法的工厂类
IOperation ope = factory.create();
int result = ope.getResult(6,3);

工厂方法模式相对于简单工厂的优点

仔细一看， 可能产生了疑问？这不就是把简单工厂里的分支判断直接挪到了业务代码的地方吗？

其实并不完全是这样， 在简单工厂中我们提到， 如果分支太多， 就不太好维护和管理了，一个工厂类也会显得过于臃肿，万一某个类的实例化需要修改， 我们都得进入这一个工厂类来修改，要是改错了就不好了， 有潜在风险， 同时， 这种设计也不符合代码设计六大原则之单一职责原则和开放封闭原则。于是， 通过工厂类进一步的抽象， 可以获得以下好处：

• 1. 符合单一职责原则。工厂类解耦，让每一个具体的工厂类只做一件事情， 就是创建对应产品的实例对象， 如果这个产品的实例化需要修改， 也只需要改这一个工厂类， 不会影响其他产品类
• 2、符合开发封闭原则。当需要新增一个产品时， 只需要新增一个对应的工厂类即可，不会对原有的类进行修改。

• 3、代码的封装和抽象更好， 可维护性得到提高。

  看到这里就有一点明白了， 其实工厂方法模式就是对简单工厂模式的一次升级， 让代码通过抽象得到了更好的封装，降低了耦合度。

工厂方法模式相对于简单工厂的缺点

缺点主要就是代码量和类的数量整体上升了。

所以，我们实际开发过程中，也是要兼顾代码优化和开发效率的， 有些比较简单，用的的地方少，也没几个分支，代码结构不负责的，直接使用简单工程模式就行了，反之， 则可以考虑使用升级版的工厂方法模式了。

没有哪一种设计模式是完美的，设计模式都是在不断演化和更新的，下一篇将介绍在工厂方法模式上进一步抽象演化出来的 抽象工厂模式。