## 01、痛点

如果你在文件导入服务里，把 CSV 的读取、校验、转换、保存代码复制到 Excel 版本里，只改了几行解析逻辑，那这篇文章就是为你准备的。我是老李，一个写 Java 后端多年的老兵。

我最怕维护的代码，不是复杂的算法，而是一堆看起来“差不多”的 Service。项目初期，我们做了一个订单导入功能，只支持 CSV。写了一个 `ImportCsvService`，里面有完整的读取、校验、转换、保存、通知流程。后来业务要求支持 Excel，同事把代码复制了一遍，改掉了文件解析部分，于是有了 `ImportExcelService`。再后来，客户说还要支持 JSON，又复制了一次，`ImportJsonService` 出现。

现在系统里有三个导入类，每个都有差不多的流程：读取文件 -> 校验数据 -> 转换实体 -> 保存数据库 -> 发送通知。它们的差异只在解析文件类型和校验字段上。但保存逻辑、事务控制、通知发送这些公共流程，被复制了三份。当保存逻辑要增加审计字段时，我们改了三个类；当通知开关要调整时，也要改三个类。新人接手后，问了一句：“这三个类到底有什么区别？”我们花了半小时解释。

代码失控的典型特征，不是单个方法多长，而是同一套流程散落在多个地方，修改半径不断扩大。设计模式要解决的不是代码写得不高级，而是变化开始失控。

> 锐评：如果一套流程只有两个分支，而且十年不变，复制粘贴也许还不是最差选择。但如果你已经预感到第三、第四个分支在路上，还继续复制，那不是复用，是埋雷。

字符画：

```
ImportCsvService    ImportExcelService   ImportJsonService
      |                    |                   |
  读取CSV              读取Excel            读取JSON
  校验CSV              校验Excel            校验JSON
  转换CSV              转换Excel            转换JSON
  保存订单            保存订单(重复)         保存订单(重复)
  发送通知            发送通知(重复)         发送通知(重复)
```

每个类重复了保存和发送通知的公共流程。

## 02、是什么

教科书会说设计模式是“软件开发中反复出现的一类问题的成熟解法”。但工程视角下，它更是管理变化的方式。设计模式有三个层次：

第一层：代码复用。第二层：隔离变化。第三层：管理复杂度。

模式不是代码模板，也不是套用公式，而是一种“职责如何拆、变化放在哪里”的思考方式。GoF 把模式分成创建型、结构型、行为型，但更重要的是，看到坏味道时能联想到对应模式。

今天重点讲模板方法模式（Template Method）。它属于行为型，核心思想是：在父类中定义算法骨架（TemplateMethod），让子类实现变化步骤。父类控制流程顺序，子类只负责填空。

核心角色：

- AbstractClass：抽象父类，定义模板方法和抽象操作。
- ConcreteClass：具体子类，实现抽象操作。
- TemplateMethod：模板方法，通常声明为 final，防止子类修改流程顺序。
- 抽象方法：由子类实现的步骤。
- 具体方法：父类提供的公共实现，子类可直接复用。
- Hook 方法：提供默认行为的空实现或返回布尔值，子类可选择覆写以影响流程。

对应文件导入场景，抽象父类 `AbstractFileImportTemplate` 定义模板方法 `execute()`，固定调用顺序：`readData() -> validate() -> transform() -> save() -> notifyIfNeeded()`。其中 `readData`、`validate`、`transform` 是抽象方法，`save` 是具体方法，`shouldNotify` 是 Hook。

字符画：

```
AbstractFileImportTemplate
|   execute() [final]
|      |
|      +-- readData()       // 抽象，子类实现
|      +-- validate()       // 抽象，子类实现
|      +-- transform()      // 抽象，子类实现
|      +-- save()           // 具体，公共逻辑
|      +-- shouldNotify()   // Hook，默认true
|      +-- sendNotification()
|
CsvImportTemplate   ExcelImportTemplate   JsonImportTemplate
```

父类决定“先读、再校验、再转换、再保存、最后通知”，子类只负责“读什么、校验什么、转成什么”。

## 03、为什么

很多开发者学过模板方法，却在项目里想不起来用。原因不是模式难，而是学习路径错了。常见误区：

误区一：先记模式，再找地方套。看到代码有重复，先想“用什么模式”，而不是“变化点在哪里”。

误区二：看到 if/else 就认为必须上策略模式。其实 if/else 本身未必坏，坏的是分散且持续增长的 if/else。如果分支是稳定两个，用一个 if 完全够。

