设计模式-模板方法
模板方法
模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤的实现延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中某些步骤的具体实现。
例子
现在我家里有一台铃木的小车锋驭和一台铃木的摩托车风暴1000，我要想把这两种类型的车都先跑起来再停下来，有一些步骤，并且这些步骤是有先后顺序的，那就是：
1. 打开车门
2. 启动发动机
3. 挂档
4. 走起
5. 刹车
6. 停车
OO设计原则之一就是分离可变和不变的部分并把可变的部分封装起来，我们来看一下以上两种类型的车，哪些步骤的实现是一样的，哪些是可变的。我们把不变的部分提取出来并放到超类中让所有子类共享其行为，同时我们把可变部分的具体实现延迟到子类中，让子类来自行决定如何实现。
1. 打开车门（摩托车没有车门，可变部分）
2. 启动发动机（不变部分）
3. 挂档（汽车用手挂档，摩托车用脚挂档，可变部分）
4. 走起（不变部分）
5. 刹车（汽车用脚刹车，摩托车用手刹车，可变部分）
6. 停车（不变部分）
当然以上分离可变及不变部分纯属个人见解，个位看官见仁见智。
如果运用设计模式的方法论，我们应该采用哪种模式来很好地满足我们的需求？
在这种应用场景下我建议使用模板方法模式。
基于以上UML类图我需要说明几点模板方法的设计意图：
-
DriveTemplate是一个抽象类，我们可以把一些可变的部分封装为抽象方法让子类去做具体实现。
-
DriveTemplate中的drive方法是final的，这样是因为我们不希望子类去覆盖这个方法，因为这个方法中定义了算法的步骤，我们不希望子类改变算法的结构。
-
所有的步骤方法都是protected的访问修饰符，因为我们希望具体算法的实现只有子类可以访问，对外是不开放的。
代码
模板抽象类
package com.singland.dp.template;
public abstract class DriveTemplate {
public final void drive() {
openDoor();
startEngine();
gear();
go();
brake();
stop();
}
protected abstract void openDoor();
protected void startEngine() {
System.out.println("engine started !");
}
protected abstract void gear();
protected void go() {
System.out.println("running...");
}
protected abstract void brake();
protected void stop() {
System.out.println("stopped !");
}
}
小车锋驭的实现
package com.singland.dp.template;
public class SuzukiScross extends DriveTemplate {
@Override
protected void openDoor() {
System.out.println("keyless entry");
}
@Override
protected void gear() {
System.out.println("gear with hand");
}
@Override
protected void brake() {
System.out.println("brake with foot");
}
}
摩托车风暴1000的具体实现
package com.singland.dp.template;
public class SuzukiStrom1000 extends DriveTemplate {
@Override
protected void openDoor() {
System.out.println("no door actually");
}
@Override
protected void gear() {
System.out.println("gear with foot");
}
@Override
protected void brake() {
System.out.println("brake with hand");
}
}
客户端的测试代码就很简单了
package com.singland.dp.template;
import org.junit.Test;
public class MyTest {
@Test
public void test() {
// DriveTemplate template = new SuzukiStrom1000();
DriveTemplate template = new SuzukiScross();
template.drive();
}
}
刚才说到模板方法模式的设计意图的时候，我们提到了第2点，我们不希望子类改变算法的结构或顺序，但是在某种场景中，我们希望子类能有一些自主权，虽然它们不能覆盖drive方法，但是我们依然希望子类可以自己决定一些东西，那么模板方法模式能否满足这一需求呢？
答案是肯定的，我们来设想这种场景，当我们在开锋驭的时候，我希望可以打开车子的MP3功能来听歌，但是骑摩托车的时候则不需要。
这样我们的UML类图就需要做一点点小改动：
从类图可以看出，我们在超类中定义了一个music的方法，但是它并不是一个抽象方法，这样子类可以自己决定是否覆盖该方法，该方法返回值是一个布尔值的标志位，默认为false. 子类SuzukiScross覆盖了该方法但是SuzukiStorm1000则没有，我们再来看看具体的实现：
模板方法类
package com.singland.dp.template;
public abstract class DriveTemplate {
public final void drive() {
openDoor();
startEngine();
gear();
go();
if (music()) {
mp3();
}
brake();
stop();
}
protected abstract void openDoor();
protected void startEngine() {
System.out.println("engine started !");
}
protected abstract void gear();
protected void go() {
System.out.println("running...");
}
private void mp3() {
System.out.println("music is good");
}
protected boolean music() {
return false;
}
protected abstract void brake();
protected void stop() {
System.out.println("stopped !");
}
}
锋驭的实现：
package com.singland.dp.template;
public class SuzukiScross extends DriveTemplate {
@Override
protected void openDoor() {
System.out.println("keyless entry");
}
@Override
protected void gear() {
System.out.println("gear with hand");
}
@Override
protected void brake() {
System.out.println("brake with foot");
}
@Override
protected boolean music() {
return true;
}
}
总结
写到这里，我来个简单的总结吧。本质上来说，模板方法设计模式是一个比较容易而且很好理解的模式，在
使用这种模式的时候我们要注意几点：
-
保护抽象类中定义算法顺序的方法不被子类修改。
-
分离可变及不可变部分，让子类自己决定可变部分的实现。
-
让算法的具体实现对子类开放，对其他类关闭。
JDBC使用模板方法
todo
参考文献
设计模式学习笔记之九：模板方法模式