（点击上方公众号，可快速关注）
来源：cashow，
cashow.github.io/head-first-design-patterns-notes-template-method-pattern.html
如有好文章投稿，请点击 → 这里了解详情
模板方法模式在一个方法中定义了一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
有些人没有咖啡就活不下去；有些人则离不开茶。两者共同的成分是什么？当然是咖啡因了！
但还不只这样。茶和咖啡的冲泡方式非常相似：
星巴兹咖啡冲泡法
把水煮沸
用沸水冲泡咖啡
把咖啡倒进杯子
加糖和牛奶
星巴兹茶冲泡法
把水煮沸
用沸水冲泡茶叶
把茶倒进杯子
加柠檬
下面我们用代码来创建咖啡和茶：
// 这是我们的咖啡类，用来煮咖啡
public class Coffee {
// 这是我们的咖啡冲泡法
void prepareRecipe() {
boilWater();
brewCoffeeGrinds();
pourInCup();
addSugerAndMilk();
}
// 煮沸水
private void boilWater() {
System.out.println("Boiling water");
}
// 冲泡咖啡
private void brewCoffeeGrinds() {
System.out.println("Dripping coffee through filter");
}
// 把咖啡倒进杯子
private void pourInCup() {
System.out.println("Pouring into cup");
}
// 加糖和奶
private void addSugerAndMilk() {
System.out.println("Adding Sugar and Milk");
}
}
// 这是我们的茶类，用来煮茶
public class Tea {
void prepareRecipe() {
boilWater();
steepTeaBag();
pourInCup();
addLemon();
}
// 煮沸水。这个方法和咖啡类完全一样
private void boilWater() {
System.out.println("Boiling water");
}
// 冲泡茶叶
private void steepTeaBag() {
System.out.println("Steeping the tea");
}
// 把茶倒进杯子。这个方法和咖啡类完全一样
private void pourInCup() {
System.out.println("Pouring into cup");
}
// 加柠檬
private void addLemon() {
System.out.println("Adding Lemon");
}
}
我们发现了重复的代码，这表示我们需要清理一下设计了。在这里，茶和咖啡是如此得相似，似乎我们应该将共同的部分抽取出来，放进一个基类中。
第一版设计
看起来这个咖啡和茶的设计相当简单，你的第一版设计，可能看起来像这样：
public abstract class CaffeineBeverage {
// prepareRecipe()方法在每个类中都不一样，所以定义成抽象方法。
abstract void prepareRecipe();
// 以下两个方法被两个子类所共享，所以被定义在这个超类中
public void boilWater() {
System.out.println("Boiling water");
}
public void pourInCup() {
System.out.println("Pouring into cup");
}
}
public class Coffee extends CaffeineBeverage {
void prepareRecipe() {
boilWater();
brewCoffeeGrinds();
pourInCup();
addSugerAndMilk();
}
private void brewCoffeeGrinds() {
System.out.println("Dripping coffee through filter");
}
private void addSugerAndMilk() {
System.out.println("Adding Sugar and Milk");
}
}
public class Tea extends CaffeineBeverage {
void prepareRecipe() {
boilWater();
steepTeaBag();
pourInCup();
addLemon();
}
private void steepTeaBag() {
System.out.println("Steeping the tea");
}
private void addLemon() {
System.out.println("Adding Lemon");
}
}
更进一步的设计
以上的设计是不是忽略了某些其他的共同点？咖啡和茶之间还有什么是相似的？
注意到两份冲泡法都采用了相同的算法：
1. 把水煮沸
2. 用热水泡咖啡或茶
3. 把饮料倒进杯子
4. 在饮料中加入适当的调料
其中，第2步和第4步并没有被抽取出来，但他们是一样的，只是应用在了不同的饮料上。我们有办法把prepareRecipe()方法也抽象化吗？让我们先从每一个子类中逐步抽象prepareRecipe()。
抽象prepareRecipe()
我们遇到的第一个问题就是，咖啡使用brewCoffeeGrinds()和addSugerAndMilk()方法，而茶使用steepTeaBag()和addLemon()方法。让我们思考这一点：浸泡(steep)和冲泡(brew)差异其实不大。所以我们给它一个新的方法名称，比方说brew()，然后不管是泡茶或者冲泡咖啡我们都用这个名称。类似地，加糖和牛奶都是在饮料中加入调料。让我们也给它一个新的方法名称：addCondiments()。这样一来，新的prepareRecipe()方法看起来像是这样：
void prepareRecipe() {
boilWater();
brew();
pourInCup();
addCondiments();
}
现在我们有了新的prepareRecipe()方法，但是需要让它能够符合代码。要想这么做，我们先从CaffeineBeverage超类开始：
public abstract class CaffeineBeverage {
// 现在，用同一个prepareRecipe()方法来处理茶和咖啡。
// prepareRecipe()方法被声明为final，因为我们不希望子类覆盖这个方法
// 我们将第2步和第4步泛化成为brew()和addCondiments()
final void prepareRecipe() {
boilWater();
brew();
pourInCup();
addCondiments();
}
// 因为咖啡和茶处理这些方法的做法不同，所以这两个方法必须被声明为抽象，
// 剩余的东西留给子类去操心
abstract void addCondiments();
abstract void brew();
public void boilWater() {
System.out.println("Boiling water");
}
public void pourInCup() {
System.out.println("Pouring into cup");
}
}
最后，我们需要处理咖啡和茶类，这两个类现在都是依赖超类来处理冲泡法，所以只需要自行处理冲泡和添加调料部分：
public class Coffee extends CaffeineBeverage {
@Override
void brew() {
System.out.println("Dripping coffee through filter");
}
@Override
void addCondiments() {
System.out.println("Adding Sugar and Milk");
}
}
public class Tea extends CaffeineBeverage {
@Override
void brew() {
System.out.println("Steeping the tea");
}
@Override
void addCondiments() {
System.out.println("Adding Lemon");
}
}
认识模板方法
基本上，我们刚刚实现的就是模板方法模式。咖啡因饮料类的结构包含了实际的“模板方法”：prepareRecipe()方法。为什么？ 因为：
毕竟它是一个方法。
它用作一个算法的模板，在这个例子中，算法是用来制作咖啡因饮料的。
在这个模板中，算法内的每一个步骤都被一个方法代表了。某些方法是由这个类（也就是超类）处理的，某些方法则是由子类处理的。需要由子类提供的方法，必须在超类中声明为抽象。
模板方法定义了一个算法的步骤，并允许子类为一个或多个步骤提供实现。
模板方法带给我们什么？
定义模板方法模式
你已经看到了茶和咖啡的例子中如何使用模板方法模式。现在，就让我们来看看这个模式的正式定义和所有的细节：
模板方法模式在一个方法中定义了一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
这个模式是用来创建一个算法的模板。什么是模板？如你所见的，模板就是一个方法。更具体地说，这个方法将算法定义成一组步骤，其中的任何步骤都可以是抽象的，由子类负责实现。这可以确保算法的结构保持不变，同时由子类提供部分实现。
让我们细看抽象类是如何被定义的，包括了它内含的模板方法和原语操作。
// 这就是我们的抽象类。它被声明为抽象，用来作为基类，其子类必须实现其操作
public abstract class AbstractClass {
// 这就是模板方法。它被声明为final，以免子类改变这个算法的顺序。
final void templateMethod() {
// 模板方法定义了一连串的步骤，每个步骤由一个方法代表
primitiveOperation1();
primitiveOperation2();
concreteOperation();
}
// 在这个范例中有两个原语操作，具体子类必须实现它们
abstract void primitiveOperation1();
abstract void primitiveOperation2();
// 这个抽象类有一个具体的操作。
void concreteOperation() {
// ...
}
}
现在我们要“更靠近一点”，详细看看此抽象类内可以有哪些类型的方法：
public abstract class AbstractClass {
final void templateMethod() {
primitiveOperation1();
primitiveOperation2();
concreteOperation();
// 我们加进一个新方法调用
hook();
}
// 这两个方法还是和以前一样，定义成抽象，由具体的子类实现。
abstract void primitiveOperation1();
abstract void primitiveOperation2();
// 这个具体的方法被定义在抽象类中。
// 将它声明为final，这样一来子类就无法覆盖它。
// 它可以被模板方法直接使用，或者被子类使用。
final void concreteOperation() {
// ...
}
// 我们也可以有“默认不做事的方法”，我们称这种方法为“hook”（钩子）。
// 子类可以视情况决定要不要覆盖它们。在下面，我们就会知道钩子的实际用途
void hook() {}
}
对模板方法进行挂钩
钩子是一种被声明在抽象类中的方法，但只有空的或者默认的实现。钩子的存在，可以让子类有能力对算法的不同点进行挂钩。要不要挂钩，由子类决定。
钩子有好几种用途，让我们先看其中一个，稍后再看其他几个：
public abstract class CaffeineBeverageWithHook {
final void prepareRecipe() {
boilWater();
brew();
pourInCup();
// 我们加上了一个小小的条件语句，而该条件是否成立，
// 是由一个具体方法customerWantsCondiments()决定的。
// 如果顾客“想要”调料，只有这时我们才调用addCondiments()。
if (customerWantsCondiments()) {
addCondiments();
}
}
abstract void addCondiments();
abstract void brew();
public void boilWater() {
System.out.println("Boiling water");
}
public void pourInCup() {
System.out.println("Pouring into cup");
}
// 我们在这里定义了一个方法，（通常）是空的缺省实现。这个方法只会返回true，不做别的事。
// 这就是一个钩子，子类可以覆盖这个方法，但不见得一定要这么做。
boolean customerWantsCondiments() {
return true;
}
}
钩子有几种用法。钩子可以让子类实现算法中可选的部分，或者在钩子对于子类的实现并不重要的时候，子类可以对此钩子置之不理。钩子的另一个用法，是让子类能够有机会对模板方法中某些即将发生的（或刚刚发生的）步骤做出反应。比方说，名为justReOrderList()的钩子方法允许子类在内部列表重新组织后执行某些动作（例如在屏幕上重新显示数据）。正如你刚刚看到的，钩子也可以让子类有能力为其抽象类做一些决定。
好莱坞原则
我们有一个新的设计原则，称为好莱坞原则：
好莱坞原则：别调用（打电话给）我们，我们会调用（打电话给）你。
很容易记吧，但这和OO设计又有什么关系呢？
好莱坞原则可以给我们一种防止“依赖腐败”的方法。当高层组件依赖低层组件，而低层组件又依赖高层组件，而高层组件又依赖边侧组件，而边侧组件又依赖低层组件时，依赖腐败就发生了。在这种情况下，没有人可以轻易地搞懂系统是如何设计的。
在好莱坞原则之下，我们允许低层组件将自己挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些低层组件。换句话说，高层组件对待低层组件的方式是“别调用我们，我们会调用你”。
好莱坞原则和模板方法之间的连接其实还算明显：当我们设计模板方法模式时，我们告诉子类，“不要调用我们，我们会调用你”。怎样才能办到呢？让我们再看一次咖啡因饮料的设计：
CaffeineBeverage是我们的高层组件，它能够控制冲泡法的算法，只有在需要子类实现某个方法时，才调用子类。
饮料的客户代码只依赖CaffeineBeverage抽象，而不依赖具体的Tea或Coffee，这可以减少整个系统的依赖。
Tea和Coffee子类只简单提供brew()和addCondiments()方法的实现细节。如果Tea和Coffee没有先被调用，绝对不会直接调用抽象类。
觉得本文对你有帮助？请分享给更多人
关注「ImportNew」，看技术干货
