正如同笔者在<简单工厂模式>一节里介绍的,工厂模式有简单工厂模式,工厂方法模式和抽象工厂模式几种形态。简单工厂模式已经在前面作过介绍。在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。
而本节要讨论的工厂方法模式是简单工厂模式的进一步抽象化和推广。它比简单工厂模式聪明的地方在于, 它不再作为一个具体的交通警察的面貌出现,而是以交通警察局的面貌出现。它把具体的车辆交通交给下面去管理。换言之,工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给子类去作。处于工厂方法模式的中心位置上的类甚至都不去接触那一个产品类应当被实例化这种细节。这种进一步抽象化的结果,是这种新的模式可以用来处理更加复杂的情形。
为什么需要工厂方法模式
现在,让我们继续考察我们的小花果园。在<简单工厂模式>一节里,我们在后花园里引进了水果类植物, 构造了简单工厂模式来处理, 使用一个FruitGardener类来负责创立水果类的实例。见下图。
图1. 简单工厂模式。FruitGardener掌握所有水果类的生杀大权。
在这一节里,我们准备再次引进蔬菜类植物，比如
西红柿 (Tomato)
土豆 (Potato)
西芥兰花 (Broccoli)
蔬菜与花和水果当然有共同点,可又有不同之处。蔬菜需要喷洒(dust)杀虫剂(pesticide)除虫, 不同的蔬菜需要喷洒不同的杀虫剂,等等。怎么办呢?
那么,再借用一下简单工厂模式不就行了? 再设计一个专管蔬菜类植物的工厂类,比如
图2. 简单工厂模式。VeggieGardener掌握所有蔬菜类的生杀大权
这样做一个明显的不足点就是不够一般化和抽象化。在FruitGardener和VeggieGardener类之间明显存在很多共同点, 这些共同点应当抽出来一般化和框架化。这样一来,如果后花园的主人决定再在园子里引进些树木类植物时, 我们有框架化的处理方法。本节所要引入的工厂方法模式就符合这样的要求。
简单工厂模式的回顾
有必要首先回顾一下简单工厂模式的定义,以便于比较。
图3. 简单工厂模式的类图定义
从上图可以看出，简单工厂模式涉及到以下的角色
工厂类 (Creator)
担任这个角色的是工厂方法模式的核心，是与应用程序紧密相关的，直接在应用程序调用下，创立产品实例的那个类。
工厂类只有一个，而且是实的。见下面的位图