误区三：抽象层越多，架构越高级。继承结构一多，阅读链变长，调试变复杂。

判断是否值得使用设计模式，有五个标准：

1. 变化是否真实存在？
2. 变化是否会持续增加？
3. 修改是否频繁影响旧逻辑？
4. 多个实现是否存在稳定公共结构？
5. 引入模式后，理解成本是否低于原来的维护成本？

可以用一个简单公式：

```
模式收益 = 未来变化成本降低 - 当前抽象复杂度增加
```

如果未来变化不大，抽象复杂度反而高，那就不值得。设计模式不是减少代码量，而是降低未来修改代码的风险。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。模板方法如果要抽象的流程步骤加起来不超过三个，或者各实现之间步骤根本不统一，强行抽父类只会增加沟通成本。

对于文件导入，如果流程确实稳定为“读取→校验→转换→保存→通知”，而且未来还会新增格式，那么模板方法收益明显。

## 04、架构

把设计模式按“开发问题”分类，比按 GoF 三大类更实用。

变化类型一：对象怎么创建？→ 工厂 / 建造者

变化类型二：多个实现怎么切换？→ 策略

变化类型三：流程怎么复用？→ 模板方法

变化类型四：多个节点怎么串起来？→ 责任链

变化类型五：外部系统怎么接进来？→ 适配器

变化类型六：功能怎么动态叠加？→ 装饰器

变化类型七：状态不同怎么改变行为？→ 状态模式

对应字符地图：

```
需求变化
   |
   v
变化点识别
   |
   v
职责拆分
   |
   v
模式选择
   |
   v
接口稳定
   |
   v
实现扩展
```

模板方法处于“流程复用”的位置。当变化点是某个流程中某些步骤的实现，而流程结构本身稳定时，选择模板方法；如果整个算法族都不同，策略更合适。

简单说，模板方法用继承控制流程，策略用组合切换算法。

## 05、实战

这一节用统一文件导入流程完整走一遍模板方法重构。

### 一、业务场景

系统需要导入订单数据，支持 CSV、Excel。导入主流程固定：读取文件→校验数据→转换实体→保存数据库→发送通知（通知可选）。未来可能支持 JSON。

### 二、第一版代码

最初的 CSV 导入类：

```java
public class ImportCsvService {
    public void importFile(File file) {
        List<String[]> rows = readCsv(file);
        List<ImportDTO> validRows = validateCsv(rows);
        List<Order> orders = transformCsv(validRows);
        saveOrders(orders);
        sendNotification("CSV", orders.size());
    }

    private List<String[]> readCsv(File file) { /* CSV解析 */ }
    private List<ImportDTO> validateCsv(List<String[]> rows) { /* CSV校验 */ }
    private List<Order> transformCsv(List<ImportDTO> rows) { /* 转换 */ }
    private void saveOrders(List<Order> orders) { /* 保存 */ }
    private void sendNotification(String type, int count) { /* 通知 */ }
}
```

Excel 导入类是复制粘贴后修改了几个方法，整体结构和保存、通知逻辑完全相同。

### 三、代码开始失控

后来新增 JSON 导入，又复制了第三个类。此时三个类中有三段几乎一样的保存逻辑和三段通知逻辑。需求要求保存时增加审计字段，三个类都要改。通知开关从“总是发送”变成“关闭通知”时，又要改三处。代码重复量大，而且流程逻辑分散，容易遗漏。

### 四、模式重构

先定义抽象父类：

```java
public abstract class AbstractFileImportTemplate {
    // 模板方法，final 防止子类改变流程顺序
    public final void execute(File file) {
        List<Map<String, Object>> rawData = readData(file);
        List<ImportDTO> validData = validate(rawData);
        List<Order> orders = transform(validData);
        saveOrders(orders);
        if (shouldNotify()) {
            sendNotification(orders.size());
        }
    }

    // 抽象方法：子类实现变化步骤
    protected abstract List<Map<String, Object>> readData(File file);
    protected abstract List<ImportDTO> validate(List<Map<String, Object>> rawData);
    protected abstract List<Order> transform(List<ImportDTO> validData);

    // 具体方法：公共逻辑，子类复用
    private void saveOrders(List<Order> orders) {
        // 统一保存逻辑，包括事务、审计
        orderRepository.saveAll(orders);
        auditLog.record("import", orders.size());
    }

    // Hook 方法：控制可选步骤
    protected boolean shouldNotify() {
        return true; // 默认发送通知
    }

    private void sendNotification(int count) {
        notificationService.send("导入完成，共 " + count + " 条");
    }
}
```

