行为型模式——模板方法(Template Method)
问题背景
当一些算法都遵循同一套流程,只有部分细节不同时,考虑使用模板方法。现在有一套窗口,它们在关闭时都执行这样一系列操作:重置窗口状态,播放关闭动画,将窗口设为disabled状态(不工作,但仍然在内存中)。在这三个步骤中,重置窗口状态是一样的,递归重置子控件的状态;播放关闭动画是不一样的,有的是逐渐透明淡出,有的是变小最后消失,还有的是飞出屏幕…之后的禁用操作也是一样的。三个步骤中有两个都是一样的,如果每次创建子类都让它们自己实现这三个行为,就会出现代码重复,同时也无法保证整个流程的强制实施。
解决方案
我们将易变的那一块逻辑提炼成一个虚方法,延迟到子类实现(当然也可以在父类中提供缺省实现)。于是,程序结构就变成这样:
这样,播放动画的逻辑就延迟到了子类,不同的窗口就能播放不同的动画了。同时,整个关闭流程由父类控制,保证了每个步骤都会执行。
模板方法还可以实现一些非常好玩的功能。比如,我们可以将核心业务逻辑延迟到子类实现,而把一些和业务无关的逻辑放在父类中(日志、权限等),这样可以实现简单的AOP;我们还可以在各个步骤之间插入一些空的虚函数,从而支持子类拦截流程中的每个步骤来作特殊处理,这样就实现了简单的Hook。
效果
- 实现了代码复用。
- 反转了控制流,由父类调用子类,因而能用来实现一些控制反转的效果。
缺陷
模板方法是一个非常好的模式,它的用途非常广泛,几乎没什么明显的缺陷。但是随着软件开发的工程化,开发者对模块化的需求越来越迫切,标准的(基于继承的)模板方法已经满足不了开发者的需求了,因为继承会不可避免地造成耦合。相比继承,反射更受框架青睐。由于反射的行为都是在运行时确定的,因此不会造成代码上的耦合,这也就使程序的移植工作变得非常轻松。模板方法也有反射版本,会在后面介绍。
相关模式
- 工厂方法:模板方法中的可变部分经常会是个工厂方法。
- 策略:模板方法和策略其实是等价的,因为他俩就是同一个效果的继承实现和组合实现。
实现
using System;
namespace TemplateMethod
{
class Client
{
public class Window
{
public void Close