模板方法模式：流程固定步骤可变的代码复用利器-北京尧图网络

1. 模板方法模式到底解决了什么痛点第一次接触模板方法模式是在做一个数据导出功能的时候。当时需求很明确系统里有好几种数据源有从关系型数据库读的有从接口拉的还有从本地文件解析的但最终都要走同一套流程——连接、读取、解析、校验、格式化、输出。我一开始的写法是每种数据源写一个独立的类每个类里把这一整套流程从头到尾写一遍。结果就是六个数据源六份几乎一模一样的代码唯一的区别就在“读取”和“解析”这两步。后来产品说要在输出前统一加一个水印我改了六个文件改到第三个的时候就已经开始怀疑人生了。这就是模板方法模式要解决的核心问题当一个业务流程的骨架是固定的但其中某些具体步骤会因场景不同而变化时把不变的骨架提取到父类中把变化的部分延迟到子类去实现。说白了它管的就是“流程固定、步骤可变”这件事。你在生活里其实经常遇到类似的情况。比如泡茶和泡咖啡流程都是“烧水→放入原料→冲泡→倒杯”区别只在于“放入什么原料”和“怎么冲泡”。如果每次泡东西都从头写一遍流程那确实挺蠢的。模板方法模式就是让你把“烧水→放入原料→冲泡→倒杯”这个骨架定死具体放什么、怎么泡交给不同的子类去决定。这个模式适合谁呢如果你正在写一个多步骤的业务流程而且这个流程在多个场景下只有部分步骤不同那你就该考虑它了。它特别适合做框架设计、数据处理管道、工作流引擎、测试用例组织这类场景。哪怕你只是写一个简单的报表生成器只要流程步骤超过三步且有复用可能模板方法模式都能帮你省下大量重复代码。2. 拆解模板方法模式的核心结构2.1 抽象父类与具体子类的职责划分模板方法模式的结构其实不复杂核心就两个角色抽象父类和具体子类。抽象父类负责定义整个算法的骨架也就是那个“模板方法”。这个方法通常是一个具体方法不是抽象方法它按照固定顺序调用一系列步骤方法。这些步骤方法有的是抽象的必须由子类实现有的是有默认实现的子类可以选择性地覆盖。具体子类则负责实现那些抽象步骤方法把自己的个性化逻辑填进去。子类不需要关心整个流程怎么走它只需要关注“我这一步该怎么做”。这里有个关键点很多人一开始会搞混模板方法本身通常是final的或者至少在设计意图上不允许子类覆盖。为什么因为模板方法定义的是流程骨架如果子类能随意覆盖它那整个流程的稳定性就没了模板方法模式也就失去了意义。你想想如果泡茶的子类能把“烧水”这一步给覆盖掉改成“直接倒冷水”那整个流程不就乱套了吗2.2 钩子方法给子类留一扇可控的门除了抽象步骤方法模板方法模式里还有一个很重要的概念叫钩子方法。钩子方法通常是父类中有一个空实现或者默认实现的方法子类可以根据需要选择性地覆盖它。钩子方法的价值在于它提供了一种“可选扩展点”。比如在数据导出的例子里我可以在流程中加一个beforeExport()的钩子方法默认什么都不做。如果某个子类需要在导出前做点额外操作比如记录日志或者检查权限它就可以覆盖这个钩子。不需要的子类完全不用管它。这比把所有步骤都定义成抽象方法要灵活得多。因为抽象方法强制子类必须实现而钩子方法给了子类选择的权利。在实际项目中钩子方法往往是后期扩展的主要入口设计得好能省掉很多返工。2.3 好莱坞原则别来找我我会找你模板方法模式背后有一个很重要的设计原则叫好莱坞原则——“Dont call us, well call you”。翻译成大白话就是子类你不要主动去调用父类的流程父类会在合适的时机调用你。这个原则听起来简单但它带来的思维转变很关键。在传统的过程式编程里我们习惯了自己控制流程一步一步往下走。但在模板方法模式里控制权是反转的父类控制流程子类只提供具体的步骤实现。子类是被动的它不需要知道整个流程长什么样只需要知道自己那一步该做什么。这种控制反转带来的好处是流程的稳定性由父类保证子类只需要关注自己的业务逻辑。当流程需要调整时只改父类一处就行所有子类自动生效。这就是为什么我说它是“流程固定、步骤可变”场景的最佳解法。3. 手把手实现一个模板方法模式3.1 场景定义一个数据导出管道的设计为了让你能直接抄作业我用一个完整的数据导出场景来演示。假设我们需要从不同数据源导出数据流程统一为连接数据源→读取数据→解析数据→校验数据→格式化输出→关闭连接。其中“连接”“读取”“解析”三步因数据源不同而不同其余步骤是通用的。先定义抽象父类public abstract class DataExporter { // 模板方法定义导出流程骨架不允许子类覆盖 public final void export() { connect(); ListString rawData read(); ListRecord records parse(rawData); if (validate(records)) { String output format(records); writeOutput(output); } else { handleValidationFailure(records); } close(); } // 抽象步骤子类必须实现 protected abstract void connect(); protected abstract ListString read(); protected abstract ListRecord parse(ListString rawData); // 通用步骤父类提供默认实现 protected boolean validate(ListRecord records) { return records ! null !records.isEmpty(); } protected String format(ListRecord records) { StringBuilder sb new StringBuilder(); for (Record record : records) { sb.append(record.toString()).append(\n); } return sb.toString(); } protected void writeOutput(String output) { System.out.println(output); } protected void close() { System.out.println(资源已释放); } // 钩子方法子类可选覆盖 protected void handleValidationFailure(ListRecord records) { System.out.println(校验未通过跳过输出); } }这段代码里export()就是模板方法它用final修饰锁死了流程顺序。connect()、read()、parse()是抽象方法子类必须实现。validate()、format()、writeOutput()、close()都有默认实现子类可以按需覆盖。handleValidationFailure()是一个钩子方法默认只是打印一条提示子类可以覆盖它来做更复杂的处理比如发送告警通知。3.2 子类实现数据库导出与文件导出接下来看两个具体的子类实现public class DatabaseExporter extends DataExporter { Override protected void connect() { System.out.println(建立数据库连接); } Override protected ListString read() { System.out.println(从数据库读取数据); return Arrays.asList(row1, row2, row3); } Override protected ListRecord parse(ListString rawData) { System.out.println(解析数据库记录); return rawData.stream() .map(Record::new) .collect(Collectors.toList()); } Override protected void handleValidationFailure(ListRecord records) { System.out.println(数据库导出校验失败发送告警邮件); } }public class FileExporter extends DataExporter { Override protected void connect() { System.out.println(打开文件句柄); } Override protected ListString read() { System.out.println(读取文件内容); return Arrays.asList(line1, line2); } Override protected ListRecord parse(ListString rawData) { System.out.println(解析文件行); return rawData.stream() .map(Record::new) .collect(Collectors.toList()); } }你看DatabaseExporter覆盖了钩子方法handleValidationFailure()因为数据库导出失败需要告警而FileExporter没有覆盖它直接用默认行为就行。两个子类都只关注自己该实现的那三步流程控制完全交给父类。3.3 参数选择与设计决策的思考过程在实际落地时有几个设计决策需要你认真考虑。第一模板方法要不要用final修饰我的建议是尽量用。如果你确实需要允许子类调整流程那说明这个场景可能不适合模板方法模式你应该考虑用策略模式或者其他方案。模板方法模式的核心价值就在于流程的稳定性如果流程可以被随意修改那这个模式的意义就不大了。第二抽象方法和钩子方法怎么划分判断标准很简单如果某个步骤在所有子类中都必须有不同的实现那就定义为抽象方法如果某个步骤在大部分子类中是一样的只有少数子类需要特殊处理那就定义为钩子方法。抽象方法强制实现钩子方法提供选择用错了会导致子类代码臃肿或者流程不完整。第三步骤的粒度怎么控制步骤拆得太细子类需要实现的方法就多使用成本高拆得太粗子类的个性化能力就弱可能又会出现重复代码。我的经验是每个步骤应该对应一个明确的业务动作而且这个动作在业务上是有意义的、可独立描述的。比如“读取数据”是一个合理的步骤粒度“读取数据的前三行”就太细了“处理数据”又太粗了。4. 实际项目中的经验与避坑指南4.1 常见问题速查表问题现象根本原因解决方案子类越来越多继承层次过深把不相关的场景硬塞进同一个继承体系考虑组合替代继承或者拆分成多个独立的模板体系父类改动导致所有子类受影响父类中放了太多具体实现耦合过重把可变逻辑下沉到子类父类只保留流程骨架某个子类需要跳过中间步骤流程设计时没有预留钩子增加钩子方法控制步骤是否执行而不是让子类覆盖模板方法模板方法被子类意外覆盖没有用final修饰或者访问权限设置不当模板方法用final修饰步骤方法用protected修饰子类之间出现大量重复代码抽象方法划分不合理通用逻辑没有上提到父类重新审视步骤划分把重复逻辑提取到父类的默认实现中4.2 我踩过的三个坑第一个坑模板方法忘了加final。有一次我在做代码审查的时候发现某个子类把模板方法给覆盖了在里面加了一段自己的逻辑。结果就是流程完全乱套了其他子类的行为跟它不一致排查了半天才发现问题。从那以后我写模板方法第一件事就是加final。第二个坑钩子方法命名不清晰。我见过一个项目里钩子方法叫doSomething()子类开发者根本不知道这个方法在什么时机被调用也不知道覆盖它会产生什么影响。后来我们统一了命名规范钩子方法用on开头比如onValidationFailure()、onBeforeExport()一看就知道是回调时机。第三个坑步骤方法之间产生了隐式依赖。比如parse()方法默认read()方法已经完成了数据读取但如果某个子类覆盖了read()却没有正确填充数据parse()就会出错。这种隐式依赖在模板方法模式里很常见解决办法是在父类的模板方法中做好参数传递让步骤之间的数据流显式化而不是依赖实例变量来传递状态。4.3 什么时候不该用模板方法模式模板方法模式不是万能的。如果你的场景满足以下任一条件我建议你换别的方案流程本身不固定如果每个场景的流程步骤都不一样那模板方法模式就失去了基础。这种情况下策略模式或者责任链模式可能更合适。子类数量极少且稳定如果只有两个子类而且未来也不太可能增加那直接写两个类可能比引入继承体系更简单。需要运行时动态切换流程模板方法模式是编译期确定的继承关系没法在运行时动态改变流程。如果需要动态切换考虑策略模式加组合。团队对继承体系有抵触有些团队推崇“组合优于继承”的原则如果团队规范不允许使用继承那就用策略模式加回调接口来替代。5. 模板方法模式在框架中的典型应用5.1 框架设计中的骨架抽象如果你去看一些主流框架的源码会发现模板方法模式无处不在。比如Spring框架里的JdbcTemplate它把“获取连接→执行SQL→处理结果→释放连接”这个流程定死在模板方法里你只需要提供SQL和结果映射逻辑就行。再比如JUnit的测试生命周期setUp()、testMethod()、tearDown()的调用顺序就是典型的模板方法模式。框架设计者喜欢用模板方法模式因为它能很好地控制扩展点。框架把核心流程锁死保证稳定性和一致性同时通过抽象方法和钩子方法给使用者留出扩展空间。这种“框架控制流程使用者填充细节”的模式是框架设计中最常用的手法之一。5.2 与策略模式的对比与选择很多人会把模板方法模式和策略模式搞混因为它们都涉及“把可变部分抽象出来”。但两者的机制和适用场景有本质区别。对比维度模板方法模式策略模式实现机制继承组合变化维度流程中的某些步骤整个算法控制权父类控制流程调用方控制算法选择运行时切换不支持支持扩展方式新增子类新增策略实现类适用场景流程固定、步骤可变算法可替换、需要动态切换简单来说如果流程骨架是固定的只是某些步骤的实现不同用模板方法模式如果整个算法都需要替换而且需要在运行时动态选择用策略模式。两者也可以结合使用用模板方法模式定义流程骨架用策略模式处理其中某个需要动态切换的步骤。5.3 在测试代码组织中的妙用模板方法模式在测试代码里也很有用。比如你要测试多个类似的接口每个接口的请求参数和断言逻辑不同但测试流程是一样的准备数据→发送请求→校验响应→清理数据。这时候就可以用一个抽象测试基类定义这个流程子类只需要提供请求参数和断言逻辑。public abstract class ApiTestBase { Test public void testApi() { Object request buildRequest(); Object response sendRequest(request); assertResponse(response); cleanup(); } protected abstract Object buildRequest(); protected abstract Object sendRequest(Object request); protected abstract void assertResponse(Object response); protected void cleanup() { // 默认清理逻辑 } }这样每个接口的测试类只需要实现三个方法测试流程完全复用。新增接口时写一个子类就行不用再重复写测试流程。6. 进阶技巧与扩展思路6.1 用组合替代继承的改造方案虽然模板方法模式基于继承但在某些场景下你可以用组合来达到类似的效果同时避免继承带来的耦合问题。具体做法是把流程骨架定义在一个类中把可变步骤抽象成接口通过构造函数注入具体的步骤实现。public class DataExporter { private final Connector connector; private final Reader reader; private final Parser parser; public DataExporter(Connector connector, Reader reader, Parser parser) { this.connector connector; this.reader reader; this.parser parser; } public final void export() { connector.connect(); ListString raw reader.read(); ListRecord records parser.parse(raw); // ... 后续流程 } }这种改造的好处是步骤实现可以在运行时替换不受继承体系的限制每个步骤可以独立测试类之间的耦合更松散。缺点是代码量会多一些而且流程的扩展点不如继承体系那么直观。6.2 模板方法模式的性能考量模板方法模式本身对性能几乎没有影响。它只是把方法调用组织了一下没有引入额外的运行时开销。唯一需要注意的是如果步骤方法中有频繁的I/O操作或者复杂计算那性能瓶颈在这些操作本身跟模式无关。不过有一个细节值得注意如果模板方法中的某个步骤在子类中经常被覆盖成空实现那这个步骤的方法调用就变成了无意义的开销。虽然单次调用开销极小但在高频调用的场景下也值得考虑。解决办法是把这个步骤设计成钩子方法并且在模板方法中加一个条件判断只在需要的时候调用。6.3 模板方法模式与开闭原则的关系模板方法模式是开闭原则的一个经典体现。对扩展开放你可以通过新增子类来扩展新的步骤实现对修改关闭流程骨架定义在父类中新增子类不需要修改父类的代码。但这里有一个微妙的平衡点如果父类的流程需要调整那所有子类都会受影响。所以设计父类的时候要尽量考虑周全把可能变化的点都预留成钩子方法。当然你不可能预判所有变化所以适度的重构是必要的。当流程需要调整时改父类一处所有子类自动生效这本身就是模板方法模式的价值所在。6.4 在微服务编排中的应用思路在微服务架构中模板方法模式可以用来编排服务调用流程。比如一个订单处理流程校验订单→扣减库存→生成支付单→发送通知。这个流程是固定的但每个步骤的具体实现可能因业务类型不同而不同。你可以定义一个抽象的订单处理模板把每个步骤定义为抽象方法或钩子方法不同的业务类型提供不同的子类实现。这种做法的好处是流程统一、易于监控和排查。所有订单都走同一套流程骨架日志打点、异常处理、超时控制都可以在父类中统一实现。子类只需要关注自己的业务逻辑不用操心流程控制。7. 我个人在实际操作中的体会模板方法模式是我在日常开发中使用频率最高的设计模式之一没有之一。它的概念简单但威力很大。我总结下来用好它的关键就三点流程骨架要稳定步骤划分要合理扩展点要清晰。流程骨架稳定是前提。如果流程本身经常变那模板方法模式反而会成为负担。步骤划分合理是核心划分得太细会导致子类实现成本高划分得太粗又会导致重复代码。扩展点清晰是保障抽象方法和钩子方法的边界要明确命名要规范让子类开发者一眼就能看懂哪里该实现、哪里可以覆盖。还有一个很实用的经验在写模板方法模式的时候先写两个具体的子类然后再提取父类。不要一上来就设计父类那样很容易设计过度。先写两个具体的实现看看哪些代码是重复的哪些是不同的然后把重复的往上提不同的留成抽象方法。这样提取出来的父类才是最贴合实际的。最后分享一个小技巧如果你不确定某个步骤该设计成抽象方法还是钩子方法那就先设计成钩子方法。因为钩子方法更灵活子类可以选择覆盖也可以不覆盖。如果后来发现所有子类都覆盖了它那再改成抽象方法也不迟。反过来如果一开始设计成抽象方法后来发现有些子类不需要实现那就得改父类成本更高。

模板方法模式：流程固定步骤可变的代码复用利器

相关推荐

硅光可靠性标准落地：代工厂与封测厂责任边界如何划分？

最大子矩阵和：从暴力到O(n³)的降维优化与Kadane算法实战

Python 3.7 + PyInstaller 3.6 封装实战：从踩坑到优化

更多资讯

Qt QPainter绘图全面解析：从Basic Drawing示例到实战技巧

实数FFT原理与工程实践：从共轭对称性到嵌入式优化

倒水问题：从5L和3L桶装4L水到BFS算法与状态空间搜索

Python PIL图片尺寸调整：从原理到批量处理与性能优化实战

PriorityBlockingQueue深度解析：从线上事故到避坑实战

基于Nodejs+Vue的商城系统开发实战：从环境配置到部署上线

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？