我先设计个类图:
非常简单的实现,你要悍马模型,我就给你悍马模型,先写个抽象类,然后两个不同型号的模型实现类,那我们把这个程序实现出来:
HummerModel抽象类的程序清单如下:
H1型号悍马的定义如下:
然后看悍马H2型号的实现:
然后程序写到这里,你就看到问题了,run方法的实现应该在抽象类上,不应该在实现类上,好,我们修改一下类图和实现:
就把run方法放到了抽象类中,那代码也相应的改变一下,先看HummerModel.java:
下面是HummerH1Model.java程序清单:
下面是HummerH2Model.java的程序清单:
类图修改完毕了,程序也该好了,提交给老大,老大一看,挺好,就开始生产了,并提交给客户使用了,那客户是如何使用的呢?类图上增加一个Client类,就是客户,我们这个是用main函数来代替他使用,类图如下:
然后看增加的Client.java程序,非常的简单:
非常非常的简单,那如果我告诉这就是模板方法模式你会不会很不屑呢?就这模式,太简单了,我一直在使用呀,是的,你经常在使用,但你不知道这是模板方法模式,那些所谓的高手就可以很牛X的说“用模板方法模式就可以实现…”,你还要很崇拜的看着,哇,牛人,模板方法模式是什么呀?
然后我们继续回顾我们这个模型,回头一想,不对呀,需求分析的有点问题,客户要关心模型的启动,停止,鸣笛,引擎声音吗?他只要在run的过程中,听到或看都成了呀,暴露那么多的方法干啥?好了,我们重新修改一下类图:
![](http://hi.csdn.net/attachment/201101/26/0_1296052427vVyV.gif)
把抽象类上的四个方法设置为protected访问权限,好了,既然客户不关心这几个方法,而且这四个方法都是由子类来实现的,那就设置成protected模式。咦~,那还有个缺陷,run方法既然子类都不修改,那是不是可以设置成final类型呢?是滴是滴,类图如下:
好了,这才是模板方法模式,就是这个样子,我们只要修改抽象类代码就可以了,HummerModel.java程序清单如下:
其他的子类都不用修改(如果要修改,就是把四个方法的访问权限由public修改protected),大家请看这个run方法,他定义了调用其他方法的顺序,并且子类是不能修改的,这个叫做模板方法;start、stop、alarm、engineBoom这四个方法是子类必须实现的,而且这四个方法的修改对应了不同的类,这个叫做基本方法,基本方法又分为三种:在抽象类中实现了的基本方法叫做具体方法;在抽象类中没有实现,在子类中实现了叫做抽象方法,我们这四个基本方法都是抽象方法,由子类来实现的;还有一种叫做钩子方法,这个等会讲。到目前为止,这两个模型都稳定的运行,突然有一天,老大又找到了我,“客户提出新要求了,那个喇叭想让它响就响,你看你设计的模型,车子一启动,喇叭就狂响,赶快修改一下”,确实是设计缺陷,呵呵,不过是我故意的,那我们怎么修改呢?看修改后的类图:
增加一个方法,isAlarm(),喇嘛要不要响,这就是钩子方法(Hook Method),那我们只要修改一下抽象类就可以了:
钩子方法模式是由抽象类来实现的,子类可以重写的,H2型号的悍马是不会叫的,喇叭是个摆设,看HummerH2Model.java代码:
那H2型号的模型都没有喇叭,就是按了喇叭也没有声音,那客户端这边的调用没有任何修改,出来的结果就不同,我们先看Client.java程序:
那H1又有所不同了,它的喇叭要不要响是由客户来决定,其实在类图上已经标明了setAlarm这个方法,我们看HummerH1Model.java的代码:
这段代码呢修改了两个地方,一是重写了父类的isAlarm()方法,一是增加了一个setAlarm方法,由调用者去决定是否要这个功能,也就是喇叭要不要滴滴答答的响,哈哈,那我们看看Client.java的修改:
看到没,这个模型run起来就有声音了,那当然把h1.setAlarm(false)运行起来喇叭就没有声音了,钩子方法的作用就是这样滴。