探索设计模式之二——工厂方法模式

2.工厂方法模式（Factory Method Pattern）

       上一章介绍了简单工厂模式的作用和使用场景，它能为我们隔离开产品使用者与产品制造者的职责，使得这两部分代码脱离耦合。

 

       在看到简单工厂模式带来的好处的同时，我们也可以预见，随着工厂产品的丰富，每增加一个产品，都将需要修改工厂方法。这是简单工厂的特性——只能处理可预见的情况决定的。然而，频繁的修改代码是我们所不愿意看到的，通过修改代码来增加产品（功能），也违反了设计模式中的“开闭原则” 。

      

       开闭原则：即“开放-闭合原则”，软件架构应该设计成对于修改来说，代码实体是关闭的，而对于扩展来说，代码实体则是开放的。通俗一点讲，开闭原则是鼓励通过“新增”来代替“变化”。鼓励设计者将业务逻辑抽象化，将逻辑的本质设计成抽象类或者接口，逻辑的具体实践操作设计成具体实现类。

 

现实世界中，业务的本质是相对稳定的，而业务的具体实践则总会不断变化。在逻辑改变的时候，应当做到可以只替换具体实现类，而会不影响到代码的架构。开闭原则是OOAD中的核心原则，在实现功能需求的时候，新增的代码与修改的代码之间的比值，某种程度上可以作为量化衡量一个软件系统的成熟程度的标志。

 

       为了解决简单工厂的这个弊端，需要引入本章的主题：工厂方法模式。工厂方法模式又称为工厂模式，也叫虚拟构造器（Virtual Constructor），工厂方法模式主要是对“工厂”的封装，提供一个创建者的接口，将产品实例化的步骤延迟到工厂的子类完成，让子类决定需要创建什么产品。

 

目的：

定义创建者的抽象接口，延迟产品实例化到其子类之中，创建的产品一般不再通过传入参数控制，而直接决定于使用了哪个实现类作为其子类。

 

场景：

       随着游戏的发展，只靠机枪兵、喷火兵越来越难以获得战斗胜利了。这时候，机械化的重型武器登上了战争的舞台，战场上的主角，不再只是从兵营一个地方生产出来。司令部为了检验Raynor的设计模式是否能在机械化混合部队中发挥作用，特别举行了一次阅兵仪式……

 

为了简单起见，本次阅兵需要检阅仅两种部队：从兵营生产出来的机枪兵以及从重工厂生产出来的坦克。无论从哪里生产出来，他们都是Terran的部队，实现了ITerranArmy接口，对于本次阅兵来说，此接口只有一个showState()方法。

 

                              

分析：

 

       照例，我们先看一下这次需要涉及到的产品类图及代码：

图2.1 战斗部队及工厂的UML图

 

public interface ITerranArmy { public void showState(); } public class Marine implements ITerranArmy { public Marine() { System.out.println("训练出一个机枪兵"); } public void showState() { System.out.println("机枪兵从兵营生产，属于步兵，作战灵活。"); } } public class Tank implements ITerranArmy { public Tank() { System.out.println("制造出一架坦克"); } public void showState() { System.out.println("坦克从重工厂生产，属于机械部队，威力强大。"); } }

 

       如果现在继续使用简单工厂来完成这个需求的话，随着各种兵种的登场，工厂类的代码将会出现一长串的if语句，而且每增加一种兵种，就必须修改一次工厂类。显然，根据上面的讨论，这样的代码是不可忍受的。

 

       根据当前的实际情况，Raynor对简单工厂做出了一些扩展：首先建立后勤部，它不负责生产任何部队，但是任何部队的生产都是由后勤部直接领导，在程序语言中，我们把它叫做“抽象工厂”，在本次实例中，我们把它叫做“ITerranFactory”接口，无论是兵营还是重工厂，都是此接口的一个实现类，在程序语言中，我们把这些实现类叫做“具体工厂”。而场景描述中提到的ITerranArmy接口，在程序语言中则成为“抽象产品”，要生产的机枪兵、坦克都是此接口的实现，成为“具体产品”。

 

       抽象工厂和具体工厂的实现代码如下：

 

//抽象工厂 public interface ITerranFactory { public ITerranArmy createArmy(); } //具体工厂，此工厂生产坦克 public class MachineFactory implements ITerranFactory { public ITerranArmy createArmy() { return new Tank(); } } //具体工厂，此工厂生产机枪兵 public class SoldierFactory implements ITerranFactory { public ITerranArmy createArmy() { return new Marine(); } }

 

       在阅兵的时候，调用代码如下：

 

public class WarField { public static void showState(ITerranFactory factory) { factory.createArmy().showState(); } public static void main(String[] args) { // 一般来说，大多应用是将Factory的实现类写在配置文件中。 // 这样就可以实现通过更换工厂来切换生产产品，而不用修改代码。 showState(new SoldierFactory()); showState(new MachineFactory()); } }

 

       从代码上可以看出，我们需要什么产品，不再是靠外界传入参数决定，而是取决于抽象工厂使用的是具体哪个实现类。

 

值得指出的是，虽然示例代码中是直接通过new来创建具体工厂，但在现实编程中，大部分工厂方法模式都是配合这反射来使用的，既可以考虑把“SoldierFactory”、“MachineFactory”等具体实现类写在配置文件中，通过反射代替直接new一个具体工厂对象，这样当增加一个产品，就可以做到对工厂和使用者都不存在任何修改，只需要添加一个新的工厂类，并且配置到配置文件中即可，这就是开闭原则的一个体现。

 

       最终运行结果如下：

 图 2.2 阅兵仪式运行结果

 

总结：

通过上述阅兵的例子，我们看到工厂方法模式确实给系统架构带来强大而灵活的扩展能力。这种基于多态性设计的模式，使得产品的实例化延迟到具体子类之中，通过替换不同的实现子类就能达到新增和切换产品的目的。

 

       由于本次阅兵效果良好，司令部决定让Raynor领导这些部队对Zerg进行一次大规模的协同作战。前面在简单工厂、工厂方法两种模式中，主要都是围绕这个体产品（Marine、Firebat、Tank等）的创建进行讨论，下一章中，我们将会通过一次“协同作战”看看各种具体对象之间存在互相依赖关系时，如何运用抽象工厂模式（Abstract Factory Pattern）来解决问题。