模板方法模式

一.定义

模板方法模式(Template Method Pattern〉是如此简单,以致让你感觉你已经能够掌握其精髓了。其定义如下:
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.Template Method lets subclasses redefine certain steps of an algorithm without changing thealgorithm’s structure. (定义一个操作中的算法的框架,而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。)模板方法模式的通用类图如图所示:
模板方法模式_第1张图片
AbstrctClass叫做抽象模板,它的方法分为两类:
基本方法
基本方法也叫做基本操作,是由子类实现的方法,并且在模板方法被调用。模板方法
可以有一个或几个,一般是一个具体方法,也就是一个框架,实现对基本方法的调度,完成固定的逻辑。
在类图中还有一个角色:具体模板。ConcreteClass1和ConcreteClass2属于具体模板,实现父类所定义的一个或多个抽象方法,也就是父类定义的基本方法在子类中得以实现。
抽象模板类

模板方法模式_第2张图片
具体模板类
模板方法模式_第3张图片
具体场景类
模板方法模式_第4张图片

二.例子

我具体用一个例子来说明,模板方法模式,大家请看下面的小故事
周三,9:00,我刚刚坐到位置上,打开电脑准备开始干活。
“小三,小三,叫一下其他同事,到会议室开会”,老大跑过来吼,带着坏笑。还没等大家坐稳,老大就开讲了:
“告诉大家一个好消息,昨天终于把XX模型公司的口子打开了,要我们做悍马模型,虽然是第一个车辆模型,但是我们有能力、有信心做好,我们一定要……”(中间省略20分钟的讲话,如果你听过领导人的讲话,这个你应该能够续上)
动员工作做完了,那就开始压任务了。“这次时间是非常紧张的,只有一个星期的时间,小三,你负责在一个星期的时间把这批10万车模(注:车模是车辆模型的意思,不是香车美女那个车模)建设完成……”
“一个星期?这个……是真做不完,要做分析,做模板,做测试,还要考虑扩展性、稳定性、健壮性等,时间实在是太少了”,还没等老大说完,我就急了,再不急我的小命就折在上面了!
“那这样,只做最基本的实现,不考虑太多的问题,怎么样?”老大又把我弹回去了。“只作基本实现?那……”
唉,领导已经布置任务了,那就开始拼命地做吧。然后就开始准备动手做,在做之前先介绍一下我们公司的背景,我们公司是做模型生产的,做过桥梁模型、建筑模型、机械模型,甚至是一些政府、军事的机密模型,这个不能细说,绝密。公司的主要业务就是把实物按照一定的比例缩小或放大,用于试验、分析、量化或者是销售,等等,上面提到的XX模型公司是专门销售车辆模型的公司,自己没有生产企业,全部是代工。我们公司是第一次从XX模型公司接单,那我怎么着也要把活干好,可时间有限,任务量又巨大,怎么办?

我们先设计基本的类图结构
模板方法模式_第5张图片
非常简单的实现,悍马车有两个型号,H1和H2。按照需求,只需要悍马模型,那好我就给你悍马模型,先写个抽象类,然后两个不同型号的模型实现类,通过简单的继承就可以实现业务要求。我们先从抽象类开始编写,抽象悍马模型如代码清单如下:
抽象悍马模型
模板方法模式_第6张图片
H1悍马模型
模板方法模式_第7张图片
H2悍马模型
模板方法模式_第8张图片

好了,程序编写到这里,已经发现问题了,两个实现类的run()方法都是完全相同的,那这个run()方法的实现应该出现在抽象类,不应该在实现类上,抽象是所有子类的共性封装。
修改后的类图
模板方法模式_第9张图片

修改后的抽象悍马模型
模板方法模式_第10张图片

在抽象的悍马模型上已经定义了run方法的执行规则,先启动,然后引擎立刻轰鸣,中间还要按一下喇叭,制造点噪声(要不就不是名车了)。然后停车,它的两个具体实现类就不需要实现run方法了,只要把上述代码的run()方法删除即可,不再赘述代码。

场景类
模板方法模式_第11张图片
目前客户只要看H1型号的悍马车,没问题,生产出来,同时可以运行起来给他看看。非常简单,那如果我告诉你这就是模板方法模式你会不会很不屑呢?就这模式,太简单了,我一直在使用呀!是的,你经常在使用,但你不知道这是模板方法模式,那些所谓的高手就可以很牛地说:“用模板方法模式就可以实现”,你还要很崇拜地看着,哇,牛人,模板方法模式是什么呀?这就是模板方法模式。

三.结论

优点

  • 封装不变部分,扩展可变部分
    把认为是不变部分的算法封装到父类实现,而可变部分的则可以通过继承来继续扩展。在悍马模型例子中,是不是就非常容易扩展?例如增加一个H3型号的悍马模型,很容易呀,增加一个子类,实现父类的基本方法就可以了。
  • 提取公共部分代码,便于维护
    我们例子中刚刚走过的弯路就是最好的证明,如果我们不抽取到父类中,任由这种散乱的代码发生,想想后果是什么样子?维护人员为了修正一个缺陷,需要到处查找类似的代码!
  • 行为由父类控制,子类实现
    基本方法是由子类实现的,因此子类可以通过扩展的方式增加相应的功能,符合开闭原则。

缺点

按照我们的设计习惯,抽象类负责声明最抽象、最一般的事物属性和方法,实现类完成具体的事物属性和方法。但是模板方法模式却颠倒了,抽象类定义了部分抽象方法,由子类实现,子类执行的结果影响了父类的结果,也就是子类对父类产生了影响,这在复杂的项目中,会带来代码阅读的难度,而且也会让新手产生不适感。

使用场景

多个子类有公有的方法,并且逻辑基本相同时。
重要、复杂的算法,可以把核心算法设计为模板方法,周边的相关细节功能则由各个子类实现。
重构时,模板方法模式是一个经常使用的模式,把相同的代码抽取到父类中,然后通过钩子函数(见“模板方法模式的扩展”)约束其行为。

你可能感兴趣的:(设计模式,模板方法模式)