设计模式之模板方法模式

2023-10-09 08:17:52

设计模式之模板方法模式

1. 模板方法模式在书中定义：

定义一个操作中算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变算法的结构即可重定义该算法的某些特定步骤。

通俗点的理解就是：完成一件事情，有固定的数个步骤，但是每个步骤根据对象的不同，而实现细节不同；就可以在父类中定义一个完成该事情的总方法，按照完成事件需要的步骤去调用其每个步骤的实现方法。每个步骤的具体实现，由子类完成。

2. 模式中的角色：

抽象父类（AbstractClass）：实现了模板方法，定义了算法的骨架。

具体类（ConcreteClass)：实现抽象类中的抽象方法，即不同的对象的具体实现细节。

3. 实例说明

现在我家里有一台铃木的小车锋驭和一台铃木的摩托车风暴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;
    }
}

总结：本质上来说，模板方法设计模式是一个比较容易而且很好理解的模式，在使用这种模式的时候我们要注意几点：

保护抽象类中定义算法顺序的方法不被子类修改。
分离可变及不可变部分，让子类自己决定可变部分的实现。
让算法的具体实现对子类开放，对其他类关闭，符合“开闭原则”。

4、模板方法的优缺点

4.1 优点

规范了框架, 封装了不变的部分, 扩展了可变的部分. 父类定义框架, 并抽象了公共不变的部分, 子类通过重写扩展完善了框架的实现.
使用了"开闭原则", 对扩展开放, 对修改关闭. 子类可以通过重写父类的抽象方法来扩展父类的实现.
行为集中有父类控制, 规范流程

4.2 缺点

每一种实现都需要定义一个具体实现类, 增加类的数量, 系统更加复杂
继承的缺点, 一旦父类增加一个抽象方法, 所有子类都需要增加. 这一点违背"开闭原则".
父类中的抽象方法由子类实现, 子类的执行结果影响父类, 这种"反向控制"结构, 会增加代码的复杂性。

5、使用场景

算法的整体步骤是固定的，但个别部分容易发生变化时，可以考虑使用模板方法设计模式，将容易发生变化的部分抽象出来，提供给子类去实现。
当多个子类存在公共的行为时，可以将其提取出来并集中到一个公共父类中以避免代码重复。首先，要识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
当需要控制子类的扩展时，模板方法只在特定点调用钩子操作，这样就只允许在这些点进行扩展。
重构时，模板方法模式是一个经常使用到的模式，把相同的代码抽取到父类中，通过钩子函数约束其行为

码农公寓