10.1 辉煌工程——制造悍马
周三，9:00，我刚刚坐到位置上，打开电脑准备开始干活。
“小三，小三，叫一下其他同事，到会议室开会”，老大跑过来吼，带着坏笑。还没等大家坐稳，老大就开讲了：
“告诉大家一个好消息，昨天终于把××模型公司的口子打开了，要我们做悍马模型，虽然是第一个车辆模型，但是我们有能力、有信心做好，我们一定要……”（中间省略20分钟的讲话，如果你听过领导人的讲话，这个你应该能够续上）
动员工作做完了，那就开始压任务了。“这次时间是非常紧张的，只有一个星期的时间，小三，你负责在一个星期的时间把这批10万车模（注：车模是车辆模型的意思，不是香车美女那个车模）建设完成……”
“一个星期？这个……是真做不完，要做分析，做模板，做测试，还要考虑扩展性、稳定性、健壮性等，时间实在是太少了。”还没等老大说完，我就急了，再不急我的小命就折在上面了！
“那这样，只做最基本的实现，不考虑太多的问题，怎么样？”老大又把我弹回去了。
“只作基本实现？那……”
唉，领导已经布置任务了，那就开始拼命地做吧。然后就开始准备动手做，在做之前先介绍一下我们公司的背景，我们公司是做模型生产的，做过桥梁模型、建筑模型、机械模型，甚至是一些政府、军事的机密模型，这个不能细说，绝密。公司的主要业务就是把实物按照一定的比例缩小或放大，用于试验、分析、量化或者是销售，等等，上面提到的××模型公司是专门销售车辆模型的公司，自己没有生产企业，全部是代工。我们公司是第一次从××模型公司接单，那我怎么着也要把活干好，可时间有限，任务量又巨大，怎么办？
既然领导都说了，不考虑扩展性，那好办，先按照最一般的经验设计类图，如图10-1所示。
图10-1 悍马车模型最一般的类图
非常简单的实现，悍马车有两个型号，H1和H2。按照需求，只需要悍马模型，那好我就给你悍马模型，先写个抽象类，然后两个不同型号的模型实现类，通过简单的继承就可以实现业务要求。我们先从抽象类开始编写，抽象悍马模型如代码清单10-1所示。
代码清单10-1 抽象悍马模型
public abstract class HummerModel { /* * 首先，这个模型要能够被发动起来，别管是手摇发动，还是电力发动，反正 * 是要能够发动起来，那这个实现要在实现类里了 */ public abstract void start; //能发动，还要能停下来，那才是真本事 public abstract void stop; //喇叭会出声音，是滴滴叫，还是哔哔叫 public abstract void alarm; //引擎会轰隆隆地响，不响那是假的 public abstract void engineBoom; //那模型应该会跑吧，别管是人推的，还是电力驱动的，总之要会跑 public abstract void run;} 在抽象类中，我们定义了悍马模型都必须具有的特质：能够发动、停止，喇叭会响，引擎可以轰鸣，而且还可以停止。但是每个型号的悍马实现是不同的，H1型号的悍马如代码清单10-2所示。
代码清单10-2 H1型号悍马模型
public class HummerH1Model extends HummerModel { //H1型号的悍马车鸣笛 public void alarm { System.out.println(/"悍马H1鸣笛.../"); } //引擎轰鸣声 public void engineBoom { System.out.println(/"悍马H1引擎声音是这样的.../"); } //汽车发动 public void start { System.out.println(/"悍马H1发动.../"); } //停车 public void stop { System.out.println(/"悍马H1停车.../"); } //开动起来 public void run{ //先发动汽车 this.start; //引擎开始轰鸣 this.engineBoom; //然后就开始跑了，跑的过程中遇到一条狗挡路，就按喇叭 this.alarm; //到达目的地就停车 this.stop; }} 大家注意看run方法，这是一个汇总的方法，一个模型生产成功了，总要拿给客户检测吧，怎么检测？“是骡子是马，拉出去溜溜”，这就是一种检验方法，让它跑起来！通过run这样的方法，把模型的所有功能都测试到了。
H2型号悍马如代码清单10-3所示。
代码清单10-3 H2型号悍马模型
public class HummerH2Model extends HummerModel { //H2型号的悍马车鸣笛 public void alarm { System.out.println(/"悍马H2鸣笛.../"); } //引擎轰鸣声 public void engineBoom { System.out.println(/"悍马H2引擎声音是这样在.../"); } //汽车发动 public void start { System.out.println(/"悍马H2发动.../"); } //停车 public void stop { System.out.println(/"悍马H2停车.../"); } //开动起来 public void run{ //先发动汽车 this.start; //引擎开始轰鸣 this.engineBoom; //然后就开始跑了，跑的过程中遇到一条狗挡路，就按喇叭 this.alarm; //到达目的地就停车 this.stop; }} 好了，程序编写到这里，已经发现问题了，两个实现类的run方法都是完全相同的，那这个run方法的实现应该出现在抽象类，不应该在实现类上，抽象是所有子类的共性封装。
注意 在软件开发过程中，如果相同的一段代码复制过两次，就需要对设计产生怀疑，架构师要明确地说明为什么相同的逻辑要出现两次或更多次。
好，问题发现了，我们就需要马上更改，修改后的类图如图10-2所示。
图10-2 修改后的悍马车模类图
注意，抽象类HummerModel中的run方法，由抽象方法变更为实现方法，其源代码如代码清单10-4所示。
代码清单10-4 修改后的抽象悍马模型
public abstract class HummerModel { /* * 首先，这个模型要能发动起来，别管是手摇发动，还是电力发动，反正 * 是要能够发动起来，那这个实现要在实现类里了 */ public abstract void start; //能发动，还要能停下来，那才是真本事 public abstract void stop; //喇叭会出声音，是滴滴叫，还是哔哔叫 public abstract void alarm; //引擎会轰隆隆地响，不响那是假的 public abstract void engineBoom; //那模型应该会跑吧，别管是人推的，还是电力驱动，总之要会跑 public void run{ //先发动汽车 this.start; //引擎开始轰鸣 this.engineBoom; //然后就开始跑了，跑的过程中遇到一条狗挡路，就按喇叭 this.alarm; //到达目的地就停车 this.stop; }} 在抽象的悍马模型上已经定义了run方法的执行规则，先启动，然后引擎立刻轰鸣，中间还要按一下喇叭，制造点噪声（要不就不是名车了）。然后停车，它的两个具体实现类就不需要实现run方法了，只要把代码清单10-2、代码清单10-3上的run方法删除即可，不再赘述代码。
场景类实现的任务就是把生产出的模型展现给客户，其源代码如代码清单10-5所示。
代码清单10-5 场景类
public class Client { public static void main(String args) { //XX公司要H1型号的悍马 HummerModel h1 = new HummerH1Model; //H1模型演示 h1.run; }} 运行结果如下所示。
悍马H1发动...
悍马H1引擎声音是这样的...
悍马H1鸣笛...
悍马H1停车...
目前客户只要看H1型号的悍马车，没问题，生产出来，同时可以运行起来给他看看。非常简单，那如果我告诉你这就是模板方法模式你会不会很不屑呢？就这模式，太简单了，我一直在使用呀！是的，你经常在使用，但你不知道这是模板方法模式，那些所谓的高手就可以很牛地说：“用模板方法模式就可以实现”，你还要很崇拜地看着，哇，牛人，模板方法模式是什么呀？这就是模板方法模式。