模板模式（保姆级教程）

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战(已更新的所有项目都能学习) / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

• 新开坑项目:《Spring AI 项目实战》 正在持续爆肝中，基于 Spring AI + Spring Boot 3.x + JDK 21...， 点击查看 ;
• 《从零手撸：仿小红书（微服务架构）》 已完结，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，点击查看项目介绍 ;演示链接： http://116.62.199.48:7070 ;
• 《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接： http://116.62.199.48/ ;

截止目前， 星球 内专栏累计输出 90w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 3100+ 小伙伴加入学习 ，欢迎点击围观

模板模式的定义与核心思想

模板模式（Template Pattern）是一种经典的设计模式，属于行为型模式的一种。它通过定义算法的“骨架”（即固定的操作流程），将某些具体步骤的实现延迟到子类中完成。这种设计思想的核心在于：固定流程框架，开放可变细节。

想象一个烹饪食谱：食谱中规定了“准备食材→烹饪→调味→装盘”这四个步骤，但每个步骤的具体操作（比如“烹饪”可以是炒、煮、烤）可以根据不同菜系或厨师偏好灵活调整。模板模式正是通过这种方式，将通用流程与可变细节分离，既保证了流程的一致性，又允许扩展性。

模板模式的结构与关键要素

模板模式的典型结构包含以下角色：

1. 抽象类（Abstract Class）：定义算法的通用步骤，并声明抽象方法或钩子方法（Hook Methods）。
2. 具体实现类（Concrete Classes）：继承抽象类，实现抽象方法，提供具体的业务逻辑。

核心要素详解

1. 模板方法（Template Method）

这是模板模式的核心方法，通常定义在抽象类中，是一个非抽象的“骨架方法”。它调用多个步骤方法（Step Methods），这些步骤可能是抽象的（必须由子类实现）或具体的（可直接使用）。

2. 步骤方法（Step Methods）

分为两种类型：

• 抽象方法：必须由子类实现，代表流程中可变的细节。
• 具体方法：抽象类直接提供实现，子类可选择覆盖或直接使用。

3. 钩子方法（Hook Methods）

钩子方法是抽象类中提供默认实现的方法，允许子类在特定阶段干预流程。例如，一个钩子方法可能默认返回 false，子类若需要改变流程分支，只需重写该方法返回 true。

模板模式的实现原理与流程图

简化的类结构示意图

流程图逻辑

1. 客户端代码调用抽象类的模板方法。
2. 模板方法按固定顺序调用各个步骤方法。
3. 抽象方法强制子类实现，钩子方法允许子类选择性干预。

模板模式的典型应用场景

场景一：业务流程标准化与扩展

案例：电商订单处理系统
订单处理通常包含以下步骤：

1. 创建订单
2. 支付验证
3. 库存扣减
4. 发货通知

但不同商品（如实物商品、虚拟商品）的支付和发货逻辑不同。此时，模板模式可以定义通用流程，而具体实现由子类控制。

场景二：算法框架的复用

案例：机器学习模型训练流程
训练流程通常包括：数据加载、预处理、模型构建、训练、评估。模板模式可封装这些通用步骤，而子类仅需实现特定数据处理或模型选择逻辑。

代码示例：电商订单处理系统

抽象类设计（Java示例）

abstract class OrderProcessor {  
    // 模板方法：定义固定流程  
    final void processOrder() {  
        createOrder();  
        if (processPayment()) {  
            deductInventory();  
            sendConfirmation();  
        } else {  
            cancelOrder();  
        }  
    }  

    // 抽象方法：必须由子类实现  
    protected abstract void createOrder();  
    protected abstract boolean processPayment();  
    protected abstract void deductInventory();  

    // 钩子方法：默认不发送通知，子类可覆盖  
    protected void sendConfirmation() {  
        // 默认实现  
    }  

    private void cancelOrder() {  
        // 公共的取消逻辑  
    }  
}  

具体实现类（实物商品订单）

class PhysicalProductOrder extends OrderProcessor {  
    @Override  
    protected void createOrder() {  
        // 创建实物订单的逻辑  
    }  

    @Override  
    protected boolean processPayment() {  
        // 调用第三方支付接口  
        return PaymentService.processCreditCard();  
    }  

    @Override  
    protected void deductInventory() {  
        // 扣减仓库库存  
    }  

    // 覆盖钩子方法，发送邮件通知  
    @Override  
    protected void sendConfirmation() {  
        EmailService.send("订单已发货");  
    }  
}  

具体实现类（虚拟商品订单）

class DigitalProductOrder extends OrderProcessor {  
    @Override  
    protected void createOrder() {  
        // 创建虚拟订单的逻辑  
    }  

    @Override  
    protected boolean processPayment() {  
        // 使用加密货币支付  
        return CryptoPaymentService.process();  
    }  

    @Override  
    protected void deductInventory() {  
        // 虚拟商品无需扣减库存  
    }  

    // 不覆盖钩子方法，使用默认行为  
}  

模板模式的优势与适用性

核心优势

1. 代码复用：公共流程被抽象到基类，避免重复代码。
2. 灵活性：子类只需关注可变部分，无需修改整体逻辑。
3. 可维护性：修改流程时，只需调整模板方法，无需改动所有子类。

适用场景总结

• 流程框架固定，但具体步骤可变的场景。
• 需要避免“上帝类”（God Class）的代码膨胀问题。
• 多个子类共享大部分逻辑，仅少数步骤不同。

常见误区与注意事项

误区一：将模板模式等同于抽象类

模板模式的核心是“模板方法”，而非单纯使用抽象类。即使没有抽象方法，只要存在固定流程的“骨架方法”，也可能属于模板模式。

误区二：过度使用模板模式

若流程本身高度可变或无固定结构，模板模式可能导致设计僵化。此时，策略模式或命令模式可能更合适。

注意事项

1. 钩子方法的谨慎使用：过多钩子可能降低代码可读性，需明确其业务意义。
2. 模板方法的final修饰：在Java等语言中，模板方法通常设为 final，防止子类破坏流程顺序。
3. 抽象方法与具体方法的平衡：避免抽象类承担过多具体逻辑，保持“骨架”与“细节”的分离。

总结：模板模式的核心价值

模板模式通过“固定框架，开放细节”的设计，帮助开发者在保证流程一致性的前提下，灵活应对业务变化。它适用于订单处理、算法框架、游戏状态机等广泛场景，是设计模式中实用性极高的工具之一。

通过合理使用模板模式，团队可以减少重复代码、提升代码复用率，并为后续扩展提供清晰的扩展点。然而，设计模式并非万能，需结合具体需求选择最合适的方案。掌握模板模式的思维，能帮助开发者更优雅地应对复杂系统的挑战。

本文通过案例与代码示例，系统解析了模板模式的原理与应用场景，旨在帮助读者理解其设计思想，并在实际项目中灵活运用这一模式。