GOF设计模式-创建型模式理解与思索（二）（Factory Method分析）

 

Factory Method模式相对于其他创建型模式，应该是最简单、最容易实现的模式，该模式定义了一个用于创建对象的接口，而让子类决定实例化哪一个类，这样就将实例化的过程延迟到了子类，从而提高了对象创建的灵活性，在这里一个最核心的特征就是为子类提供了一个挂钩。

但是，该模式有一个潜在的缺陷，就是客户可能仅仅为了创建一个特定ConcreteProduct对象而不得不创建Creator的子类，这样，当客户端除了需要一个新的ConcreteProduct而对Creator没有别的新要求时，就会增加维护新产生的Creator类层次负担。通过分析我觉得在如下三个场景中比较适合采用Factory Method模式：

1、Abstract Factory内部。Abstract Factory（抽象工厂）模式可以通过Factory Method实现，此时抽象工厂内的每个创建一类对象的方法就可以是一个Factory Method。结构图如下：

 

2 、框架应用。因为框架给特定应用提供了基础机构，而它（框架）对特定应用的细节是不可知的，所以当在框架中必须创建某种应用对象时，就可以通过工厂方法进行临时填充，具体应用对象的创建通过框架子类重定义该挂钩接口来实现，具体细节描述见该模式的动机部分，结构图如下：

3、在类层次中创建类相关对象。如果存在一个类层次，这个类层次中的每个类都需要一个相似但却略有不同的类于自己关联，这时关联类可以由自己负责和管理，如该模式的效果部分中的图形操作对象类层次。以及jdk集合工具包中迭代器的生成，在jdk集合类层次中，每个具体集合类都有一个与之相对应的迭代器（Iterator）类，具体的迭代器对象就可以由各个集合类负责产生，结构图如下：

  继续深入

在上一篇blog中，我提到创建型模式抽象了对象的实例化过程，而这种抽象化的实现方式大致分为：对象委托、类继承和实例注入三种，并且我把Factory Method模式归入到了通过类继承方式，这与GOF设计模式中的划分——Factory Method 为 对象创建型模式有些不一致。

通过对GOF的《设计模式-可复用面向对象软件的基础》的学习和理解，我觉得 在一些时候将Factory Method 模式归入 类创建型模式可能会更为贴切和容易理解，原因如下：

第一、“类创建型模式将对象的部分创建工作延迟到子类中，而一个对象创建型模式将它延迟到另一个对象中”（引言1.5节），Factory Method模式正式通过在类中定义一个用于创建对象的接口，而让子类通过重新定义该接口（也可能使用父类实现）来决定实例化哪一个类。这种通过父类定义、子类实现的方式正是类的继承机制。

第二、我们可以通过Template Method（模板方法-类行为型模式）来进一步说明，Template Method定义了一个操作中算法的骨架，而将一些步骤延迟到子类中，从而使得子类可以不改变算法的结构既可重定义该算法的某些特定步骤。这与Factory Method的意图（定义一个用于创建对象的接口，而让子类来决定实例化哪一个类，从而使一个类的实例化延迟到子类，给子类带来了灵活性）从层次的角度来说正好相同，而不同的只是Template Method 延迟的是操作行为，Factory Method 延迟的是实例化对象。

其实，将某个模式分为对象模式还是类模式，我觉得并不是很严格，具体分法只是根据观察的角度不同而已。比如对于书中该模式的动机部分中所讲的示例——一个文档应用框架，和代码程序部分中的迷宫的创建，我觉得用类创建型模式理解就会好一些；而对于书中该模式的效果部分中提到的创建图形操作对象，我觉得用对象创建型模式理解会好一些。 通过分析总结就是：如果创建的对象是自己用，那就看作类创建型模式理解较好；如果创建的对象是提供给外界对象用，那就看作对象创建型模式理解较好。