我不是第一次在代码评审里看到这种场面五六个方法体几乎一模一样的 Service各自复制粘贴后小改两行然后整整齐齐地排在一个类里。改动一个公共逻辑要全局搜索替换漏改一处就线上报警。行为型设计模式里模板模式Template Method Pattern专门对付这类“流程固定、细节多变”的场景。它把算法的骨架定义在父类里把无法确定的具体步骤延迟到子类实现听着简单但用得好不好差别很大。这篇博文我会结合一次我参与过的支付渠道对接项目把模板模式的原理、结构、选型边界、坑点和框架里的实际应用串起来讲。不吹概念全部是可落地的思路和代码级细节。适合已经写过一段时间业务代码、想在抽象这条路上做出可靠设计的朋友也适合面试前把行为型模式彻底想明白的人。1. 模板模式的核心思想与适用场景1.1 一句话讲清楚模板模式模板模式的定义不复杂在一个方法里定义算法的骨架把某些步骤延迟到子类实现。父类负责控制流程、把握顺序、处理公共逻辑子类只负责填充自己特有的步骤。真实项目里最常见的非典型写法是“复制粘贴式扩展”。比如对接三家支付渠道每家都要求“验签 → 构造报文 → 发起请求 → 解析响应 → 落库”。第一版只对接一家时你很爽直接写一个 Service 全搞定。等第二家接入时你复制了整个方法改一改等第三家接入时你已经有三份几乎一样的代码。有问题时可能只有其中一家的验签方式不一样你却要维护三整套流程。模板模式解决的就是这个困境。它把“验签 → 构造报文 → 发起请求 → 解析响应 → 落库”这个流程骨架固定下来放在抽象父类里。每一家渠道只需要继承父类实现自己特有的那部分逻辑比如“验签算法”和“报文格式”。流程的稳定性与步骤的差异性被清晰地分开了。它最好用生活里的做法解释做饭馆里卖得最好的那道菜后厨会提前定好标准作业程序洗菜、切配、焯水、爆炒、装盘都有严格顺序。但不同客人可能要求少辣、免葱、多放蒜。后厨不会因为一个客人改口味就重写整个流程而是在标准流程允许的位置做局部调节。模板模式的父类就是这个标准作业程序子类就是针对不同口味的局部调节。1.2 它解决的核心痛点流程复用与扩展约束如果只说“复用”很多开发者会觉得继承本来就能复用。模板模式真正的价值其实有两个层次。第一层确实是消灭重复代码父类把公共算法收敛起来子类只写差异部分。但光这层还不够因为抽象方法也能做到。第二层更关键它通过流程顺序的控制强制所有子类遵循同一种执行顺序。比如所有支付渠道都必须先验签再请求这个顺序你写在父类的模板方法里子类想跳过都不可能。反向思考一下如果不用模板模式会怎样。接口加一个公共逻辑比如所有渠道请求前要打印完整的请求报文日志用抽象父类你只需要改一处不用模板模式你就要去每个渠道实现里手工补。漏掉一个渠道就是线上事故。模板模式让“流程不可破坏”成为可能这是它作为行为型模式区别于单纯继承复用的核心点。再补一个容易被忽略的好处模板模式天然适合团队协作。父类定好骨架和抽象步骤组长把接口定清楚组员每人认领一个子类去填实现。因为流程顺序已经锁定合并代码时几乎不会出现“有人把顺序改了导致结果不一致”的情况。并行开发的安全感这是我在实际项目管理中感受最直观的价值。1.3 什么场景该用它判断一个场景适不适合套模板模式我一般用三个问题自测这个业务是否存在一个固定的操作流程或算法步骤顺序不会随便变不同实现之间是否存在大量公共逻辑只有部分步骤差异化是否希望后续新增实现时强制遵循现有流程三个问题全是肯定回答那就大胆用。典型的例子包括多渠道支付对接、多类型文件导入解析、报表生成器、数据迁移管道、测试框架中的用例执行流程、游戏角色技能释放流程。尤其是“接入第三方系统”这类场景非常适合因为第三方系统各有各的签名算法、报文格式、重试策略但请求的整体节奏是一致的。反过来如果流程本身就不稳定今天三步明天五步每步子类的实现差异又非常大几乎没有什么公共逻辑那不要硬套模板模式。这种情况下模板父类除了一个空壳流程什么都给不了反而用策略模式更灵活。2. 模板模式的结构拆解与角色分工2.1 三个核心角色模板模式的结构里通常有三个角色每个都对应清晰的职责边界。第一个是抽象模板类AbstractClass。它定义了算法的骨架通常会包含三类成员。模板方法本身是 final 的它控制整个流程的顺序子类不能重写。抽象方法是被延迟到子类的步骤一般用 protected abstract 修饰。具体方法则是所有子类共享的公共逻辑写在父类里直接实现。第二个是具体实现类ConcreteClass。它继承抽象模板类实现那些抽象方法。每个具体类代表一种场景或一套参数下的完整流程但自己不控制流程顺序。还有一个容易被忽视的角色钩子方法Hook。钩子不是必须实现的抽象方法而是一个有默认实现的普通方法。子类可以通过重写钩子方法在流程的特定节点插入自己额外的逻辑或者改变流程中某一步是否执行。它本质上是框架留给扩展的“插槽”。三者的关系可以用一个比喻理解模板方法是舞台监督手里的流程单每一步都写得清清楚楚具体实现类是上台的演员只负责打磨自己的戏份钩子是观众互动环节不需要可以没有但演员想加戏就必须在这个环节上。2.2 模板方法、抽象方法、钩子方法的区别这个三兄弟的差别很多初学者容易糊涂。我整理一张表直接对比它们的本质。类型修饰符特征子类能否重写用途模板方法public final不能定义算法骨架控制流程顺序抽象方法protected abstract必须实现强制子类提供差异化步骤钩子方法protected非抽象带默认实现可选重写灵活的扩展点干预流程细节公共具体方法private 或 protected final可以调用不能重写封装公共算法步骤设计父类时这三类方法的取舍直接决定了骨架的刚性。模板方法必须 final这是纪律性的体现。如果把模板方法开放给子类重写抽象父类对流程的控制就形同虚设所有子类都能自己重新编排流程那模板模式等于没用了。这不是语法规定但类设计者应该在代码注释里明确这个纪律代码评审时也要重点盯这个。抽象方法的粒度也要控制好。太粗了子类实现里还会出现重复代码太细了子类会实现大量只差一行的抽象方法类变得臃肿。我见过一个不好的例子把“取数据库连接”和“设置查询参数”都拆成抽象方法结果每个子类里都要重复写连接参数这类逻辑放在父类公共方法里更合理。抽象方法要拆到“子类之间差异的真实边界”为止。钩子方法的设计更考验经验。一个常用的实践是给钩子方法提供“默认开”或“默认关”的合理默认值。比如默认开启日志记录子类不需要关心日志时什么都不用做默认不开启某种延展动作子类想加时重写钩子返回 true 就行。好的钩子默认值应该符合大部分子类的实际需求让它们尽量少写代码。2.3 好莱坞原则在模板模式中的体现模板模式背后是一个挺有名但常被忽略的原则叫“好莱坞原则”Dont call us, well call you别给我们打电话我们会打给你。映射到代码里就是子类不在自己的方法里主动调用父类的流程而是父类的模板方法在合适的时机主动调用子类实现的方法。这个反向控制结构对理解模板模式来说非常关键。很多人第一次写模板模式时不适应觉得子类明明是独立的类怎么反而被父类牵着走。其实这正是框架思维的开端。你写一个子类实现抽象方法并不会立刻被调用而是当外部代码调用父类的模板方法时模板方法内部会按顺序反过来调用你这个子类的实现。这也解释了模板模式为什么是“反向控制”的雏形。后来的 IoC 容器、Spring 的回调机制都有类似的影子。你可以说模板模式是很多开发者接触到的第一个容器思想的代码级呈现。2.4 在 GUI 框架中的应用如果要找模板模式最直觉的例子图形界面框架里的绘制流程是最好的。一个窗口控件从创建到显示中间经历的步骤几乎是固定的创建对象、设置布局、绘制背景、绘制子元素、绘制前景、处理事件循环。任何自定义控件都不需要重写整个绘制流程只需要实现一个 onPaint() 方法。框架在合适的时机回调它在它前后自动完成背景清理和画布准备。这和一个成熟的游戏渲染循环也很贴近。游戏引擎把“每帧更新”的骨架定义好了开发者只需要把“更新自己角色的具体逻辑”填进指定的 update() 方法。对开发者来说你不用关心引擎内部怎么计算帧间隔、处理垂直同步这些都在父类里去做了。这种使用体验就是模板模式去皮之后最朴实的形态。3. 实战案例支付渠道通用对接框架3.1 业务背景与父类骨架定义讲理论有点干我来还原一次我参与过的支付对接项目。当时需要同时接入微信支付、支付宝、银联云闪付三个渠道每个渠道都有各自的验签规则、报文结构、请求方式、回调验签逻辑。按传统复制粘贴的做法每家写一套完整流程出问题后定位成本极高。我们决定用模板模式做一个通用对接层让所有渠道都走同一条流程管线。抽象父类叫 AbstractPayChannel里面定义了一个 final 的 pay() 方法作为模板方法流程固定为参数校验 → 构建渠道专属请求参数 → 加签 → 发起 HTTP 请求 → 解析响应 → 验签 → 落库更新。代码如下public abstract class AbstractPayChannel { // 模板方法定义整个支付流程骨架子类不可重写 public final PayResult pay(PayRequest request) { // 1. 公共参数校验 validate(request); // 2. 构建渠道专属参数子类实现 MapString, String params buildChannelParams(request); // 3. 加签子类实现 String sign sign(params, request.getSecretKey()); params.put(sign, sign); // 4. 发起请求公共方法走统一 HTTP 客户端 String response doPost(request.getGatewayUrl(), params); // 5. 解析渠道响应子类实现 PayResponse payResponse parseResponse(response); // 6. 验签子类实现 boolean verify verifySign(payResponse, request.getSecretKey()); if (!verify) { throw new PayException(渠道响应验签失败); } // 7. 落库更新公共逻辑 updateOrderStatus(payResponse); // 8. 钩子允许子类做额外的后置处理 afterPay(payResponse); return buildResult(payResponse); } // 公共方法统一参数校验 private void validate(PayRequest request) { if (request.getAmount() null || request.getAmount() 0) { throw new PayException(金额非法); } if (StringUtils.isBlank(request.getOutTradeNo())) { throw new PayException(商户订单号不能为空); } } // 公共方法统一发起 HTTP 请求 private String doPost(String url, MapString, String params) { // 使用统一的 HTTP 客户端带上公共超时配置 return HttpUtil.post(url, params); } // 公共方法统一更新订单状态 private void updateOrderStatus(PayResponse response) { // do something } // 公共方法统一构建返回结果 private PayResult buildResult(PayResponse response) { return PayResult.success(response.getChannelOrderId(), response.getPayStatus()); } // 抽象方法子类必须实现渠道专属逻辑 protected abstract MapString, String buildChannelParams(PayRequest request); protected abstract String sign(MapString, String params, String secretKey); protected abstract PayResponse parseResponse(String response); protected abstract boolean verifySign(PayResponse response, String secretKey); // 钩子方法默认空实现子类按需重写 protected void afterPay(PayResponse response) { // 默认什么都不做 } }3.2 抽象方法与公共方法的边界划分写这个父类时最费心思的不是流程本身而是每步到底该做成抽象方法、公共方法还是钩子。我当时的划分逻辑很简单凡是所有渠道行为一致的步骤全部做成 private 的公共方法比如参数校验、HTTP 请求、落库更新。凡是每个渠道差异明显的步骤做成 protected abstract比如参数构建、加签、解析响应、验签。凡是“大部分渠道不需要但不排除个别渠道需要”的步骤做成钩子比如支付成功后的短信通知或其他定制后置动作。其中最需要解释的是为什么验签是抽象方法而不是公共方法。因为三个渠道的验签算法各不相同微信用 HMAC-SHA256支付宝用 RSA2银联有自己的证书验签流程。用同一个函数签名去抽象它们其实已经是一种妥协但对于上层流程而言它只需要知道“这一步做了验签”就足够了。而我特意没有把“加签”和“验签”合并成一个抽象方法是因为它们的输入输出差异太大。加签处理的是请求参数验签处理的是响应数据分开更清晰。3.3 具体渠道子类的实现方式有了父类之后接入一个新渠道就变成一件很机械的事。以微信支付为例子类长这样public class WechatPayChannel extends AbstractPayChannel { Override protected MapString, String buildChannelParams(PayRequest request) { MapString, String params new HashMap(); params.put(appid, request.getAppId()); params.put(mch_id, request.getMchId()); params.put(out_trade_no, request.getOutTradeNo()); params.put(total_fee, String.valueOf(request.getAmount().multiply(100).intValue())); params.put(body, request.getSubject()); return params; } Override protected String sign(MapString, String params, String secretKey) { String content buildSignContent(params); return HmacSha256Util.digest(content, secretKey); } Override protected PayResponse parseResponse(String response) { // 解析微信支付的 XML 响应 return WechatResponseParser.parse(response); } Override protected boolean verifySign(PayResponse response, String secretKey) { // 微信支付回调时的验签逻辑 return WechatSignVerifier.verify(response.getRawData(), response.getSign(), secretKey); } }接入支付宝就再写一个 AlipayPayChannel接入银联就写一个 UnionPayChannel。每个子类只关注“自己渠道的差异逻辑”流程怎么走、什么时候校验、什么时候落库全都交给父类。当时我们这个框架上线后后期新增一个渠道的工时从原来的两天压缩到半天左右主要时间都花在阅读对方渠道的文档上代码量反而很少。3.4 钩子方法的两个实际用法钩子方法在支付项目里最常用的就是 afterPay()。普通渠道支付成功后的后置动作都是相同的所以父类里的默认实现是空方法什么都不做。但有一个渠道比较特殊用户在支付成功后需要跳转一个合作方的落地页于是我们在这个渠道的子类里重写了 afterPay()额外拼接落地页参数并做了跳转。这个逻辑不影响主流程又不愿意污染公共模板用钩子干干净净地插进去。另一个钩子用法是控制流程分支。比如我们定义一个 protected boolean needRetry() 钩子默认返回 false。某个渠道的网络稳定性比较差就在子类里重写返回 true。然后在父类的模板方法里把发起请求那一步包裹进一个重试循环int maxRetryTimes needRetry() ? 3 : 1; for (int i 0; i maxRetryTimes; i) { try { response doPost(request.getGatewayUrl(), params); break; } catch (RemoteTimeoutException e) { if (i maxRetryTimes - 1) { throw e; } } }这个设计让“是否重试”从固定流程里解耦出来变成了子类可选决策整体代码整洁度提升不少。我个人在使用钩子时有一条原则钩子数量不要超过两三个越多会越难读懂父类到底在做什么。钩子的命名也要体现“可选性”最好用 canXxx、needXxx、afterXxx、beforeXxx 这种词让人一眼就知道这是可选的扩展点。4. 模板模式与策略模式的边界与选型4.1 一个经典误区模板模式和策略模式不是一回事我在面试候选人和做代码评审时发现很多人分不清模板模式和策略模式。其实两者解决的问题有重叠但思路完全不同。策略模式重点是“算法整体可替换”它把一整个算法封装成独立对象通过组合的方式让运行时机动态选择。模板模式重点是“算法骨架固定局部步骤可变”它用继承的方式在编译期固定流程。举个具体例子。策略模式里一个优惠计价器有满减、折扣、会员价三种算法你可以运行时自由切换算法之间彼此完全独立没有公共流程。模板模式里支付渠道三家的流程大体一致只是细节不同骨架不可变。如果用策略模式做支付渠道等于把整个支付流程塞进三个策略类里公共逻辑还是得抽出来但抽出来之后策略类之间没有任何结构化约束很容易出现实现差异。选型时我常用一个判断标准如果差异点是整个算法层面的替换本质上是“换一种做法”用策略模式更合适如果差异点是某个固定流程中的若干步骤本质上是“同一个流程的不同细节”用模板模式更合适。混淆这两者代码写出来你会发现要么抽象封装太松散要么继承层级太僵硬。4.2 组合与继承的取舍模板模式建立在继承之上这让它在某些场景下显得不够灵活。Java 是单继承一个子类只能继承一个抽象父类如果一个类既要做支付渠道又要做对账流程模板模式就无能为力。这时可以用策略模式加组合把两个能力委托给两个不同的组件对象。但组合不是银弹。当流程结构非常稳定且公共逻辑较多时继承带来的代码复用和结构约束反而比组合更直观。我现在写代码时不会刻意回避继承关键是判断继承的层级是否会失控。模板模式的继承层级严格控制在两层到三层是最舒服的超过三层每次改父类逻辑的影响面就会变得难以预测。在实际项目中我偶尔也会把模板模式和策略模式结合使用。抽象模板类里某个步骤的实现可以通过策略接口来委派这样既保留流程骨架的稳定性又让局部的算法可动态切换。比如支付渠道的验签算法可以在子类里注入一个验签策略对象而不是直接硬编码到子类里。这个组合玩法比较高阶但确实能解决很多复杂场景。4.3 一个决策表模板模式还是策略模式如果看完上面的分析还是拿不准可以对照这张决策表。判断维度选用模板模式选用策略模式核心诉求固定流程、复用公共代码、强制顺序灵活替换整套算法流程稳定性流程基本不变流程本身可能变公共代码量公共逻辑多差异点少公共逻辑少差异点大绑定方式继承编译期绑定组合运行期绑定扩展方式新增子类实现抽象方法新增策略类动态注入适用例子支付渠道、报表生成、数据导入优惠计价、压缩算法、路由策略真实开发中很多系统两种模式会同时出现。模板模式管流程骨架策略模式管某个步骤的算法选择。你不需要把它们对立起来理解各自的侧重点组合使用才能写出好维护的架构。5. 使用模板模式最容易踩的几个坑5.1 子类重写模板方法这是模板模式最致命的反模式也是我见过最多的错误。有人觉得模板方法加个 final 太死板或者他根本没意识到模板方法不能重写直接在子类里 override 了整个模板方法然后把自己的一套流程写进去。这样父类对流程的控制完全失效公共逻辑也不再被强制复用等于模板模式名存实亡。我在代码规范里明确要求模板方法必须声明为 final并且通过静态检查工具扫描是否存在对模板方法的重写。如果子类确实需要完全不一样的流程说明这个子类根本不适合用模板模式应该把它拆出去用别的方式实现而不是在模板模式体系里开一个破坏规则的口子。5.2 钩子方法过多导致阅读困难钩子是模板模式的润滑剂但用多了会变成下水道。网上很多人推崇钩子甚至是父类里堆了五六个钩子方法子类每个都重写一遍最后父类的模板方法里插满了 if 判断。这种情况下阅读者想搞懂整个流程时必须逐个子类去对照钩子的返回值思维负担非常大。我的建议是钩子数量控制在两个以内。超过两个就要反思是不是公共流程切分有问题。钩子应该承担真正的“分支决策”或“后置扩展”不应该承担“补丁式”的临时逻辑。有一次我把一个钩子用作临时数据修正后来数据修正逻辑不断膨胀钩子方法里塞了几十行代码后来重构时把它移到了公共方法里父类结构一下子清爽了很多。5.3 继承层级过深模板模式天然鼓励继承但很多人写着写着就把层级叠得很深。抽象父类 → 中间抽象类 → 再抽象一层 → 具体实现。每多一层理解和调试的复杂度就翻一倍。现实中三层继承已经接近维护上限四层以上基本就是可读性灾难。出现多层继承往往意味着抽象粒度没把握好。比如最开始父类是 AbstractPayChannel后来发现微信和支付宝都有“扫码支付”和“H5 支付”于是又抽出一层 AbstractWechatMultiModeChannel。如果再往后发现小程序支付和公众号支付还有差异再抽一层。等层级到了一定数量任何一层的小改动都要仔细分析影响到了多少子类。我的经验是如果发现层级超过三层优先考虑用一个组合或者策略来替代中间抽象层。把变化的维度拆到组件里而不是无限地用继承细分。继承应该表达“这个子类是一种父类”而不是表达“这个子类拥有某个特性”。5.4 单元测试容易忽略模板父类逻辑很多开发者为每个具体子类写单元测试却漏掉了抽象父类里的公共流程。从覆盖率来说这算个盲区。模板方法的流程一旦出错所有子类都会受影响但如果你只在子类里测试父类流程的问题会被隐藏成子类问题排查起来绕圈子。比较好的测试策略是先写一个假的子类只实现最小的抽象方法专门用来测父类的模板方法流程。验证流程顺序是否按预期执行、异常路径是否正确处理、钩子方法是否能影响流程分支。然后再针对真实业务子类测试差异逻辑。这样既保住了骨架的正确性又保住了差异实现的正确性。5.5 注意抽象方法调用的时机父类的构造函数里如果调用了抽象方法这是一个隐蔽的坑。Java 在初始化子类时会先调用父类构造器而父类构造器里调用抽象方法时子类还没完全初始化此时子类字段可能为 null很可能抛出空指针。我一个朋友遇到过这个经典问题抽象父类构造时调用了一个抽象方法 initChannel()子类 override 后在 initChannel() 里读取了自己的 apiKey 字段结果 apiKey 还没赋值直接空指针。解决方案很简单不要在构造器里调用抽象方法把初始化逻辑推后到模板方法的第一步或者用钩子方法加一个 default 实现。我自己后来写模板模式时初始化逻辑一律放到模板方法流程里不在构造函数里做任何动态行为。6. 主流框架中的模板模式应用6.1 Spring 里的模板类Spring 的 JdbcTemplate 就是模板模式的典型应用。它把“获取连接、创建 Statement、执行 SQL、遍历结果集、处理异常、关闭资源”这些步骤封装成模板开发者只需要实现回调方法里的“如何解析每行数据”。你写查询不需要关心资源释放但你必须实现 RowMapper 接口告诉框架一行数据映射成什么对象。Spring 的 RestTemplate 也体现了类似思想。它把 HTTP 请求的完整流程模板化无论 GET、POST、PUT底层的连接管理、超时设置、错误处理统一固化开发者只需要提供 URL、请求体、响应类型就能完成调用。6.2 JDK 里的模板模式JDK 的 AbstractList 是另一个教科书级的例子。它把 list 的大部分操作基于 get() 和 size() 两个抽象方法实现。你继承 AbstractList 只需要实现 get(int) 和 size()就自动拥有了迭代、查找、子列表等一整套功能。这就是模板模式在基础设施层的威力。InputStream 也类似。read() 抽象方法定义了单字节读取而 read(byte[], int, int) 是建立在它之上的模板方法。子类只需要实现单字节读取就能获得整个批量读取和流操作能力。6.3 中间件与框架的扩展点设计很多中间件设计也是模板模式思路。比如 Tomcat 处理请求的管道定义了一整套过滤链流程开发者在配置里插入过滤器框架在固定的节点调用它们。再比如很多批处理框架把“读取 → 处理 → 写入”定义成固定管线开发者只需要实现 Reader、Processor、Writer 三个步骤。这类框架使用体验的核心就是模板模式的思想。理解了模板模式再看框架你能明显感受到框架设计者在“控制流程”和“开放扩展”之间的良苦用心。骨架是你改不动的纪律扩展点是你可以自由创作的空间。7. 动手优化从一个坏味道到模板模式7.1 识别代码里的模板模式需求识别需要重构为模板模式的代码最直观的信号是看是否存在大量的方法级复制粘贴。比如三个类里各有一个 export() 方法方法体几乎一样只是中间某个转换函数不同。那 export() 就是潜在的模板方法那个转换函数就是潜在的抽象方法。我分享一个三分钟定位法。挑出一个典型实现把它的方法步骤编号写出来。然后拿另一个实现对照看哪些步骤的代码完全一样哪些步骤有差异。公共部分越多越值得模板化差异部分越集中抽象方法的边界越清晰。7.2 重构步骤详解假设原来有三个独立的导出器CsvExporter、ExcelExporter、PdfExporter每个里面都有完整流程。重构时可以这样操作。第一步新建抽象父类 AbstractExporter把公共流程的骨架代码复制进去写成 final 的模板方法。第二步把流程中有差异的步骤提取成抽象方法签名尽量抽象能覆盖三家差异的最小集合。第三步让三个导出器继承 AbstractExporter删除它们各自的重复流程代码只保留差异实现。第四步跑一遍原有测试集对比导出结果是否一致。重构期间最容易出的问题是抽象方法签名定得太具体。比如 Excel 导出需要设置列宽参数CSV 不需要如果抽象方法 signature 里有 columnWidth 参数CSV 实现就很尴尬。这时可以把列宽设置变成另一个钩子而不是硬塞进公共签名里。这个设计取舍很考验经验我的建议是抽象方法以业务意图为单位而不是以参数差异为单位。7.3 重构后的收益量化重构到底值不值可以用几个数字来评估。复制粘贴版本里一个公共流程修改要改动三个文件重构后只需要改父类一个文件原来新增一种导出格式需要几乎重写整个流程重构后只需要实现几个抽象方法公共逻辑的覆盖率从三份实现分别测试变成一个父类测试加三个差异测试测试成本显著下降。这类量化数据在向团队或上级汇报重构收益时非常有用也能让你判断重构的投入产出比。8. 模板模式的扩展玩法与个人经验8.1 用模板模式做统一校验编排除了典型的外接渠道场景模板模式还可以做业务校验编排。比如一个下单接口固定流程是参数校验、库存校验、价格校验、风控校验、落单。每一步校验器各不相同但编排结构固定。抽象父类定义验证流程子类实现不同的校验细节公共结果统一收集。这种玩法的好处是校验逻辑可以轻松扩展到新业务线。新业务线只需要新增一个子类配置到流程里即可不需要改动原有编排。实际项目中我把一套下单流程的校验从 if-else 改造成模板模式后新增校验规则的效率提升非常明显。8.2 模板模式与函数式接口的对比在 Java 8 之后函数式接口和 Lambda 提供了一种比继承更轻量的做法。比如 JdbcTemplate 的 execute 方法你可以传一个 PreparedStatementCallback 的 Lambda相当于一步到位地代替了定义一个匿名子类。那模板模式是不是过时了我的看法是模板模式作为设计思想永远不过时只是实现载体可以更现代。当一个流程需要被多个类复用并且有较多公共状态时继承式模板模式还是最自然的选择。但如果你只需要复用一段简单的流程并且差异点就一两个方法直接用函数式接口配 Lambda 会清爽很多。技术选型千万不要有偶像包袱设计模式不是信仰是为了让代码更好维护。8.3 钩子与模板方法的一个进阶组合一个进阶做法是模板方法配合持有状态的对象。比如模板父类维护一个结果收集器模板方法分步执行时每一步把结果暂存进去钩子方法可以在最终阶段读取这些状态做后处理。这本质上把流程中产生的过程数据传递给扩展点能力比传统钩子强不少。我做过一个数据同步管道不同数据源同步流程固定为“抽取 → 清洗 → 转换 → 加载”但由于每个环节都可能产生中间产物钩子方法需要读取前面的产物。那时我就在父类里引入一个 PipelineContext每个步骤都往里面写钩子只接收 context。这样钩子可以访问的上下文足够丰富又不用为了传参给抽象方法加一堆无关参数。8.4 模板模式的未来视角设计模式是经验的结晶模板模式这几年在框架设计里的形态已经悄然进化。比如 Java 的 HttpClient 提供了 send 和 sendAsync 两个固定模板方法开发者只需要提供 BodyPublisher 和 BodyHandler。这里模板方法不再依赖继承而是通过函数式参数完成流程控制。核心思想没有变变的只是载体。我认为理解设计模式最正确的姿势是先搞懂经典形态知道它解决什么本质问题然后看框架里怎么演化最后在自己的代码里能识别问题、选对形态。模板模式从继承到函数式本质依然是把不变的流程与变化的步骤分离。这个分离的思想放之四海而皆准。9. 面试中模板模式的高频追问模板模式在面试中出现的频率不算低但十个人里有八个都只讲“抽象类里定义骨架子类实现差异”这句话。面试官继续追问就答不上来了。这里梳理几个高频追问和参考思路。第一个高频问题模板方法的 final 关键字是必须的吗回答思路是必须写它是控制流程不被破坏的基本前提。然后补一句即使语言允许开放也应该通过命名规范约定为不可重写。这就能体现你的经验。第二个高频问题模板模式和策略模式有什么区别回答思路是先说清楚各自结构上的不同继承与组合、编译期绑定与运行期绑定。然后举一个业务场景同时解释两种方案分别怎么设计最后说明什么场景选谁。能结合代码经验讲基本上就是加分项。第三个高频问题为什么模板模式能体现好莱坞原则回答思路是解释子类不主动调用父类而是由父类模板方法在合适的时机回调子类实现。同时分享一下你在看 Spring 源码时对“框架反向控制”的体会。如果你能讲清楚这个面试官通常不会再追问了。第四个高频问题模板模式里钩子的意义是什么回答思路是钩子提供可选的扩展点让子类能在不影响流程结构的前提下干预流程细节。你还可以顺势提一下构建 PipelineContext 的进阶玩法展示你踩过坑后的深度理解。10. 常见问题速查表我把这些年实际项目中遇到的模板模式问题整理成一个速查表有类似症状可以直接对照。现象可能原因解决办法子类重写了模板方法父类模板方法未加 final立即加上 final 并代码评审排除模板父类改动导致多个子类异常公共逻辑封装不够充分或层级过深提炼公共方法控制继承层级子类新增后总有逻辑遗漏遗漏了某个抽象方法或钩子把关键步骤声明为 abstract钩子选好默认值父类构造函数空指针构造器里调用了抽象方法初始化逻辑延迟到模板方法第一步钩子方法里塞了太多逻辑钩子被当成了补丁入口收敛钩子数量把通用逻辑提到公共方法子类实现里还有重复代码抽象方法粒度太粗继续下钻差异点重新划分抽象边界新增一种实现很困难抽象方法签名设计不合理以业务意图为单位设计抽象签名用钩子承载附加参数流程顺序被破坏某子类直接 override 了模板方法模板方法 final配套 lint 规则检测这张表我建议你收藏在团队代码评审时直接拿出来当检查清单用比临时讲道理好使。最后再分享一个自己在建模时常用的提炼思路。我会先写出一个最简单的流程实现把它在纸上画成若干步骤。然后拿第二个场景来实现看两个流程的差异点到底落在哪几步。差异点越稳定的地方越适合抽象成方法差异点越容易变化的地方反而要小心抽象过早。模板模式不是把代码从第一天就抽象得很完美而是在不断迭代中让骨架越来越清晰。真正的骨架来自你深刻理解了业务不变的部分而不是为了套设计模式硬生生切出来的方法。
我不是第一次在代码评审里看到这种场面五六个方法体几乎一模一样的 Service各自复制粘贴后小改两行然后整整齐齐地排在一个类里。改动一个公共逻辑要全局搜索替换漏改一处就线上报警。行为型设计模式里模板模式Template Method Pattern专门对付这类“流程固定、细节多变”的场景。它把算法的骨架定义在父类里把无法确定的具体步骤延迟到子类实现听着简单但用得好不好差别很大。这篇博文我会结合一次我参与过的支付渠道对接项目把模板模式的原理、结构、选型边界、坑点和框架里的实际应用串起来讲。不吹概念全部是可落地的思路和代码级细节。适合已经写过一段时间业务代码、想在抽象这条路上做出可靠设计的朋友也适合面试前把行为型模式彻底想明白的人。1. 模板模式的核心思想与适用场景1.1 一句话讲清楚模板模式模板模式的定义不复杂在一个方法里定义算法的骨架把某些步骤延迟到子类实现。父类负责控制流程、把握顺序、处理公共逻辑子类只负责填充自己特有的步骤。真实项目里最常见的非典型写法是“复制粘贴式扩展”。比如对接三家支付渠道每家都要求“验签 → 构造报文 → 发起请求 → 解析响应 → 落库”。第一版只对接一家时你很爽直接写一个 Service 全搞定。等第二家接入时你复制了整个方法改一改等第三家接入时你已经有三份几乎一样的代码。有问题时可能只有其中一家的验签方式不一样你却要维护三整套流程。模板模式解决的就是这个困境。它把“验签 → 构造报文 → 发起请求 → 解析响应 → 落库”这个流程骨架固定下来放在抽象父类里。每一家渠道只需要继承父类实现自己特有的那部分逻辑比如“验签算法”和“报文格式”。流程的稳定性与步骤的差异性被清晰地分开了。它最好用生活里的做法解释做饭馆里卖得最好的那道菜后厨会提前定好标准作业程序洗菜、切配、焯水、爆炒、装盘都有严格顺序。但不同客人可能要求少辣、免葱、多放蒜。后厨不会因为一个客人改口味就重写整个流程而是在标准流程允许的位置做局部调节。模板模式的父类就是这个标准作业程序子类就是针对不同口味的局部调节。1.2 它解决的核心痛点流程复用与扩展约束如果只说“复用”很多开发者会觉得继承本来就能复用。模板模式真正的价值其实有两个层次。第一层确实是消灭重复代码父类把公共算法收敛起来子类只写差异部分。但光这层还不够因为抽象方法也能做到。第二层更关键它通过流程顺序的控制强制所有子类遵循同一种执行顺序。比如所有支付渠道都必须先验签再请求这个顺序你写在父类的模板方法里子类想跳过都不可能。反向思考一下如果不用模板模式会怎样。接口加一个公共逻辑比如所有渠道请求前要打印完整的请求报文日志用抽象父类你只需要改一处不用模板模式你就要去每个渠道实现里手工补。漏掉一个渠道就是线上事故。模板模式让“流程不可破坏”成为可能这是它作为行为型模式区别于单纯继承复用的核心点。再补一个容易被忽略的好处模板模式天然适合团队协作。父类定好骨架和抽象步骤组长把接口定清楚组员每人认领一个子类去填实现。因为流程顺序已经锁定合并代码时几乎不会出现“有人把顺序改了导致结果不一致”的情况。并行开发的安全感这是我在实际项目管理中感受最直观的价值。1.3 什么场景该用它判断一个场景适不适合套模板模式我一般用三个问题自测这个业务是否存在一个固定的操作流程或算法步骤顺序不会随便变不同实现之间是否存在大量公共逻辑只有部分步骤差异化是否希望后续新增实现时强制遵循现有流程三个问题全是肯定回答那就大胆用。典型的例子包括多渠道支付对接、多类型文件导入解析、报表生成器、数据迁移管道、测试框架中的用例执行流程、游戏角色技能释放流程。尤其是“接入第三方系统”这类场景非常适合因为第三方系统各有各的签名算法、报文格式、重试策略但请求的整体节奏是一致的。反过来如果流程本身就不稳定今天三步明天五步每步子类的实现差异又非常大几乎没有什么公共逻辑那不要硬套模板模式。这种情况下模板父类除了一个空壳流程什么都给不了反而用策略模式更灵活。2. 模板模式的结构拆解与角色分工2.1 三个核心角色模板模式的结构里通常有三个角色每个都对应清晰的职责边界。第一个是抽象模板类AbstractClass。它定义了算法的骨架通常会包含三类成员。模板方法本身是 final 的它控制整个流程的顺序子类不能重写。抽象方法是被延迟到子类的步骤一般用 protected abstract 修饰。具体方法则是所有子类共享的公共逻辑写在父类里直接实现。第二个是具体实现类ConcreteClass。它继承抽象模板类实现那些抽象方法。每个具体类代表一种场景或一套参数下的完整流程但自己不控制流程顺序。还有一个容易被忽视的角色钩子方法Hook。钩子不是必须实现的抽象方法而是一个有默认实现的普通方法。子类可以通过重写钩子方法在流程的特定节点插入自己额外的逻辑或者改变流程中某一步是否执行。它本质上是框架留给扩展的“插槽”。三者的关系可以用一个比喻理解模板方法是舞台监督手里的流程单每一步都写得清清楚楚具体实现类是上台的演员只负责打磨自己的戏份钩子是观众互动环节不需要可以没有但演员想加戏就必须在这个环节上。2.2 模板方法、抽象方法、钩子方法的区别这个三兄弟的差别很多初学者容易糊涂。我整理一张表直接对比它们的本质。类型修饰符特征子类能否重写用途模板方法public final不能定义算法骨架控制流程顺序抽象方法protected abstract必须实现强制子类提供差异化步骤钩子方法protected非抽象带默认实现可选重写灵活的扩展点干预流程细节公共具体方法private 或 protected final可以调用不能重写封装公共算法步骤设计父类时这三类方法的取舍直接决定了骨架的刚性。模板方法必须 final这是纪律性的体现。如果把模板方法开放给子类重写抽象父类对流程的控制就形同虚设所有子类都能自己重新编排流程那模板模式等于没用了。这不是语法规定但类设计者应该在代码注释里明确这个纪律代码评审时也要重点盯这个。抽象方法的粒度也要控制好。太粗了子类实现里还会出现重复代码太细了子类会实现大量只差一行的抽象方法类变得臃肿。我见过一个不好的例子把“取数据库连接”和“设置查询参数”都拆成抽象方法结果每个子类里都要重复写连接参数这类逻辑放在父类公共方法里更合理。抽象方法要拆到“子类之间差异的真实边界”为止。钩子方法的设计更考验经验。一个常用的实践是给钩子方法提供“默认开”或“默认关”的合理默认值。比如默认开启日志记录子类不需要关心日志时什么都不用做默认不开启某种延展动作子类想加时重写钩子返回 true 就行。好的钩子默认值应该符合大部分子类的实际需求让它们尽量少写代码。2.3 好莱坞原则在模板模式中的体现模板模式背后是一个挺有名但常被忽略的原则叫“好莱坞原则”Dont call us, well call you别给我们打电话我们会打给你。映射到代码里就是子类不在自己的方法里主动调用父类的流程而是父类的模板方法在合适的时机主动调用子类实现的方法。这个反向控制结构对理解模板模式来说非常关键。很多人第一次写模板模式时不适应觉得子类明明是独立的类怎么反而被父类牵着走。其实这正是框架思维的开端。你写一个子类实现抽象方法并不会立刻被调用而是当外部代码调用父类的模板方法时模板方法内部会按顺序反过来调用你这个子类的实现。这也解释了模板模式为什么是“反向控制”的雏形。后来的 IoC 容器、Spring 的回调机制都有类似的影子。你可以说模板模式是很多开发者接触到的第一个容器思想的代码级呈现。2.4 在 GUI 框架中的应用如果要找模板模式最直觉的例子图形界面框架里的绘制流程是最好的。一个窗口控件从创建到显示中间经历的步骤几乎是固定的创建对象、设置布局、绘制背景、绘制子元素、绘制前景、处理事件循环。任何自定义控件都不需要重写整个绘制流程只需要实现一个 onPaint() 方法。框架在合适的时机回调它在它前后自动完成背景清理和画布准备。这和一个成熟的游戏渲染循环也很贴近。游戏引擎把“每帧更新”的骨架定义好了开发者只需要把“更新自己角色的具体逻辑”填进指定的 update() 方法。对开发者来说你不用关心引擎内部怎么计算帧间隔、处理垂直同步这些都在父类里去做了。这种使用体验就是模板模式去皮之后最朴实的形态。3. 实战案例支付渠道通用对接框架3.1 业务背景与父类骨架定义讲理论有点干我来还原一次我参与过的支付对接项目。当时需要同时接入微信支付、支付宝、银联云闪付三个渠道每个渠道都有各自的验签规则、报文结构、请求方式、回调验签逻辑。按传统复制粘贴的做法每家写一套完整流程出问题后定位成本极高。我们决定用模板模式做一个通用对接层让所有渠道都走同一条流程管线。抽象父类叫 AbstractPayChannel里面定义了一个 final 的 pay() 方法作为模板方法流程固定为参数校验 → 构建渠道专属请求参数 → 加签 → 发起 HTTP 请求 → 解析响应 → 验签 → 落库更新。代码如下public abstract class AbstractPayChannel { // 模板方法定义整个支付流程骨架子类不可重写 public final PayResult pay(PayRequest request) { // 1. 公共参数校验 validate(request); // 2. 构建渠道专属参数子类实现 MapString, String params buildChannelParams(request); // 3. 加签子类实现 String sign sign(params, request.getSecretKey()); params.put(sign, sign); // 4. 发起请求公共方法走统一 HTTP 客户端 String response doPost(request.getGatewayUrl(), params); // 5. 解析渠道响应子类实现 PayResponse payResponse parseResponse(response); // 6. 验签子类实现 boolean verify verifySign(payResponse, request.getSecretKey()); if (!verify) { throw new PayException(渠道响应验签失败); } // 7. 落库更新公共逻辑 updateOrderStatus(payResponse); // 8. 钩子允许子类做额外的后置处理 afterPay(payResponse); return buildResult(payResponse); } // 公共方法统一参数校验 private void validate(PayRequest request) { if (request.getAmount() null || request.getAmount() 0) { throw new PayException(金额非法); } if (StringUtils.isBlank(request.getOutTradeNo())) { throw new PayException(商户订单号不能为空); } } // 公共方法统一发起 HTTP 请求 private String doPost(String url, MapString, String params) { // 使用统一的 HTTP 客户端带上公共超时配置 return HttpUtil.post(url, params); } // 公共方法统一更新订单状态 private void updateOrderStatus(PayResponse response) { // do something } // 公共方法统一构建返回结果 private PayResult buildResult(PayResponse response) { return PayResult.success(response.getChannelOrderId(), response.getPayStatus()); } // 抽象方法子类必须实现渠道专属逻辑 protected abstract MapString, String buildChannelParams(PayRequest request); protected abstract String sign(MapString, String params, String secretKey); protected abstract PayResponse parseResponse(String response); protected abstract boolean verifySign(PayResponse response, String secretKey); // 钩子方法默认空实现子类按需重写 protected void afterPay(PayResponse response) { // 默认什么都不做 } }3.2 抽象方法与公共方法的边界划分写这个父类时最费心思的不是流程本身而是每步到底该做成抽象方法、公共方法还是钩子。我当时的划分逻辑很简单凡是所有渠道行为一致的步骤全部做成 private 的公共方法比如参数校验、HTTP 请求、落库更新。凡是每个渠道差异明显的步骤做成 protected abstract比如参数构建、加签、解析响应、验签。凡是“大部分渠道不需要但不排除个别渠道需要”的步骤做成钩子比如支付成功后的短信通知或其他定制后置动作。其中最需要解释的是为什么验签是抽象方法而不是公共方法。因为三个渠道的验签算法各不相同微信用 HMAC-SHA256支付宝用 RSA2银联有自己的证书验签流程。用同一个函数签名去抽象它们其实已经是一种妥协但对于上层流程而言它只需要知道“这一步做了验签”就足够了。而我特意没有把“加签”和“验签”合并成一个抽象方法是因为它们的输入输出差异太大。加签处理的是请求参数验签处理的是响应数据分开更清晰。3.3 具体渠道子类的实现方式有了父类之后接入一个新渠道就变成一件很机械的事。以微信支付为例子类长这样public class WechatPayChannel extends AbstractPayChannel { Override protected MapString, String buildChannelParams(PayRequest request) { MapString, String params new HashMap(); params.put(appid, request.getAppId()); params.put(mch_id, request.getMchId()); params.put(out_trade_no, request.getOutTradeNo()); params.put(total_fee, String.valueOf(request.getAmount().multiply(100).intValue())); params.put(body, request.getSubject()); return params; } Override protected String sign(MapString, String params, String secretKey) { String content buildSignContent(params); return HmacSha256Util.digest(content, secretKey); } Override protected PayResponse parseResponse(String response) { // 解析微信支付的 XML 响应 return WechatResponseParser.parse(response); } Override protected boolean verifySign(PayResponse response, String secretKey) { // 微信支付回调时的验签逻辑 return WechatSignVerifier.verify(response.getRawData(), response.getSign(), secretKey); } }接入支付宝就再写一个 AlipayPayChannel接入银联就写一个 UnionPayChannel。每个子类只关注“自己渠道的差异逻辑”流程怎么走、什么时候校验、什么时候落库全都交给父类。当时我们这个框架上线后后期新增一个渠道的工时从原来的两天压缩到半天左右主要时间都花在阅读对方渠道的文档上代码量反而很少。3.4 钩子方法的两个实际用法钩子方法在支付项目里最常用的就是 afterPay()。普通渠道支付成功后的后置动作都是相同的所以父类里的默认实现是空方法什么都不做。但有一个渠道比较特殊用户在支付成功后需要跳转一个合作方的落地页于是我们在这个渠道的子类里重写了 afterPay()额外拼接落地页参数并做了跳转。这个逻辑不影响主流程又不愿意污染公共模板用钩子干干净净地插进去。另一个钩子用法是控制流程分支。比如我们定义一个 protected boolean needRetry() 钩子默认返回 false。某个渠道的网络稳定性比较差就在子类里重写返回 true。然后在父类的模板方法里把发起请求那一步包裹进一个重试循环int maxRetryTimes needRetry() ? 3 : 1; for (int i 0; i maxRetryTimes; i) { try { response doPost(request.getGatewayUrl(), params); break; } catch (RemoteTimeoutException e) { if (i maxRetryTimes - 1) { throw e; } } }这个设计让“是否重试”从固定流程里解耦出来变成了子类可选决策整体代码整洁度提升不少。我个人在使用钩子时有一条原则钩子数量不要超过两三个越多会越难读懂父类到底在做什么。钩子的命名也要体现“可选性”最好用 canXxx、needXxx、afterXxx、beforeXxx 这种词让人一眼就知道这是可选的扩展点。4. 模板模式与策略模式的边界与选型4.1 一个经典误区模板模式和策略模式不是一回事我在面试候选人和做代码评审时发现很多人分不清模板模式和策略模式。其实两者解决的问题有重叠但思路完全不同。策略模式重点是“算法整体可替换”它把一整个算法封装成独立对象通过组合的方式让运行时机动态选择。模板模式重点是“算法骨架固定局部步骤可变”它用继承的方式在编译期固定流程。举个具体例子。策略模式里一个优惠计价器有满减、折扣、会员价三种算法你可以运行时自由切换算法之间彼此完全独立没有公共流程。模板模式里支付渠道三家的流程大体一致只是细节不同骨架不可变。如果用策略模式做支付渠道等于把整个支付流程塞进三个策略类里公共逻辑还是得抽出来但抽出来之后策略类之间没有任何结构化约束很容易出现实现差异。选型时我常用一个判断标准如果差异点是整个算法层面的替换本质上是“换一种做法”用策略模式更合适如果差异点是某个固定流程中的若干步骤本质上是“同一个流程的不同细节”用模板模式更合适。混淆这两者代码写出来你会发现要么抽象封装太松散要么继承层级太僵硬。4.2 组合与继承的取舍模板模式建立在继承之上这让它在某些场景下显得不够灵活。Java 是单继承一个子类只能继承一个抽象父类如果一个类既要做支付渠道又要做对账流程模板模式就无能为力。这时可以用策略模式加组合把两个能力委托给两个不同的组件对象。但组合不是银弹。当流程结构非常稳定且公共逻辑较多时继承带来的代码复用和结构约束反而比组合更直观。我现在写代码时不会刻意回避继承关键是判断继承的层级是否会失控。模板模式的继承层级严格控制在两层到三层是最舒服的超过三层每次改父类逻辑的影响面就会变得难以预测。在实际项目中我偶尔也会把模板模式和策略模式结合使用。抽象模板类里某个步骤的实现可以通过策略接口来委派这样既保留流程骨架的稳定性又让局部的算法可动态切换。比如支付渠道的验签算法可以在子类里注入一个验签策略对象而不是直接硬编码到子类里。这个组合玩法比较高阶但确实能解决很多复杂场景。4.3 一个决策表模板模式还是策略模式如果看完上面的分析还是拿不准可以对照这张决策表。判断维度选用模板模式选用策略模式核心诉求固定流程、复用公共代码、强制顺序灵活替换整套算法流程稳定性流程基本不变流程本身可能变公共代码量公共逻辑多差异点少公共逻辑少差异点大绑定方式继承编译期绑定组合运行期绑定扩展方式新增子类实现抽象方法新增策略类动态注入适用例子支付渠道、报表生成、数据导入优惠计价、压缩算法、路由策略真实开发中很多系统两种模式会同时出现。模板模式管流程骨架策略模式管某个步骤的算法选择。你不需要把它们对立起来理解各自的侧重点组合使用才能写出好维护的架构。5. 使用模板模式最容易踩的几个坑5.1 子类重写模板方法这是模板模式最致命的反模式也是我见过最多的错误。有人觉得模板方法加个 final 太死板或者他根本没意识到模板方法不能重写直接在子类里 override 了整个模板方法然后把自己的一套流程写进去。这样父类对流程的控制完全失效公共逻辑也不再被强制复用等于模板模式名存实亡。我在代码规范里明确要求模板方法必须声明为 final并且通过静态检查工具扫描是否存在对模板方法的重写。如果子类确实需要完全不一样的流程说明这个子类根本不适合用模板模式应该把它拆出去用别的方式实现而不是在模板模式体系里开一个破坏规则的口子。5.2 钩子方法过多导致阅读困难钩子是模板模式的润滑剂但用多了会变成下水道。网上很多人推崇钩子甚至是父类里堆了五六个钩子方法子类每个都重写一遍最后父类的模板方法里插满了 if 判断。这种情况下阅读者想搞懂整个流程时必须逐个子类去对照钩子的返回值思维负担非常大。我的建议是钩子数量控制在两个以内。超过两个就要反思是不是公共流程切分有问题。钩子应该承担真正的“分支决策”或“后置扩展”不应该承担“补丁式”的临时逻辑。有一次我把一个钩子用作临时数据修正后来数据修正逻辑不断膨胀钩子方法里塞了几十行代码后来重构时把它移到了公共方法里父类结构一下子清爽了很多。5.3 继承层级过深模板模式天然鼓励继承但很多人写着写着就把层级叠得很深。抽象父类 → 中间抽象类 → 再抽象一层 → 具体实现。每多一层理解和调试的复杂度就翻一倍。现实中三层继承已经接近维护上限四层以上基本就是可读性灾难。出现多层继承往往意味着抽象粒度没把握好。比如最开始父类是 AbstractPayChannel后来发现微信和支付宝都有“扫码支付”和“H5 支付”于是又抽出一层 AbstractWechatMultiModeChannel。如果再往后发现小程序支付和公众号支付还有差异再抽一层。等层级到了一定数量任何一层的小改动都要仔细分析影响到了多少子类。我的经验是如果发现层级超过三层优先考虑用一个组合或者策略来替代中间抽象层。把变化的维度拆到组件里而不是无限地用继承细分。继承应该表达“这个子类是一种父类”而不是表达“这个子类拥有某个特性”。5.4 单元测试容易忽略模板父类逻辑很多开发者为每个具体子类写单元测试却漏掉了抽象父类里的公共流程。从覆盖率来说这算个盲区。模板方法的流程一旦出错所有子类都会受影响但如果你只在子类里测试父类流程的问题会被隐藏成子类问题排查起来绕圈子。比较好的测试策略是先写一个假的子类只实现最小的抽象方法专门用来测父类的模板方法流程。验证流程顺序是否按预期执行、异常路径是否正确处理、钩子方法是否能影响流程分支。然后再针对真实业务子类测试差异逻辑。这样既保住了骨架的正确性又保住了差异实现的正确性。5.5 注意抽象方法调用的时机父类的构造函数里如果调用了抽象方法这是一个隐蔽的坑。Java 在初始化子类时会先调用父类构造器而父类构造器里调用抽象方法时子类还没完全初始化此时子类字段可能为 null很可能抛出空指针。我一个朋友遇到过这个经典问题抽象父类构造时调用了一个抽象方法 initChannel()子类 override 后在 initChannel() 里读取了自己的 apiKey 字段结果 apiKey 还没赋值直接空指针。解决方案很简单不要在构造器里调用抽象方法把初始化逻辑推后到模板方法的第一步或者用钩子方法加一个 default 实现。我自己后来写模板模式时初始化逻辑一律放到模板方法流程里不在构造函数里做任何动态行为。6. 主流框架中的模板模式应用6.1 Spring 里的模板类Spring 的 JdbcTemplate 就是模板模式的典型应用。它把“获取连接、创建 Statement、执行 SQL、遍历结果集、处理异常、关闭资源”这些步骤封装成模板开发者只需要实现回调方法里的“如何解析每行数据”。你写查询不需要关心资源释放但你必须实现 RowMapper 接口告诉框架一行数据映射成什么对象。Spring 的 RestTemplate 也体现了类似思想。它把 HTTP 请求的完整流程模板化无论 GET、POST、PUT底层的连接管理、超时设置、错误处理统一固化开发者只需要提供 URL、请求体、响应类型就能完成调用。6.2 JDK 里的模板模式JDK 的 AbstractList 是另一个教科书级的例子。它把 list 的大部分操作基于 get() 和 size() 两个抽象方法实现。你继承 AbstractList 只需要实现 get(int) 和 size()就自动拥有了迭代、查找、子列表等一整套功能。这就是模板模式在基础设施层的威力。InputStream 也类似。read() 抽象方法定义了单字节读取而 read(byte[], int, int) 是建立在它之上的模板方法。子类只需要实现单字节读取就能获得整个批量读取和流操作能力。6.3 中间件与框架的扩展点设计很多中间件设计也是模板模式思路。比如 Tomcat 处理请求的管道定义了一整套过滤链流程开发者在配置里插入过滤器框架在固定的节点调用它们。再比如很多批处理框架把“读取 → 处理 → 写入”定义成固定管线开发者只需要实现 Reader、Processor、Writer 三个步骤。这类框架使用体验的核心就是模板模式的思想。理解了模板模式再看框架你能明显感受到框架设计者在“控制流程”和“开放扩展”之间的良苦用心。骨架是你改不动的纪律扩展点是你可以自由创作的空间。7. 动手优化从一个坏味道到模板模式7.1 识别代码里的模板模式需求识别需要重构为模板模式的代码最直观的信号是看是否存在大量的方法级复制粘贴。比如三个类里各有一个 export() 方法方法体几乎一样只是中间某个转换函数不同。那 export() 就是潜在的模板方法那个转换函数就是潜在的抽象方法。我分享一个三分钟定位法。挑出一个典型实现把它的方法步骤编号写出来。然后拿另一个实现对照看哪些步骤的代码完全一样哪些步骤有差异。公共部分越多越值得模板化差异部分越集中抽象方法的边界越清晰。7.2 重构步骤详解假设原来有三个独立的导出器CsvExporter、ExcelExporter、PdfExporter每个里面都有完整流程。重构时可以这样操作。第一步新建抽象父类 AbstractExporter把公共流程的骨架代码复制进去写成 final 的模板方法。第二步把流程中有差异的步骤提取成抽象方法签名尽量抽象能覆盖三家差异的最小集合。第三步让三个导出器继承 AbstractExporter删除它们各自的重复流程代码只保留差异实现。第四步跑一遍原有测试集对比导出结果是否一致。重构期间最容易出的问题是抽象方法签名定得太具体。比如 Excel 导出需要设置列宽参数CSV 不需要如果抽象方法 signature 里有 columnWidth 参数CSV 实现就很尴尬。这时可以把列宽设置变成另一个钩子而不是硬塞进公共签名里。这个设计取舍很考验经验我的建议是抽象方法以业务意图为单位而不是以参数差异为单位。7.3 重构后的收益量化重构到底值不值可以用几个数字来评估。复制粘贴版本里一个公共流程修改要改动三个文件重构后只需要改父类一个文件原来新增一种导出格式需要几乎重写整个流程重构后只需要实现几个抽象方法公共逻辑的覆盖率从三份实现分别测试变成一个父类测试加三个差异测试测试成本显著下降。这类量化数据在向团队或上级汇报重构收益时非常有用也能让你判断重构的投入产出比。8. 模板模式的扩展玩法与个人经验8.1 用模板模式做统一校验编排除了典型的外接渠道场景模板模式还可以做业务校验编排。比如一个下单接口固定流程是参数校验、库存校验、价格校验、风控校验、落单。每一步校验器各不相同但编排结构固定。抽象父类定义验证流程子类实现不同的校验细节公共结果统一收集。这种玩法的好处是校验逻辑可以轻松扩展到新业务线。新业务线只需要新增一个子类配置到流程里即可不需要改动原有编排。实际项目中我把一套下单流程的校验从 if-else 改造成模板模式后新增校验规则的效率提升非常明显。8.2 模板模式与函数式接口的对比在 Java 8 之后函数式接口和 Lambda 提供了一种比继承更轻量的做法。比如 JdbcTemplate 的 execute 方法你可以传一个 PreparedStatementCallback 的 Lambda相当于一步到位地代替了定义一个匿名子类。那模板模式是不是过时了我的看法是模板模式作为设计思想永远不过时只是实现载体可以更现代。当一个流程需要被多个类复用并且有较多公共状态时继承式模板模式还是最自然的选择。但如果你只需要复用一段简单的流程并且差异点就一两个方法直接用函数式接口配 Lambda 会清爽很多。技术选型千万不要有偶像包袱设计模式不是信仰是为了让代码更好维护。8.3 钩子与模板方法的一个进阶组合一个进阶做法是模板方法配合持有状态的对象。比如模板父类维护一个结果收集器模板方法分步执行时每一步把结果暂存进去钩子方法可以在最终阶段读取这些状态做后处理。这本质上把流程中产生的过程数据传递给扩展点能力比传统钩子强不少。我做过一个数据同步管道不同数据源同步流程固定为“抽取 → 清洗 → 转换 → 加载”但由于每个环节都可能产生中间产物钩子方法需要读取前面的产物。那时我就在父类里引入一个 PipelineContext每个步骤都往里面写钩子只接收 context。这样钩子可以访问的上下文足够丰富又不用为了传参给抽象方法加一堆无关参数。8.4 模板模式的未来视角设计模式是经验的结晶模板模式这几年在框架设计里的形态已经悄然进化。比如 Java 的 HttpClient 提供了 send 和 sendAsync 两个固定模板方法开发者只需要提供 BodyPublisher 和 BodyHandler。这里模板方法不再依赖继承而是通过函数式参数完成流程控制。核心思想没有变变的只是载体。我认为理解设计模式最正确的姿势是先搞懂经典形态知道它解决什么本质问题然后看框架里怎么演化最后在自己的代码里能识别问题、选对形态。模板模式从继承到函数式本质依然是把不变的流程与变化的步骤分离。这个分离的思想放之四海而皆准。9. 面试中模板模式的高频追问模板模式在面试中出现的频率不算低但十个人里有八个都只讲“抽象类里定义骨架子类实现差异”这句话。面试官继续追问就答不上来了。这里梳理几个高频追问和参考思路。第一个高频问题模板方法的 final 关键字是必须的吗回答思路是必须写它是控制流程不被破坏的基本前提。然后补一句即使语言允许开放也应该通过命名规范约定为不可重写。这就能体现你的经验。第二个高频问题模板模式和策略模式有什么区别回答思路是先说清楚各自结构上的不同继承与组合、编译期绑定与运行期绑定。然后举一个业务场景同时解释两种方案分别怎么设计最后说明什么场景选谁。能结合代码经验讲基本上就是加分项。第三个高频问题为什么模板模式能体现好莱坞原则回答思路是解释子类不主动调用父类而是由父类模板方法在合适的时机回调子类实现。同时分享一下你在看 Spring 源码时对“框架反向控制”的体会。如果你能讲清楚这个面试官通常不会再追问了。第四个高频问题模板模式里钩子的意义是什么回答思路是钩子提供可选的扩展点让子类能在不影响流程结构的前提下干预流程细节。你还可以顺势提一下构建 PipelineContext 的进阶玩法展示你踩过坑后的深度理解。10. 常见问题速查表我把这些年实际项目中遇到的模板模式问题整理成一个速查表有类似症状可以直接对照。现象可能原因解决办法子类重写了模板方法父类模板方法未加 final立即加上 final 并代码评审排除模板父类改动导致多个子类异常公共逻辑封装不够充分或层级过深提炼公共方法控制继承层级子类新增后总有逻辑遗漏遗漏了某个抽象方法或钩子把关键步骤声明为 abstract钩子选好默认值父类构造函数空指针构造器里调用了抽象方法初始化逻辑延迟到模板方法第一步钩子方法里塞了太多逻辑钩子被当成了补丁入口收敛钩子数量把通用逻辑提到公共方法子类实现里还有重复代码抽象方法粒度太粗继续下钻差异点重新划分抽象边界新增一种实现很困难抽象方法签名设计不合理以业务意图为单位设计抽象签名用钩子承载附加参数流程顺序被破坏某子类直接 override 了模板方法模板方法 final配套 lint 规则检测这张表我建议你收藏在团队代码评审时直接拿出来当检查清单用比临时讲道理好使。最后再分享一个自己在建模时常用的提炼思路。我会先写出一个最简单的流程实现把它在纸上画成若干步骤。然后拿第二个场景来实现看两个流程的差异点到底落在哪几步。差异点越稳定的地方越适合抽象成方法差异点越容易变化的地方反而要小心抽象过早。模板模式不是把代码从第一天就抽象得很完美而是在不断迭代中让骨架越来越清晰。真正的骨架来自你深刻理解了业务不变的部分而不是为了套设计模式硬生生切出来的方法。