CSV 子类只实现自己的解析、校验、转换：

```java
@Component
public class CsvImportTemplate extends AbstractFileImportTemplate {
    @Override
    protected List<Map<String, Object>> readData(File file) {
        // CSV 具体解析
    }

    @Override
    protected List<ImportDTO> validate(List<Map<String, Object>> rawData) {
        // CSV 字段校验
    }

    @Override
    protected List<Order> transform(List<ImportDTO> validData) {
        // CSV 转 Order
    }

    @Override
    protected boolean shouldNotify() {
        return false; // CSV 导入不需要通知
    }
}
```

Excel 和 JSON 子类类似。新增 JSON 时，只需新建 `JsonImportTemplate` 实现三个抽象方法，不需要再复制保存和通知代码。

调用方式可以使用一个简单工厂或 Map 路由，但核心是父类模板方法保证流程统一：

```java
@Service
public class ImportService {
    private final Map<String, AbstractFileImportTemplate> importers;

    public ImportService(List<AbstractFileImportTemplate> importers) {
        this.importers = importers.stream()
            .collect(Collectors.toMap(i -> i.getType(), i -> i));
    }

    public void importFile(String type, File file) {
        importers.get(type).execute(file);
    }
}
```

每个子类实现 `getType()` 返回格式标识。

### 五、结构变化

重构前：

```
ImportCsvService    ImportExcelService   ImportJsonService
      |                    |                   |
  读取CSV              读取Excel            读取JSON
  校验CSV              校验Excel            校验JSON
  转换CSV              转换Excel            转换JSON
  保存订单(重复)        保存订单(重复)        保存订单(重复)
  发送通知(重复)        发送通知(重复)        发送通知(重复)
```

重构后：

```
ImportService
      |
      v
AbstractFileImportTemplate (execute)
      |
      +-- readData()    // 子类实现
      +-- validate()    // 子类实现
      +-- transform()   // 子类实现
      +-- saveOrders()  // 公共实现
      +-- sendNotification() // 公共实现
      +-- shouldNotify() // Hook
      |
CsvImportTemplate  ExcelImportTemplate  JsonImportTemplate
```

### 六、收益

- 新增导入格式只需新建子类实现三个变化步骤，不再复制保存、通知。
- 流程顺序被父类锁定，不会因为开发者疏忽遗漏某一步。
- 通知逻辑由 Hook 控制，子类可以按需覆写。
- 重复代码数量显著减少，修改公共逻辑只需改父类一处。
- 便于单元测试：每个子类可以单独测试自己的解析、校验、转换。

### 七、代价

- 类数量增加，从三个具体 Service 变成抽象父类+多个子类。
- 使用继承，子类与父类强耦合，父类修改可能影响所有子类。
- Java 单继承限制，如果子类还需要继承其他类，会比较麻烦。
- 阅读链路变长，需要先理解父类模板流程，再看子类实现。
- 如果未来流程步骤本身变化大，比如某个格式不需要校验或保存方式差异巨大，父类模板可能变得僵硬。

### 八、什么时候不要用

- 只有两个格式且未来不会再增加，且流程差异不大时，复制两份也不一定比抽象差。
- 各格式的流程步骤本身不统一，比如一个需要校验另一个不需要，或者保存方式完全不同，强制统一父类反而别扭。
- 变化步骤太多，导致抽象方法很多，子类实现负担重，这时候可能需要更灵活的方案（如策略+组合）。

记忆口诀：**“稳定流程交给父类，变化步骤留给子类。”**

另外，模板方法与策略模式常被混淆：模板方法依赖继承，父类控制流程骨架，子类填充变化步骤；策略模式偏组合，算法独立为策略对象，可运行时替换。简单判断：如果流程骨架稳定且多种实现共享大量公共代码，用模板方法；如果整个算法都需要替换，或希望动态切换，用策略。

## 06、洞见

会使用设计模式后，更重要的是会判断。以下几个洞见值得琢磨。

洞见一：设计模式真正关注的是“变化”，不是“类”。模板方法的核心不是父类和子类，而是“哪些步骤稳定，哪些步骤会变”。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。我们之所以抽 `AbstractFileImportTemplate`，是因为看到了三个类复制了三次保存逻辑，而不是一开始就设计一个父类。

洞见三：设计模式最重要的价值是降低修改半径。模板方法让保存逻辑的修改半径从三个类缩小到一个父类。

洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。很多时候复制两份代码更清晰。

