把书读薄 | 《设计模式之美》设计模式与范式(行为型-模板模式)

928 阅读4分钟

这是我参与8月更文挑战的第1天,活动详情查看: 8月更文挑战

0x0、引言

🤡 掘金8月更文挑战又开始了,肝起!!!本文对应设计模式与范式:行为型(58-59),模板模式 (Template Pattern),用于解决复用和扩展两个问题。

Tips:二手知识加工难免有所纰漏,感兴趣有时间的可自行查阅原文,谢谢。


0x1、定义

原始定义

在操作用中定义算法的框架,将一些步骤推迟到子类中。模板方法模式让子类在不改变数据结构的情况下重新定义算法的某些步骤。

定义解读

定义里的 算法 可以理解为广义上的 业务逻辑,而不特指数据结构和算法中的 算法。算法骨架就是 模板,包含算法骨架的方法就是 模板方法,这也是模板方式模式名字由来。

好像还不是很理解?写个简单例子~


0x2、写个简单例子

还是奶茶店的例子,可以把一杯奶茶的步骤可以分为四步:茶底 → 加奶 → 加料 → 打包,可以抽象为一个接口:

public interface ITea {
    void addTeaBase();
    void addMilk();
    void addIngredient();
    void pack();
}

定义一种具体的奶茶,实现上面的接口就好,但有个缺点:所有方法都要实现一遍,而有些方法是子类是相同的,如addMilk()和pack(),可以用抽象类代替,不变的部分在父类中实现,可变的部分abstract由子类行实现:

// 抽象模板
abstract class AbstractTea {
    // 抽象方法 → abstract修饰,抽象模板声明,具体模板角色实现;
    abstract String addTeaBase();
    // 钩子方法 → 抽象模板声明并实现,具体模板角色可实现加以扩展;
    protected String addMilk() { return "添加牛奶"; }

    abstract String addIngredient();

    protected String pack() { return "打包饮品"; }

    // 模板方法 → 负责对基本方法的调度,一般用final修饰,不允许具体模板角色重写
    final String make() {
        return addTeaBase() + "→" + addMilk() + "→" + addIngredient() + "→" + pack();
    }
}

// 具体模板
public class CoconutGreenTea extends AbstractTea {
    @Override String addTeaBase() { return "添加绿茶底"; }
    @Override String addIngredient() { return "添加椰果配料"; }
}

public class PearlBlackTea extends AbstractTea {
    @Override String addTeaBase() { return "添加红茶底"; }
    @Override protected String addMilk() { return "添加三花淡奶"; }
    @Override String addIngredient() { return "添加珍珠配料"; }
}

// 测试用例
public class TeaTest {
    public static void main(String[] args) {
        PearlBlackTea blackTea = new PearlBlackTea();
        System.out.println(blackTea.make());
        CoconutGreenTea greenTea = new CoconutGreenTea();
        System.out.println(greenTea.make());
    }
}

代码运行结果如下

这就是模板方法模式,代码很简单,其实绝大部分设计模式的原理和实现都非常简单,难的是 掌握应用场景,搞清楚能解决什么问题。顺带画出UML类图、组成角色、使用场景及优缺点~

组成角色

  • AbstractClass (抽象模板) → 定义一个"算法"包含的所有步骤,并提供一些通用的方法逻辑;
  • ConcreteClass (具体模板) → 继承抽象模板,按需重写算法步骤中的某些步骤;

应用场景

  • 多个类具有相同方法且逻辑可共用时,将公共行为抽取并集中到公共父类中减少代码重复;
  • 通用算法、协议、固定流程设计为模板,在每个具体的子类中再继续优化算法步骤或流程步骤;

优点

  • 去除子类中的重复代码,抽象模板保存通用代码逻辑,子类无需重复处理公用逻辑,只关注特定逻辑;
  • 子类对父类的反向控制,通过子类来决定父类算法中某个步骤是否执行;
  • 代码复用、封装、良好的扩展性;

缺点

  • 违反开闭原则,"对修改关闭",子类执行结果受父类影响;
  • 增加代码阅读难度,子类多跳转也会很多,不方便联系上下文逻辑线索,模板中步骤越多,越难维护;
  • 违反里氏替换原则,替换子类,可能导致父类不可用或整体逻辑发生改变;

0x3、模板模式 VS 回调

两者的应用场景一致 → 定义好算法骨架,并对外开放扩展点,不同的地方:

  • 模板模式 基于 继承 关系实现,子类重写父类的抽象方法,一种类间的关系,针对不同实现都要定义不同的子类,子类必须实现父类中定义的所有抽象方法;
  • 回调 基于 组合 关系实现,把一个对象传递给另一个对象,一种对象间的关系,可使用匿名类来创建回调对象,不用事先定义类;

以上就是本节的全部内容,谢谢~