本文从实际开发场景出发，用3个贴近业务的案例（如电商订单处理、报表生成流程）拆解模板方法的核心结构：抽象类定义骨架、子类实现可变步骤。每个案例都搭配完整代码示例，从结构设计到细节优化，一步步带你理解如何通过模板方法复用流程、隔离变化。
无论你是刚接触设计模式的新手，还是想优化代码结构的资深开发者，跟着案例敲一遍代码，就能快速掌握“定义骨架-留空扩展”的设计思路，下次遇到重复流程场景，直接套用模板，轻松提升代码复用率和可维护性。看完这篇，模板方法设计模式再也不是纸上谈兵，上手就能用！
你有没有在后端开发时遇到过这种糟心情况？同一个业务流程写了七八遍，比如用户注册要“验证手机号→检查黑名单→创建账号”，商家入驻也要“验证资质→检查重复→创建店铺”，明明步骤框架都一样，每次却要复制粘贴改细节，不仅代码越堆越乱，后期改一个通用步骤（比如加个日志记录），还得挨个翻文件改，差点没把我同事逼疯。
后来我们团队用模板方法设计模式重构了这些流程，把固定步骤抽成“骨架”，可变细节留给子类，结果重复代码少了40%，上次改日志功能时，只动了一个抽象类就搞定了。今天我就带你扒透这个“流程复用神器”，从原理到代码一步步实操，保证你看完就能在项目里用上。
模板方法的核心：把重复流程“装”进骨架里
其实模板方法的思路特别简单，你想想咱们平时泡方便面：不管是红烧牛肉还是老坛酸菜，撕开包装、加开水、焖3分钟这三步是固定的（骨架），但具体放哪个口味的调料包（细节）可以自己选。模板方法设计模式就是干这个的——用抽象类定义一套流程骨架，把不变的步骤写死，把可变的步骤留空让子类填，既保证流程一致性，又能灵活扩展。
为啥后端开发非学不可？
我去年带一个电商项目时，团队里三个新人写订单处理逻辑，结果普通订单、秒杀订单、团购订单各写了一套，代码长得几乎一样，就验证规则和价格计算有点区别。上线后要加个“订单提交前记录操作日志”的功能，得改三个类，其中一个新人还漏改了秒杀订单，导致线上出了bug。后来我让他们用模板方法重构，把“验证→计算→提交→日志”这四个固定步骤抽到抽象类里，三个订单类只需要实现自己的验证和计算逻辑，后续改日志功能时，抽象类里加一行代码就全搞定了。
这就是模板方法的核心价值：把“做什么”（流程）和“怎么做”（细节）拆开。后端开发里80%的重复劳动都来自“流程相似但细节不同”的场景，比如数据导入导出、任务调度、消息处理，用模板方法就能把这些“重复骨架”拎出来，让代码从“复制粘贴型”变成“乐高积木型”。
模板方法的“两板斧”：抽象类+钩子方法
模板方法的结构其实就两部分，特别好记：
templateMethod()里按顺序调用step1()、step2()、step3()，其中step1()和step3()是固定实现（比如日志记录、异常处理），step2()是抽象方法（留给子类实现）。 这里有个容易被忽略的“钩子方法”（Hook Method），就是在抽象类里留一个可选步骤，子类可以选择重写或不重写。比如订单处理时，普通订单不需要“发送短信通知”，但团购订单需要，这时候抽象类可以定义一个空实现的sendNotification()，团购订单子类重写它，普通订单子类不用管——就像方便面调料包里的“蔬菜包”，想吃就加，不想吃就跳过。
你可能会问：“这和策略模式有啥区别？” 简单说，策略模式是“选不同算法”，模板方法是“固定流程里改细节”。比如排序用策略模式选冒泡还是快排（算法不同），而模板方法是“先排序再去重”这个流程不变，但排序用快排还是归并可以变（流程内的细节）。
3个实战案例带你落地：从代码到业务场景
光说理论太空泛，下面三个案例都是我在项目里真实用过的，每个案例我都贴了完整代码，你跟着敲一遍，保准下次遇到类似场景直接套用。
案例1：电商订单处理——让不同订单“走同一个流程”
业务场景
：电商系统里，普通订单、团购订单、预售订单的处理流程都包含“验证订单→计算价格→提交订单→记录日志”，但验证规则（比如团购订单需要检查库存是否满足成团人数）和价格计算（预售订单要加定金）不一样。 不用模板方法时：三个订单类各写一套process()方法，重复代码占比70%，改一个通用步骤得改三个类。 用模板方法重构后：
process()里，抽象方法validate()和calculatePrice()留给子类，固定步骤submit()和log()直接实现。 // 订单处理模板（抽象类）
public abstract class OrderTemplate {
// 模板方法：定义固定流程骨架
public final void process() {
validate(); // 抽象方法：留给子类实现
double price = calculatePrice(); // 抽象方法：留给子类实现
submit(price); // 固定实现：父类完成
log(); // 固定实现：父类完成
}
// 抽象方法：订单验证（子类必须实现）
protected abstract void validate();
// 抽象方法：价格计算（子类必须实现）
protected abstract double calculatePrice();
// 固定方法：提交订单（父类实现）
private void submit(double price) {
System.out.println("提交订单，价格：" + price);
// 实际项目中这里会调订单服务API
}
// 固定方法：记录日志（父类实现）
private void log() {
System.out.println("订单处理完成，记录日志");
// 实际项目中这里会写数据库或ELK
}
}
validate()和calculatePrice()。 // 普通订单子类
public class NormalOrder extends OrderTemplate {
@Override
protected void validate() {
System.out.println("普通订单验证：检查库存是否充足");
}
@Override
protected double calculatePrice() {
return 199.9; // 普通订单直接返回商品价格
}
}
// 团购订单子类
public class GroupOrder extends OrderTemplate {
private int groupSize; // 成团人数
@Override
protected void validate() {
System.out.println("团购订单验证：检查库存是否满足" + groupSize + "人");
}
@Override
protected double calculatePrice() {
return 199.9 * 0.8; // 团购8折
}
}
public class OrderClient {
public static void main(String[] args) {
OrderTemplate normalOrder = new NormalOrder();
normalOrder.process(); // 走普通订单流程
OrderTemplate groupOrder = new GroupOrder();
groupOrder.process(); // 走团购订单流程
}
}
效果
：代码复用率从30%提升到85%，后来加“订单提交前检查优惠券”功能，直接在抽象类process()里加一行checkCoupon()就搞定了，所有订单类型自动生效。
案例2：报表生成——让Excel和PDF“共用一套导出逻辑”
业务场景
：后端经常要导出报表，Excel和PDF的导出流程都是“查询数据→过滤数据→格式化数据→导出文件”，但格式化（Excel用POI，PDF用iText）和文件写入逻辑不同。 这里可以用钩子方法：比如有些报表不需要过滤数据，抽象类可以定义一个默认返回true的needFilter()钩子方法，子类如果不需要过滤就重写返回false。 核心代码片段（完整代码可私信我获取）：
// 报表导出模板（抽象类）
public abstract class ReportTemplate {
public final void export() {
String data = queryData(); // 固定步骤：查询数据
if (needFilter()) { // 钩子方法：是否需要过滤
data = filterData(data); // 固定步骤：过滤数据
}
String formattedData = formatData(data); // 抽象方法：格式化
writeFile(formattedData); // 抽象方法：写入文件
}
// 固定实现：查询数据
private String queryData() { return "原始数据..."; }
// 钩子方法：默认需要过滤，子类可重写
protected boolean needFilter() { return true; }
// 固定实现：过滤数据
private String filterData(String data) { return "过滤后的数据..."; }
// 抽象方法：格式化数据（Excel/PDF不同）
protected abstract String formatData(String data);
// 抽象方法：写入文件（Excel/PDF不同）
protected abstract void writeFile(String data);
}
// Excel报表子类
public class ExcelReport extends ReportTemplate {
@Override
protected String formatData(String data) {
return "Excel格式：" + data; // 用POI格式化
}
@Override
protected void writeFile(String data) {
System.out.println("写入Excel文件：" + data);
}
}
案例3：数据导入工具——5行代码搞定10种数据源导入
业务场景
：后端经常要写数据导入功能（MySQL→ES、CSV→MySQL、Excel→MongoDB），流程都是“读取文件→解析数据→验证格式→写入数据库”，但读取（CSV用opencsv，Excel用POI）和写入（MySQL用JDBC，ES用RestHighLevelClient）逻辑不同。 用模板方法后：抽象类定义流程，子类只需实现readFile()和writeDb()，我司数据组用这个模板后，新接一个数据源导入功能从2天缩短到2小时。 前后效果对比表：
| 对比项 | 不用模板方法 | 用模板方法后 |
|---|---|---|
| 代码量 | 每个数据源200行+ | 每个数据源50行左右 |
| 复用率 | 30%（仅重复代码） | 90%（流程+公共逻辑） |
| 维护成本 | 改一个流程步骤需改N个类 | 改抽象类即可，子类无需变动 |
这些坑你可别踩！我踩过的3个实战教训
模板方法虽好，但用不对反而会让代码更复杂，分享三个我踩过的坑和解决方案：
你看，模板方法其实就是“给重复流程画个框，框里留空填细节”，后端开发里这种场景真的太多了。我现在看到“步骤相似但细节不同”的需求，第一反应就是“能不能用模板方法抽个骨架？” 你在项目里遇到过类似的重复流程问题吗？用模板方法解决后代码量减了多少？欢迎在评论区分享你的经验，咱们一起避坑～
之前在项目里踩过一个坑，就是模板方法里的抽象类定义了个成员变量存流程中间结果，结果多线程一跑，数据直接乱套了。记得当时是订单处理模板，抽象类里有个currentStep变量记录当前流程到哪一步，普通订单和秒杀订单的线程同时改这个变量，导致A线程刚把currentStep设成“计算价格”，B线程就改成了“提交订单”，最后日志里全是错乱的步骤记录。后来才反应过来，抽象类的成员变量是每个实例共享的，如果多个线程共用一个子类实例，这些变量就成了共享资源，肯定会冲突。
这时候有两种解决办法，要么给共享变量加锁，比如用synchronized块或者ReentrantLock，每次只有一个线程能改；要么干脆用线程安全的容器，像ConcurrentHashMap存中间结果，或者用ThreadLocal让每个线程有自己的变量副本。我后来选了ThreadLocal，把currentStep放在里面，每个线程操作自己的副本，再也没出现过数据串了的情况。不过要记得用完ThreadLocal及时清理，不然可能内存泄漏，这点得注意。
还有个容易踩的坑是静态变量，之前有同事觉得“流程状态放静态变量里方便”，就在抽象类里定义了static String processStatus，结果线上出了个大bug：用户A提交的普通订单，状态竟然显示成了用户B的秒杀订单状态。你想想，静态变量是属于类的，所有实例都共用这一个，多线程下谁先改就被谁覆盖，可不就串数据了嘛。所以模板方法里千万别用静态变量存和具体流程相关的状态，除非这个状态是所有线程都通用的（比如配置参数），不然绝对会出问题。
不过如果你的模板方法是“无状态”的，那就省心多了。啥叫无状态？就是流程步骤不依赖抽象类的成员变量，所有数据都靠入参传进来，子类实现也只处理自己的局部变量。比如报表导出模板，抽象类里的queryData()方法只接收reportId参数，子类实现的formatData()也只处理方法内的临时变量，每个线程来调用时，直接new一个子类实例，处理完就扔，根本不会有线程安全问题。我现在写模板方法都尽量往无状态靠，实在需要中间变量就用ThreadLocal，这样多线程跑起来才踏实。
模板方法设计模式和策略模式有什么区别？
核心区别在于解决问题的角度不同：模板方法关注“固定流程骨架+可变细节”，比如订单处理的“验证→计算→提交”流程固定，具体验证规则可变；而策略模式关注“不同算法的替换”，比如排序时选冒泡还是快排，算法逻辑完全不同。简单说，模板方法是“流程不变，步骤细节变”，策略模式是“目标不变，实现算法变”。实际开发中两者可以组合使用，比如用模板方法定义流程，流程中的某个步骤用策略模式选不同算法。
哪些场景不适合用模板方法设计模式？
如果流程本身不稳定（比如步骤经常增减），或各实现类的步骤差异很大（超过50%步骤不同），就不适合用模板方法。比如一个业务需求中，A流程需要5个步骤，B流程需要3个完全不同的步骤，强行用模板方法会导致抽象类中出现大量空实现或钩子方法，反而让代码更复杂。这种情况 直接用普通类，或考虑策略模式。
抽象类中的钩子方法具体怎么用？能举个简单例子吗？
钩子方法是抽象类中定义的“可选步骤”，默认有简单实现（比如空方法或返回默认值），子类可根据需要重写。比如报表导出模板中，大部分报表需要“过滤数据”步骤，但少数简单报表不需要，这时抽象类可以定义钩子方法 needFilter() 默认返回 true，简单报表子类重写该方法返回 false，就能跳过过滤步骤。钩子方法的作用是“让流程更灵活，避免子类被迫实现不需要的步骤”。
使用模板方法时，如何避免抽象类变得臃肿？
关键是“只抽固定流程，不塞业务细节”。抽象类只定义步骤顺序和必要的公共逻辑（如日志、异常处理），具体业务逻辑（如价格计算、数据格式化）交给子类。 控制抽象类中抽象方法的数量，80%子类都会用的步骤直接在抽象类实现，仅留真正差异化的步骤作为抽象方法。如果发现抽象类超过5个抽象方法，可能是流程拆解得不够细， 拆分多个小模板（比如把“报表导出”拆成“基础报表模板”和“高级报表模板”）。
模板方法在多线程环境下使用需要注意什么？
主要注意抽象类中共享资源的线程安全问题。如果抽象类中定义了成员变量（比如流程中间结果），且子类可能被多线程调用，需要对共享变量加锁或使用线程安全容器（如 ConcurrentHashMap）。 避免在模板方法中定义静态变量存储流程状态，可能导致不同线程间数据干扰。如果流程步骤本身无状态（仅依赖入参和子类实现），多线程下通常无需额外处理，因为每个线程会创建独立的子类实例。
