（22）行为型模式——模板方法

行为型模式——模板方法（Template Method）

问题背景

当一些算法都遵循同一套流程，只有部分细节不同时，考虑使用模板方法。现在有一套窗口，它们在关闭时都执行这样一系列操作：重置窗口状态，播放关闭动画，将窗口设为disabled状态（不工作，但仍然在内存中）。在这三个步骤中，重置窗口状态是一样的，递归重置子控件的状态；播放关闭动画是不一样的，有的是逐渐透明淡出，有的是变小最后消失，还有的是飞出屏幕…之后的禁用操作也是一样的。三个步骤中有两个都是一样的，如果每次创建子类都让它们自己实现这三个行为，就会出现代码重复，同时也无法保证整个流程的强制实施。

解决方案

我们将易变的那一块逻辑提炼成一个虚方法，延迟到子类实现（当然也可以在父类中提供缺省实现）。于是，程序结构就变成这样：

这样，播放动画的逻辑就延迟到了子类，不同的窗口就能播放不同的动画了。同时，整个关闭流程由父类控制，保证了每个步骤都会执行。

模板方法还可以实现一些非常好玩的功能。比如，我们可以将核心业务逻辑延迟到子类实现，而把一些和业务无关的逻辑放在父类中（日志、权限等），这样可以实现简单的AOP；我们还可以在各个步骤之间插入一些空的虚函数，从而支持子类拦截流程中的每个步骤来作特殊处理，这样就实现了简单的Hook。

效果

1. 实现了代码复用。
2. 反转了控制流，由父类调用子类，因而能用来实现一些控制反转的效果。

缺陷

模板方法是一个非常好的模式，它的用途非常广泛，几乎没什么明显的缺陷。但是随着软件开发的工程化，开发者对模块化的需求越来越迫切，标准的（基于继承的）模板方法已经满足不了开发者的需求了，因为继承会不可避免地造成耦合。相比继承，反射更受框架青睐。由于反射的行为都是在运行时确定的，因此不会造成代码上的耦合，这也就使程序的移植工作变得非常轻松。模板方法也有反射版本，会在后面介绍。

相关模式

1. 工厂方法：模板方法中的可变部分经常会是个工厂方法。
2. 策略：模板方法和策略其实是等价的，因为他俩就是同一个效果的继承实现和组合实现。

实现

using System;

namespace TemplateMethod
{
   
    class Client
    {
   
        public class Window
        {
   
            public void Close