走进设计模式之——模板模式（Template）

在面向对象系统的分析与设计过程中经常会遇到这样一种情况：对于某一个业务逻辑（算法实现）在不同的对象中有不同的细节实现，但是逻辑（算法）的框架（或通用的应用算法）是相同的。Template提供了这种情况的一个实现框架，它定义一个操作中的算法的骨架，而将步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义算法的某些特定步骤。（Define
the skeleton of an algorithm in an operation, deferring somesteps to subclasses. Template Method lets subclasses redefine certain steps ofan algorithm without changing the algorithm's structure。）
Template模式是采用继承的方式实现这一点：将逻辑（算法）框架放在抽象基类中，并定义好细节的接口，子类中实现细节。他的结构图如图1所示。



图1：Template模式结构图

抽象类（AbstractClass）：实现了模板方法，定义了算法的骨架。
具体类（ConcreteClass)：实现抽象类中的抽象方法，已完成完整的算法。

Template模式实际上就是利用面向对象中多态的概念实现算法实现细节和高层接口的松耦合。Template模式采取的是继承方式实现这一点的，由于继承是一种强约束性的条件，因此也给Template模式带来一定的限制。

有一个实现的原型代码，一直上传不上附件，后面传上。

Template模式是很简单模式，但是也应用很广的模式。如上面的分析和实现中阐明的Template是采用继承的方式实现算法的异构，其关键点就是将通用算法封装在抽象基类中，并将不同的算法细节放到子类中实现。

Template模式获得一种反向控制结构效果，这也是面向对象系统的分析和设计中一个原则DIP（依赖倒置：Dependency Inversion Principles）。其含义就是父类调用子类的操作（高层模块调用低层模块的操作），低层模块实现高层模块声明的接口。这样控制权在父类（高层模块），低层模块反而要依赖高层模块。

继承的强制性约束关系也让Template模式有不足的地方，我们可以看到对于ConcreteClass类中的实现的原语方法Primitive1()，是不能被别的类复用。假设我们要创建一个AbstractClass的变体AnotherAbstractClass，并且两者只是通用算法不一样，其原语操作想复用AbstractClass的子类的实现。但是这是不可能实现的，因为ConcreteClass继承自AbstractClass，也就继承了AbstractClass的通用算法，AnotherAbstractClass是复用不了ConcreteClass的实现，因为后者不是继承自前者。

Template模式暴露的问题也正是继承所固有的问题，Strategy模式则通过组合（委托）来达到和Template模式类似的效果，其代价就是空间和时间上的代价，关于Strategy模式的详细讨论请参考Strategy模式解析。

模板模式的优点有如下：

封装不变部分，扩展可变部分

把认为是不变部分的算法封装到父类实现，而可变部分的则可以通过继承来继续扩展。

提取公共部分代码，便于维护

行为控制交由子类来实现

基本方法是由子类实现的，因此子类可以通过扩展的方式增加相应的功能，符合开闭原则。

缺点

破坏了封装性，继承中父类的实现细节暴露给子类了；
“白盒”复用，原因在1）中；
当父类的实现更改时，其所有子类将不得不随之改变
从父类继承而来的实现在运行期间不能改变（编译期间就已经确定了）。