老朋友们都知道我这个《Java 设计模式西游篇》系列的规矩——每一回挑一个设计模式，借取经路上的故事把理论盘活。前九回我们已经聊了工厂、单例、策略、观察者这些常用模式，这一回轮到第十回：模板方法模式，题目就叫《模板方法定规矩 天条戒律不可违》。
这一回我们要把视角从孙悟空身上挪开，抬头看看天庭。取经路上降妖除魔，从来不是抡起棒子就打那么简单。谁先去侦查？怎么定策略？打赢之后怎么善后？要不要上报天庭？这一整套流程，其实早就写在天条里了。把这条“天条”翻译成 Java 代码，就是模板方法模式：父类把流程骨架焊死，子类只能往固定位置上填自己的本事。
这篇内容适合三类人：准备面试的 Java 工程师，设计模式是面试高频题，模板方法几乎场场都能遇到；正在做设计模式大作业或者期末项目的学生，文中的完整代码可以直接复用；还有那些“代码能跑但总觉得结构别扭”的日常业务开发，学完这个模式，你会发现很多重复代码都能收进同一个骨架里。读完这一回，你至少能带走四样东西：模板方法的核心思想、一个能跑通的完整 Java 示例、和策略模式的选型对比、一份实操避坑清单。
1. 模板方法模式真面目：把“流程”变成“天条”
1.1 这个模式到底在解决什么问题
先说一个特别常见的场景。你负责做一个报表导出功能，目前有 Excel 导出和 PDF 导出两条线，每条线的代码都差不多：查数据、处理表头、填充内容、导出文件、记日志。第一次写的时候痛痛快快复制粘贴，等需求变成“所有导出都要在文件头追加公司水印”的时候，你就要去两个地方甚至五个地方改同样的逻辑，漏改一个就是线上事故。
模板方法解决的就是这类问题：流程骨架是稳定的，里面的某些步骤是可变的。它把一个算法的不变部分写在父类里，把可变部分通过抽象方法或多态留给子类去实现。比起复制粘贴，它把“变”和“不变”在代码层面彻底分开，这其实是设计模式的通用思路——封装变化。
定义也简单：在一个抽象类中定义一个模板方法，模板方法里编排好整个算法的执行顺序，其中某些具体步骤延迟到子类中实现。子类不能改变算法结构，只能替换算法里某几步的具体内容。用西游的话讲，流程是天庭定的，怎么落实是神仙自己的事。
1.2 三个关键角色和一条天条
模板方法模式的参与角色其实只有两个，但如果按职责拆开，我们可以从三个角度来看：
- AbstractClass（抽象类）：负责定义模板方法和算法的骨架。骨架方法通常用 final 修饰，表示“天条戒律不可违”，子类不能重排流程。
- ConcreteClass（具体子类）：实现抽象类里声明的抽象步骤，也可以覆盖带默认实现的可选步骤。
- Template Method（模板方法）：抽象类里那个编排流程的方法，它决定了“先做什么、后做什么、哪些环节必须有、哪些环节可跳过”。
这里最容易被忽略的是 final 关键字。模板方法为什么要加 final？因为设计这个模式的初衷就是不希望子类改动流程。流程一变，整个骨架就失去意义，父类对子类的约束也荡然无存。就好比玉帝定了天条，你一个神仙下界私自把降妖流程改成“见面就砍”，天庭的统筹就乱套了。所以记住一句话：模板方法可以 final，步骤方法不要 final，否则子类什么都做不了。
1.3 好莱坞原则：别打电话给我，我会打给你
模板方法模式背后还站着一个著名的原则：好莱坞原则——别打电话给我们，我们会打电话给你。在代码里的意思是：父类负责主动调用子类的方法，而不是让子类反过来控制父类的执行时机。
这和我们平时习惯的“子类调用父类”是反着的。很多初学者写成模板方法模式后，喜欢在子类里直接调用父类的某个步骤方法，或者在子类里自行调用 execute，这其实已经破坏了模式的初衷。正确的姿势是：你只管在子类里实现好步骤，父类的 execute 会在合适的时机来调用你，这样整个流程的节奏才掌握在父类手里。把控制权集中在父类，是模板方法模式保持秩序的关键。
2. 西游场景映射：天条执法流程拆解
2.1 从“抡棒子就打”到“按流程降妖”
回到西游世界。天庭每次派神仙下界降妖，理论上都有一个固定的流程，我把它归纳成五步：侦查、制定策略、正面交锋、善后处理、向玉帝汇报。这五步的顺序就是天条定死的，不能倒过来“先汇报再侦查”。这其实就是模板方法里那个 execute() 的骨架。
但是每一步怎么做，天条管不着，只看个人本事。孙悟空侦查是拔毫毛变小猴钻洞，二郎神侦查是开了天眼站在云头看，哪吒侦查可能直接让风火轮去转一圈。大家流程一致，个性不同，这正是模板方法最适合的舞台。取经路上那么多妖怪，没有哪一场战斗的套路是完全一样的，但“先查清底细再动手”这个流程，从头到尾都没变过。
2.2 固定步骤、可变步骤、钩子步骤
把刚才的降妖流程映射到代码角色上，可以分成四类：
| 类型 | 西游里的对应 | 代码体现 |
|---|---|---|
| 固定模板 | 天条规定的整体顺序 | public final execute() |
| 强制可变步骤 | 侦查、交锋是每个神仙都必须亲自做的 | protected abstract |
| 可选可变步骤 | 策略可以有自己的打法，善后也可以追加动作 | protected 默认实现 |
| 钩子步骤 | “要不要上报天庭”“要不要善后”这类判断 | protected boolean 方法 |
这里有个很容易理解错的地方：抽象方法代表“必须有但内容可变”，钩子方法代表“有没有都不一定”。也就是说，在模板方法里，一个步骤的存在感和自由度是分层级的。设计的时候先问自己三个问题：这个步骤是不是必须的？每个子类是不是一定要有不同实现？有没有某些子类希望直接跳过这个步骤？三个问题问完，这个方法应该设计成 abstract、普通 protected 还是钩子，心里就有数了。
3. Java 代码实战：从零手写“天条执法器”
3.1 工程准备与建模
老规矩，先把工程环境说清楚。为了照顾正在做设计模式大作业和期末项目的同学，这一回我不引入任何第三方框架，只要一个能跑 Java 的环境就行，JDK 8 以上都OK，直接在任意目录建一个普通 Java 工程。
我们来模拟这样一个场景：天庭要派神仙下界降妖，每个神仙执行的流程一致，但具体手段不同。我把整个流程抽象成DemonSuppressionProcess类，把“天条”写死在 execute() 里，然后让MonkeyKingProcess和PigEightProcess两个子类去实现各自的步骤。
3.2 抽象类：先立规矩
package com.xiyou.template; /** * 天庭降妖流程模板 * 整个流程固定为五步：侦查、策略、交锋、善后、汇报 */ public abstract class DemonSuppressionProcess { /** * 模板方法：定义降妖流程的骨架。 * 使用 final 修饰，子类只能往步骤里填内容，不能重排流程。 */ public final void execute() { investigate(); makeStrategy(); fight(); if (needAfterlife()) { afterlife(); } if (needReport()) { report(); } } /** * 第一步：侦查敌情。 * 每个神仙的侦查手段都不一样，所以设计为抽象方法，强制子类实现。 */ protected abstract void investigate(); /** * 第三步：正面交锋。 * 战斗方式千差万别，也必须由子类各自实现。 */ protected abstract void fight(); /** * 第二步：制定策略。 * 这里给一个通用默认实现：先礼后兵。子类可以覆盖，也可以直接用默认的。 */ protected void makeStrategy() { System.out.println("[通用策略] 先礼后兵，能劝降就劝降，劝不动再动手"); } /** * 第四步：善后处理。 * 默认处理是清点损失、安抚百姓。子类可以在前后追加自己的动作。 */ protected void afterlife() { System.out.println("[通用善后] 清点损失，安抚百姓，修复被破坏的房屋"); } /** * 第五步：向玉帝汇报。 */ protected void report() { System.out.println("[通用汇报] 向玉帝提交《降妖工作总结报告》"); } /** * 钩子方法：是否需要善后。 * 如果妖怪灰飞烟灭、没有伤及百姓，子类可以返回 false 跳过善后。 */ protected boolean needAfterlife() { return true; } /** * 钩子方法：是否需要上报天庭。 * 如果这趟是私下行动，子类可以返回 false 不写报告。 */ protected boolean needReport() { return true; } }代码里的几个设计细节值得单独说。execute() 用了 final，这就是“天条戒律不可违”的直接体现。abstract 的 investigate() 和 fight() 是强制可变步骤，每个子类必须给出实现，否则编译不过。带默认实现的 makeStrategy()、afterlife()、report() 是可选可变步骤，子类想改就覆盖，不想改就用默认的。最后的 needAfterlife() 和 needReport() 是钩子方法，它们的返回值直接影响流程要不要走到下一步。
3.3 具体实现：悟空和八戒的两种风格
先看悟空的实现：
package com.xiyou.template; public class MonkeyKingProcess extends DemonSuppressionProcess { @Override protected void investigate() { System.out.println("[悟空侦查] 拔下三根毫毛，变出三只小猴，一只去前山踩点，一只去洞府偷听，一只去查妖怪底细"); } @Override protected void makeStrategy() { System.out.println("[悟空策略] 先变作小妖混进洞府，骗出妖怪的看家宝贝，再正面动手"); } @Override protected void fight() { System.out.println("[悟空交锋] 抡起金箍棒，七十二变加筋斗云，打得妖怪丢盔弃甲"); } @Override protected void afterlife() { System.out.println("[悟空善后] 找到被掳走的唐僧，解开绳索，先安顿好师父"); super.afterlife(); } @Override protected boolean needReport() { System.out.println("[悟空选择] 先斩后奏是老规矩，跳过汇报，免得玉帝催命"); return false; } }悟空的类里覆盖了侦查、策略、交锋、善后四个步骤，还通过钩子方法关掉了汇报环节。注意善后这里先打印了自己的逻辑，然后又调了 super.afterlife()，这是模板方法里非常常见的“在默认动作前/后追加逻辑”的写法，代码复用的效果很好。
再看八戒的实现：
package com.xiyou.template; public class PigEightProcess extends DemonSuppressionProcess { @Override protected void investigate() { System.out.println("[八戒侦查] 倒头就睡，睡醒了问一句：师父，妖怪在哪儿？"); } @Override protected void fight() { System.out.println("[八戒交锋] 九齿钉耙抡了几下，一看打不过，扭头就跑，边跑边喊：大师兄来了"); } @Override protected boolean needAfterlife() { System.out.println("[八戒选择] 善什么后？分行李回高老庄要紧，跳过善后环节"); return false; } }八戒只实现了侦查和交锋两个抽象方法，策略和汇报直接用父类的默认实现，还通过钩子把善后环节跳过了。这个类比悟空短得多，但流程执行下来是完全完整、不报错的。这也恰好说明模板方法模式的一个优点：子类的代码量可以非常少，只要把必须的抽象步骤实现掉，剩下的靠父类兜底。
3.4 运行验证与结果解读
最后写一个运行入口：
package com.xiyou.template; public class SkyLawDemo { public static void main(String[] args) { System.out.println("========== 天庭派悟空降妖 =========="); DemonSuppressionProcess monkey = new MonkeyKingProcess(); monkey.execute(); System.out.println(); System.out.println("========== 天庭派八戒降妖 =========="); DemonSuppressionProcess pig = new PigEightProcess(); pig.execute(); } }运行结果是这样的：
========== 天庭派悟空降妖 ========== [悟空侦查] 拔下三根毫毛，变出三只小猴，一只去前山踩点，一只去洞府偷听，一只去查妖怪底细 [悟空策略] 先变作小妖混进洞府，骗出妖怪的看家宝贝，再正面动手 [悟空交锋] 抡起金箍棒，七十二变加筋斗云，打得妖怪丢盔弃甲 [悟空善后] 找到被掳走的唐僧，解开绳索，先安顿好师父 [通用善后] 清点损失，安抚百姓，修复被破坏的房屋 [悟空选择] 先斩后奏是老规矩，跳过汇报，免得玉帝催命 ========== 天庭派八戒降妖 ========== [八戒侦查] 倒头就睡，睡醒了问一句：师父，妖怪在哪儿？ [通用策略] 先礼后兵，能劝降就劝降，劝不动再动手 [八戒交锋] 九齿钉耙抡了几下，一看打不过，扭头就跑，边跑边喊：大师兄来了 [八戒选择] 善什么后？分行李回高老庄要紧，跳过善后环节 [通用汇报] 向玉帝提交《降妖工作总结报告》注意看结果的顺序：悟空的善后和汇报判断都执行了，但 report() 被跳过了；八戒的策略和汇报用的是父类默认实现，但 afterlife() 被跳过。两个神仙执行同一个 execute()，因为各自的实现和钩子返回值不同，最终行为完全不一样，但流程骨架始终没有变。这就是模板方法模式“同骨架、异细节”的直观证据。
4. 钩子方法：天条里那扇“法外开恩”的窗
4.1 钩子的本质：不是步骤，是开关
刚才的代码里，needReport() 和 needAfterlife() 就是典型的钩子方法。很多人第一次接触模板方法时，分不清抽象方法、默认实现方法和钩子方法到底有什么区别。我用一个更直白的说法：抽象方法是“填空”，钩子方法是“开关”，默认实现方法是“备胎”。
- 抽象方法：流程里必须有的一步，但你不知道具体怎么做，强制子类来填空。
- 默认实现方法：流程里必须有的一步，父类已经给了通用做法，子类不覆盖就直接用。
- 钩子方法：不是流程步骤本身，而是流程的开关。它的返回值决定某个步骤到底执不执行。
钩子方法通常返回 boolean，放在模板方法里的某个步骤之前。如果返回 true，流程继续往下走；返回 false，流程跳过这一步。前面代码里的if (needAfterlife())就是典型的例子。
4.2 钩子方法在西游里的另类用法
除了当开关，钩子方法还有一个更隐蔽的用法：给子类一个“知情权”。子类可以在钩子里做点前置处理或者打印一些信息，然后返回一个默认值。比如悟空在 needReport() 里打印的那句话，其实就是在钩子里干的“私活”。这在真实业务里很常见：某个子类在执行到某一步之前，需要先发个通知、打个日志，或者检查一下自己的状态，但又不想改动主流程，这时候用钩子最合适。
还有一类钩子是用来控制“执行到一半要不要停下来”的。比如降妖流程里，如果侦查完发现根本不是妖怪，而是一个普通村民搞出来的误会，那后面的交锋、善后都得跳过。把这个判断做成钩子，父类流程不用改，子类自己决定后续步骤是否执行，整个模式就非常灵活。
4.3 钩子用多了也会翻车
钩子虽好，千万克制。我见过有人把模板方法写成这样：execute() 里全是 if，每个 if 后面跟一个钩子，类里面光钩子方法就有七八个。这种代码的维护成本非常高，每加一个子类就要面对一堆钩子，根本不知道哪个要返回 false、哪个要返回 true。如果你发现钩子越来越多，先不要急着加钩子，而是应该审视一下：是不是这个父类的职责太杂了？是不是该拆成两套模板了？模板方法模式的前提是“流程骨架稳定”，骨架本身都不稳定，硬往上堆钩子只会让代码变成蜘蛛网。
5. 模板方法 vs 策略模式：亲兄弟也要明算账
5.1 必须搞懂的区别
设计模式学得越多，越容易把模板方法和策略模式搞混，因为它们俩关心的都是“算法怎么变化”。面试里问这个问题的频率也特别高，所以这里单独开一节把账算清楚。
| 维度 | 模板方法模式 | 策略模式 |
|---|---|---|
| 核心关系 | 继承，父类与子类 | 组合，上下文与策略接口 |
| 控制权 | 算法骨架在父类手里，子类填空 | 算法整体封装在策略对象里，运行时可以替换 |
| 变化粒度 | 部分步骤可变 | 整个算法可替换 |
| 典型例子 | JdbcTemplate、HttpServlet | 支付渠道选择、压缩算法切换 |
| 改动方式 | 新增子类实现不同步骤 | 新增策略实现类，注入给上下文 |
模板方法是“骨架不变、细节在变”，策略模式是“整体算法可以换”。举一个实际例子：导出报表时，导出流程先查数据再生成文件这个骨架大概率不会变，只是文件的格式不同，这适合模板方法；但如果你同一个接口有微信支付和支付宝支付两种完全不同的对接方式，互相之间没有共同骨架，这就适合策略模式。
5.2 模板方法和策略也能组合
还有一个容易被忽视的事实：模板方法模式中的某个步骤，完全可以用策略模式来实现。比如降妖流程里的“交锋”这一步，可以定义成一个战斗策略接口，让子类注入不同的战斗策略。这样一来，顶层流程用模板方法定骨架，局部变化用策略模式做替换，各管各的变化维度，这也是实际项目里最常见的组合拳。
我自己在写业务代码时也用过这种组合。流程层用模板方法把“查数、计算、写库、通知”固定下来，判断用什么方式计算时，再注入一个策略对象。两套机制各管一段，互相不干扰，后面接需求的人一眼就能看明白哪里是骨架、哪里是策略。
5.3 框架里的模板方法：看一眼就懂
模板方法模式在主流框架里无处不在，随便举几个都能找到它的影子。
Spring 的JdbcTemplate是模板方法思想的典型：execute方法把获取连接、创建语句、执行、处理异常、释放资源这一整套骨架封装好，而真正的 SQL 逻辑通过回调接口传进去，回调方法就是那个“可变步骤”。
再比如 Java Web 的HttpServlet，父类的service()方法就是模板方法，它负责解析请求类型，然后调用 doGet、doPost、doPut 这些方法，子类只需要覆盖自己关心的那一个方法。这其实就是模板方法模式最经典的教科书级案例。
Spring 的AbstractApplicationContext.refresh()方法也是，整个容器的刷新流程是固定的，但其中的 beanFactory 创建、bean 后置处理器注册等步骤留给了子类去实现。
看框架源码的时候，别光看它能做什么，试着找找哪个方法是 final 的、哪个方法是 abstract 的、哪个方法带一个 boolean 钩子，用这个思路去读代码，很多框架的设计意图一下就通了。
6. 常见问题与避坑实录
6.1 模板方法没加 final：天条成了摆设
这是我在 code review 里最常挑的问题。有人把 execute() 写成了普通方法，某个子类一不高兴，直接 override 掉了整个流程，父类设计的骨架形同虚设。更可怕的是，这种问题在编译期完全看不出来，只有跑到某个子类出现诡异行为时才会发现“流程怎么不对了”。
解决方式就一个：模板方法一定要用 final。设计模式不是摆设，你既然选择了模板方法来定流程，就要用语言机制把流程保护住。final 就是给后来维护者看的契约：这地方你不能动。天条如果谁都能改，那就不叫天条了。
6.2 抽象步骤划分得太粗或太细都不行
步骤粒度是个经验问题。划分太粗，父类里的默认实现会承载过多逻辑，子类想改其中一小段都得把整个方法复制一遍；划分太细，每个子类都要实现一堆零碎的抽象方法，很多实现是空方法或者一句 return，代码看似规范，其实充满了噪音。
我个人的经验是：先写出两个真实的子类实现，再回头倒推抽象步骤的粒度。如果两个子类在某个步骤上的代码有八成都一样，那这个步骤就不该抽象，应该把共同部分上提到父类，只暴露差异点。如果一个步骤被拆成三个小方法，但所有子类都是整体覆盖，那说明拆得太细了。
6.3 钩子泛滥和 if 堆砌
前面已经说过钩子要用得克制。还有一种情况是一上来就堆 if 判断，把钩子直接写成if (xxx.getType().equals("A"))这种业务判断。这种做法等于把子类的差异又塞回了父类，父类迟早要知道所有子类的内部情况，模块之间就产生了反向依赖。
正确的做法是：差异交给子类通过覆盖钩子来表达，父类不要做业务判断。父类只需要知道“这个方法返回 true 还是 false”，至于为什么返回 false，那是子类的事。父类和子类各守边界，代码才清爽。
6.4 和策略模式选型翻车
面试里被问“模板方法和策略模式的区别”时，很多人的回答是“一个是继承一个是组合”，这没错，但最好再补一句选型判断：当流程骨架稳定、只有局部步骤变化时，用模板方法；当算法整体需要运行时切换时，用策略模式。再进一步，还可以说两者可以组合使用。能答到这个深度，这一题基本就稳了。
6.5 命名和注释不规范
最后说一个容易被忽略的小点。模板方法模式的代码里，模板方法一般叫 execute、process、run 这类动词，一眼就知道是入口；步骤方法不要用 step1、step2 这种编号命名，而要用业务语义命名，比如 validate、convert、persist。同样重要的是在抽象方法上写明注释：“本方法为强制实现步骤”“本方法为可选覆盖步骤”，这对后来的维护者是极大的善意。
7. 什么时候用、什么时候别用：边界感很重要
7.1 适合用模板方法的信号
我总结了几个比较明显的信号，只要你观察到两个或两个以上信号，就可以考虑上模板方法：
- 多个类在业务流程上高度相似，只有某些环节不同；
- 流程的先后顺序基本稳定，不太会频繁调整；
- 希望以后新增业务时能自动遵循同一套流程，而不是各自随意发挥；
- 代码里已经出现多处复制粘贴的流程代码，而且每次改流程都要改好几个地方。
这些信号出现的时候，往往不需要一开始就设计模板方法，而是在重构时顺手把公共流程抽出来。我见过很多项目是在写完三四个相似类之后才抽出模板方法的，效果并不比一开始就设计差，反而因为有了真实的代码样本，抽象出来的骨架更贴合实际。
7.2 不适合用模板方法的信号
反过来，下面这些情况强行用模板方法只会更难受：
- 流程本身天天变，今天五步明天三步，骨架稳定不下来；
- 子类之间的共同点很少，大部分步骤都是各写各的，硬抽象出来的父类就是个空壳；
- 继承体系已经很深了，再为了模板方法加一层父类，整个类层次会变得复杂难懂。
遇到这些情况，宁可先复制几份代码，也别急着用一个不成熟的抽象去“规范”所有人。设计模式是工具，不是使命。流程还没有稳定就上模板方法，最后一定是反复改父类，改得比复制粘贴还累。
7.3 一个真实业务例子：数据导入流程
最后分享一个真实业务案例。我有一次接手一个数据导入需求，要支持 Excel 导入、接口推送导入、手工录入三条渠道，三条渠道看起来完全不同，但走完整个项目后发现它们的核心流程是一致的：校验数据、清洗转换、落库、更新统计、通知结果。于是我把这个流程抽成了一个AbstractImportHandler，定义好模板方法，三个渠道各自实现校验和转换的逻辑。
后来要增加“导入前自动备份”功能，只需要在模板方法里加一步，三条渠道全部生效，改动量从三个文件缩减到一个文件。这个例子想表达的是：模板方法模式最好的应用时机往往不在需求设计阶段，而在你发现重复代码的时候。不要为了用模式而用模式，先写代码，再在迭代中嗅到重复的味道，然后动手重构，这样用出来的模式最自然，也最有说服力。
我自己的体会是，模板方法模式是“约束”与“灵活”之间平衡最好的模式之一。它不像单例那样简单，也不像代理那样绕，但它在业务代码里的出现频率其实非常高。这些年我养成了一个习惯：但凡发现两个方法贴来贴去、只有中间几行不一样，就会下意识地想想能不能抽出模板方法。这个过程做多了，再回头看设计模式，你会发现它不是玄学，就是一群经验丰富的程序员从真实代码里提炼出来的套路。希望你也能在下一次写重复代码的时候，想起那句“模板方法定规矩，天条戒律不可违”，让父类把流程立起来，子类好好填自己的那一部分，代码自然会干净很多。
