设计模型之模板方法模式
1. 模板方法模式
1.1 定义与特点
定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。它是一种类行为型模式。
该模式的主要优点如下：
- 它封装了不变部分，扩展可变部分。它把认为是不变部分的算法封装到父类中实现，而把可变部分算法由子类继承实现，便于子类继续扩展。
- 它在父类中提取了公共的部分代码，便于代码复用。
- 部分方法是由子类实现的，因此子类可以通过扩展方式增加相应的功能，符合开闭原则。
该模式的主要缺点如下：
- 对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。
- 父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度。
1.2 模式的结构
模板方法模式包含以下主要角色：
(1) 抽象类（Abstract Class）：负责给出一个算法的轮廓和骨架。它由一个模板方法和若干个基本方法构成。这些方法的定义如下：
① 模板方法：定义了算法的骨架，按某种顺序调用其包含的基本方法。
② 基本方法：是整个算法中的一个步骤，包含以下几种类型：
抽象方法：在抽象类中申明，由具体子类实现。
具体方法：在抽象类中已经实现，在具体子类中可以继承或重写它。
钩子方法：在抽象类中已经实现，包括用于判断的逻辑方法和需要子类重写的空方法两种。
(2) 具体子类（Concrete Class）：实现抽象类中所定义的抽象方法和钩子方法，它们是一个顶级逻辑的一个组成步骤。
1.3 问题由来
在代码设计中，我们把一些业务规定为流程或格式的实例定义成模板(列如人每天会起床、吃饭、做事、睡觉)，允许使用者根据自己的需求去更新它。在代码设计实现中，把通用流程抽象出为一系列方法，但是每一个子类都重新实现这些方法，这种设计实现不合理。就好像生活中，一个人每天会起床、吃饭、做事、睡觉等，其中“做事”的内容每天可能不同。这个时候起床、吃饭、睡觉是不用重新实现的，做事要重新实现。如果每个人对象都重写这4个方法，就不合理了，只需要重新实现一个方法。
1.4 解决思路
把一些些业务规定为流程或格式的实例定义成模板(列如人每天会起床、吃饭、做事、睡觉)，允许使用者根据自己的需求去更新它。在代码设计实现中，把通用流程或者说模板抽象出来，它封装了不变部分，扩展可变部分。它把认为是不变部分的算法封装到父类中实现，而把可变部分算法由子类继承实现，这样当具体子类实现抽象父类，可变部分算法由子类继承实现，不变部分的算法直接继承就可以了，达到目的。
1.5 UML类图
1.6 解决方案
/**
* @author tbb
* 抽象人
*/
public abstract class AbstractPerson
{
public void eat()
{
System.out.println("吃饭");
}
public void sleep()
{
System.out.println("睡觉");
}
public void getUp()
{
System.out.println("起床");
}
abstract void handleAffairs();
public void templateMethod()
{
eat();
getUp();
handleAffairs();
sleep();
}
}
public class Student extends AbstractPerson
{
@Override
void handleAffairs()
{
System.out.println("上课");
}
}
public class Teacher extends AbstractPerson
{
@Override
void handleAffairs()
{
System.out.println("讲课");
}
}
public class Test
{
public static void main(String[] args)
{
Teacher teacher = new Teacher();
teacher.templateMethod();
/*
吃饭
起床
讲课
睡觉
*/
Student student = new Student();
student.templateMethod();
/*
吃饭
起床
上课
睡觉
*/
}
}
