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