洞见五：很多 Spring 框架设计本身就是设计模式的大型实践。`JdbcTemplate` 用模板方法封装了 `获取连接 -> 创建语句 -> 执行 -> 处理结果 -> 释放连接` 的流程，开发者只填空；`HttpServlet` 的 `service()` 方法也是模板方法，调用 `doGet`/`doPost`；`AbstractApplicationContext` 的 `refresh()` 亦然。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

不要试图一次学完 23 种模式，先掌握最常用的五个：策略、工厂、模板方法、责任链、适配器。今天重点练模板方法。

第一阶段，先理解模板方法适用的坏味道：重复流程、固定顺序、只有部分步骤不同。

第二阶段，从项目里找重复流程。比如各种文件导入、报表导出、支付回调处理、消息处理等。每天找一个重复代码。

第三阶段，尝试重构。每次重构回答五个问题：

1. 变化点是什么？
2. 不使用模式会怎样？
3. 使用模式增加了什么复杂度？
4. 下一次新增需求，需要修改几个地方？
5. 新人是否更容易理解？

给你一个七天实践计划：

- Day 1：找到一个超过两个实现、流程重复的服务（例如导入 CSV/Excel）。
- Day 2：列出它们的固定步骤顺序，识别哪些步骤真正不同。
- Day 3：抽抽象父类，定义模板方法和抽象方法。
- Day 4：让现有子类继承并实现，确保行为不变。
- Day 5：添加一个 Hook 方法控制可选步骤（如是否发送通知）。
- Day 6：模拟新增一种格式，只写子类，看看需要改多少代码。
- Day 7：重新评估：这个抽象是否真的降低了维护成本？如果答案是否定的，回退。

最后记住：设计模式不是考试题，是重构工具。

## 08、小结

> 设计模式不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。

模板方法模式把“流程”和“实现”分开，父类控制稳定的流程骨架，子类只负责可变的步骤。真正值得学习的不是 23 个名字，而是看到变化、识别变化、隔离变化的能力。

如果读完这篇文章，你少写了一个 500 行复制粘贴，这篇文章就算没有白写。

## 09、链接与概念说明

- **GoF**：指 Gang of Four，即《设计模式：可复用面向对象软件的基础》四位作者，该书定义了 23 种经典设计模式。
- **创建型 / 结构型 / 行为型**：创建型解决对象创建（如工厂、建造者），结构型解决类或对象组合（如适配器、装饰器），行为型解决对象间交互与职责分配（如策略、模板方法、责任链）。
- **SOLID 原则与设计模式**：设计模式通常服务于 SOLID 原则。模板方法模式体现开闭原则（对扩展开放、对修改关闭）——新增文件格式通过新增子类实现，无需修改父类流程。
- **开闭原则**：软件实体应对扩展开放，对修改关闭。模板方法通过固定模板方法和抽象步骤，确保流程稳定且可扩展。
- 推荐继续阅读经典书籍：《设计模式：可复用面向对象软件的基础》《Head First 设计模式》《重构：改善既有代码的设计》。官方资料可参考 Spring Framework 文档中关于 `JdbcTemplate` 的说明。

如果你在文件导入服务里，把 CSV 的读取、校验、转换、保存代码复制到 Excel 版本里，只改了几行解析逻辑，那这篇文章就是为你准备的。我是老李，一个写 Java 后端多年的老兵。

《设计模式军体拳第23招》 模板方法模式 Template Method——固定主流程，把变化留给子类

文件导入流程从复制粘贴到统一模板：固定读取-校验-转换-保存-通知，CSV/Excel/JSON 各自实现变化步骤，配合 Hook 控制通知，减少重复并隔离变化

架构师

编程语言

后端

模板方法模式解决文件导入流程重复问题，将读取、校验、转换抽象为子类实现，保存、通知逻辑收敛至父类。新增格式只需扩展子类，降低修改半径，提升维护效率，是流程复用场景的核心设计模式。

软件开发

单元测试

代码解释

数据库

路由

JSON

Java

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第23招》 模板方法模式 Template Method——固定主流程，把变化留给子类-腾讯云开发者社区-腾讯云

《设计模式军体拳第23招》模板方法模式 Template Method——固定主流程，把变化留给子类

《设计模式军体拳第23招》模板方法模式 Template Method——固定主流程，把变化留给子类

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第23招》 模板方法模式 Template Method——固定主流程，把变化留给子类

《设计模式军体拳第23招》 模板方法模式 Template Method——固定主流程，把变化留给子类

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第23招》模板方法模式 Template Method——固定主流程，把变化留给子类

《设计模式军体拳第23招》模板方法模式 Template Method——固定主流程，把变化留给子类