还是在我刚刚分析完源码的JUnit中找个例子吧。JUnit中的TestCase以及它的子类就是一个模板方法模式的例子。在TestCase这个抽象类中将整个测试的流程设置好了,比如先执行Setup方法初始化测试前提,在运行测试方法,然后再TearDown来取消测试设置。但是你将在Setup、TearDown里面作些什么呢?鬼才知道呢!!因此,而这些步骤的具体实现都延迟到子类中去,也就是你实现的测试类中。
来看下相关的源代码吧。
这是TestCase中,执行测试的模板方法。你可以看到,里面正像前面定义中所说的那样,它制定了“算法”的框架——先执行setUp方法来做下初始化,然后执行测试方法,最后执行tearDown释放你得到的资源。
来看下相关的源代码吧。
这是TestCase中,执行测试的模板方法。你可以看到,里面正像前面定义中所说的那样,它制定了“算法”的框架——先执行setUp方法来做下初始化,然后执行测试方法,最后执行tearDown释放你得到的资源。
public void runBare() throws Throwable { setUp(); try { runTest(); } finally { tearDown(); } } |
这就是上面使用的两个方法。与定义中不同的是,这两个方法并没有被实现为抽象方法,而是两个空的无为方法(被称为钩子方法)。这是因为在测试中,我们并不是必须要让测试程序使用这两个方法来初始化和释放资源的。如果是抽象方法,则子类们必须给它一个实现,不管用到用不到。这显然是不合理的。使用钩子方法,则你在需要的时候,可以在子类中重写这些方法。
可以看出,使用模板方法模式可以将代码的公共行为提取出来,达到复用的目的。而且,在模板方法模式中,是由父类的模板方法来控制子类中的具体实现。这样你在实现子类的时候,根本不需要对业务流程有太多的了解。
子类的实现可以不关注业务流程