模板方法模式实战：用流程骨架与钩子机制化解重复代码

这期聊模板方法模式。说实话，这是我在实际项目里被“重复代码”逼到墙角之后，用得最顺手的一个模式。很多人学设计模式容易把它和策略模式搞混，觉得都是“把一个流程拆开让子类去实现”，真到写代码的时候又不知道骨架该搭在哪、钩子该留几个。这期就借着“流程骨架与钩子实现”这个主题，把模板方法模式从头到尾捋一遍，从原理到实战到坑点，争取看完你就能直接在自己的项目里用上。

1. 为什么需要模板方法模式：一个流程复用的真实痛点

1.1 从一条“改不完的代码”吐槽说起

先讲一个我印象特别深的场景。早几年我在一家做电商系统的公司，当时要对接好几家物流商的电子面单接口。每一家的文档都不一样，但整个业务流程高度相似：先校验订单参数，然后生成请求报文，再做签名加密，接着调用对方接口，最后解析回执更新订单状态。看上去是个很标准的流程，对吧？

结果我当时写代码的时候是怎么干的？按物流商分了三个类，每个类里把完整流程从头写一遍。刚好那段时间顺丰那边改了一次签名算法，我当时心里还想“还好只改顺丰一个类”。可等我打开代码才发现，签名逻辑在三四个类里各有一份，光全局搜索就搜出来五处。那一刻我才真正意识到一个事：重复的流程代码，必然带来连锁修改的灾难。

类似的场景其实到处都是。订单状态流转、数据导入导出、报表生成、审批流程……只要业务上有“同构不同细节”的处理链路，如果每个实现类都各自复制一遍流程，初期看着代码挺多，热热闹闹的，等后期需求一变更，那酸爽谁改谁知道。

1.2 复制粘贴式的流程实现到底错在哪

很多人觉得，流程类似就复制粘贴呗，改的时候全改一遍不就行了。这话放在只有两处重复的时候勉强成立，但一旦重复点超过三个，问题就非常明显了：

• 漏改风险很高。 全局搜索出来的五处签名代码，只要漏掉一处，线上就是事故。
• 新接入成本高。 下个月要接中通，你得完全照着现有代码再“抄”一遍，抄的过程中还要自行判断哪些逻辑是“这家特有的”、哪些是“所有渠道都要有的”，试错成本非常大。
• 代码结构模糊。 每个类里都是几十行相似代码，真正的差异逻辑被淹没在重复里，后来接手的人根本分不清主次。

1.3 模板方法模式的核心思路：把流程固化，把细节下放

模板方法模式给出的解法其实就是一句话：把流程骨架放进父类，把可变细节留给子类。

父类里定义一个不可被重写的“模板方法”，它负责把整个流程按固定顺序串联起来；而那些会变化的步骤，比如参数校验、签名生成、报文解析，则声明成抽象方法或钩子方法，交给具体子类去实现。流程的“骨架”是固定的，非子类所能撼动；流程的“血肉”是灵活的，由子类各自填充。

这就好比一家连锁奶茶店的出杯流程：接单、加茶底、加小料、封口、贴标签、叫号，这套“骨架”每家门店都一样，但加什么茶底、加什么小料，就由每家门店按顾客需求自己决定。骨架要是谁都能改，那这家店的品控也就崩了。

2. 模板方法模式的结构拆解：骨架、步骤与钩子

2.1 四个关键角色一次性说清

要把模板方法模式讲透，得先认识这几个角色。它们的分工非常清楚：

抽象模板类（AbstractClass）

这是整个模式的核心。它定义了一个模板方法（Template Method），通常是 final 修饰的，里面按照业务顺序调用了若干步骤方法。这个类里还包括一个或多个抽象方法、具体方法和钩子方法。

模板方法（Template Method）

定义算法骨架的方法，规定了各个步骤的执行顺序。一般用 final 锁死，防止子类覆盖后打乱流程。比如我前面说的支付流程，就把“校验→签名→请求→解析→落库→通知”这个顺序锁死在父类里，子类不能重排。

抽象方法（Abstract Method）

必须由子类实现的步骤。比如不同支付渠道的签名算法差异很大，那 sign() 就必须是抽象方法，让微信和支付宝各自实现。

具体方法（Concrete Method）

父类已经实现了的、通用性极强的步骤。比如“记录日志”“保存流水”，所有渠道都一样，子类直接用就行，不需要重写。

钩子方法（Hook Method）

这是模板方法模式里最容易被忽略但又非常好用的设计。钩子方法在父类里有一个默认实现（可以是空方法，也可以返回一个默认布尔值），子类选择性地去覆盖它，从而影响模板方法中某个步骤是否执行、或者在某些地方插入额外的逻辑。注意和抽象方法的区别：抽象方法是“强制实现”的，钩子方法是“可选覆盖”的。

2.2 用一个生活化示例理解流程骨架

拿最经典的“泡茶和泡咖啡”例子来说。

泡茶和泡咖啡的共同流程是：烧水、冲泡、倒进杯子、加调料。但细节不一样：茶是放茶叶，咖啡是放咖啡粉；茶的调料是柠檬，咖啡的调料是糖和牛奶。

用模板方法模式来写就是：

java复制public abstract class CaffeineBeverage {

    // 模板方法：流程骨架，用 final 锁死
    public final void prepareRecipe() {
        boilWater();        // 具体方法：烧水，所有饮料都一样
        brew();             // 抽象方法：冲泡，由子类决定
        pourInCup();        // 具体方法：倒杯，一样
        if (customerWantsCondiments()) {  // 钩子方法：决定是否加调料
            addCondiments();  // 抽象方法：加调料，由子类决定
        }
    }

    private void boilWater() {
        System.out.println("烧水");
    }

    private void pourInCup() {
        System.out.println("倒进杯子");
    }

    protected abstract void brew();
    protected abstract void addCondiments();

    // 钩子方法：默认加调料，子类可以覆盖
    protected boolean customerWantsCondiments() {
        return true;
    }
}

这个例子里最值得玩味的就是 customerWantsCondiments()。当实现“纯茶”这种不需要加调料的子类时，只要覆写这个钩子返回 false，泡茶流程里的“加柠檬”步骤就会自动跳过。父类流程骨架不用改，步骤能不能被跳过，完全由子类通过钩子控制，这就是把“固定”和“变化”之间那层弹性给做出来了。

2.3 模板方法与普通继承的区别

可能有人会问：这不就是普通继承嘛，父类写几个方法，子类继承再重写，有什么稀奇？

区别在于控制权的归属。普通继承里，子类可以随意重写父类的任何方法，也可以自己定义一个 doSomething() 然后在自己的业务方法里调用，流程顺序完全由子类自己说了算。而模板方法模式把“流程控制权”上收到了父类的模板方法里，子类只能填充具体步骤，不能改变步骤的调用顺序。

这种“控制反转”是模板方法模式最核心的特征。用行业里的黑话讲，它体现了好莱坞原则：Don't call us, we'll call you。父类在流程里主动调用子类的方法，子类永远不要去反向控制流程。

3. 场景化实战：用模板方法模式重构一套多支付渠道接入代码

3.1 业务背景与朴素实现的问题

前面讲了原理，现在上点硬菜。假设我们系统需要接入微信支付、支付宝、银行卡支付三条渠道，每条渠道的支付流程都有这么几个环节：参数校验、生成签名、发起支付请求、解析响应、保存流水、通知前端。

大多数新手的第一版代码是这样的：建三个 Service，每个 Service 里把一个完整的支付方法从头写到尾。代码结构大体如下：

java复制public class WechatPayService {

    public PayResult pay(PayRequest request) {
        // 1. 参数校验（微信特有的校验逻辑）
        validate(request);
        // 2. 生成微信签名
        String sign = buildWechatSign(request);
        // 3. 调用微信接口
        String response = httpPost("https://api.weixin.qq.com/pay", request, sign);
        // 4. 解析微信响应
        PayResult result = parseWechatResponse(response);
        // 5. 保存流水
        saveRecord(request, result);
        // 6. 通知前端
        notifyFront(request, result);
        return result;
    }
}

AlipayPayService 和 BankCardPayService 里的代码结构几乎一致，只有 validate、buildSign、httpPost 的目标地址、parseResponse 的具体实现不一样。你复制三遍试试？后面一旦要加“幂等校验”或者“风控检查”这种公共环节，你就得三个类挨个加一遍，中间漏一个就是线上事故。

3.2 第1版：方法抽离与骨架搭建

模板方法模式的切入点就是在这些“结构一致、细节不同”的流程里。我先定义一个抽象父类，把流程骨架锁死：

java复制public abstract class AbstractPayService {

    // 模板方法：支付流程骨架，不允许子类修改顺序和整体流程
    public final PayResult pay(PayRequest request) {
        // 1. 参数校验（子类实现各自逻辑）
        validate(request);
        // 2. 幂等校验（新增公共逻辑，只写一遍）
        checkIdempotent(request);
        // 3. 渠道签名（子类实现）
        String signature = buildSignature(request);
        // 4. 发起支付请求（子类实现）
        String response = callPayApi(request, signature);
        // 5. 解析响应（子类实现）
        PayResult result = parseResponse(response);
        // 6. 保存流水（父类实现，公共逻辑）
        saveRecord(request, result);
        // 7. 钩子：是否发送通知
        if (needNotify()) {
            notifyFront(request, result);
        }
        return result;
    }

    protected abstract void validate(PayRequest request);

    protected abstract String buildSignature(PayRequest request);

    protected abstract String callPayApi(PayRequest request, String signature);

    protected abstract PayResult parseResponse(String response);

    private void checkIdempotent(PayRequest request) {
        // 公共幂等校验逻辑，三个渠道共用
    }

    private void saveRecord(PayRequest request, PayResult result) {
        // 公共流水保存逻辑
    }

    private void notifyFront(PayRequest request, PayResult result) {
        // 公共通知逻辑
    }

    // 钩子方法：默认需要通知，子类按需覆盖
    protected boolean needNotify() {
        return true;
    }
}

这个骨架搭建起来之后，微信支付实现类就变得非常干净：

java复制public class WechatPayService extends AbstractPayService {

    @Override
    protected void validate(PayRequest request) {
        // 微信渠道特有的校验逻辑
    }

    @Override
    protected String buildSignature(PayRequest request) {
        // 微信签名算法（MD5 + 商户Key）
        return null;
    }

    @Override
    protected String callPayApi(PayRequest request, String signature) {
        // 调用微信支付API
        return null;
    }

    @Override
    protected PayResult parseResponse(String response) {
        // 解析微信支付响应
        return null;
    }
}

小明再看到这个类，能在五秒钟内看懂整个渠道的定制点在哪。所有公共逻辑都收敛在父类里，子类只写自己真正不一样的东西。这就是模板方法模式在“可读性”和“可维护性”上最直接的收益。

3.3 第2版：引入钩子支持渠道差异化

需求继续演进。银行卡支付渠道因为银行风控要求严格，支付回调后必须额外做一次对账确认；而且银行卡渠道的回调通知不能走前端轮询，得走服务端主动推送。要是没有钩子，这种“渠道特有”的需求还是会把子类代码变得臃肿。

这时候钩子就派上用场了。我在骨架里增加两个钩子方法，一个控制“是否需要做对账”，一个控制“通知方式”：

java复制public abstract class AbstractPayService {

    public final PayResult pay(PayRequest request) {
        validate(request);
        checkIdempotent(request);
        String signature = buildSignature(request);
        String response = callPayApi(request, signature);
        PayResult result = parseResponse(response);
        saveRecord(request, result);
        if (needReconciliation()) {
            doReconciliation(request, result);      // 需要渠道级对账
        }
        if (needNotify()) {
            notifyFront(request, result);           // 按渠道定制通知方式
        }
        return result;
    }

    // 钩子1：是否需要对账
    protected boolean needReconciliation() {
        return false;
    }

    protected void doReconciliation(PayRequest request, PayResult result) {
        // 默认空实现，子类按需覆盖
    }

    // 钩子2：是否需要通知，默认 true
    protected boolean needNotify() {
        return true;
    }

    protected void notifyFront(PayRequest request, PayResult result) {
        // 默认走前端轮询
    }
}

银行卡渠道接入的时候是这样的：

java复制public class BankCardPayService extends AbstractPayService {

    @Override
    protected void validate(PayRequest request) {
        // 银行渠道特有校验
    }

    @Override
    protected String buildSignature(PayRequest request) {
        // RSA签名
        return null;
    }

    @Override
    protected String callPayApi(PayRequest request, String signature) {
        // 调用银行接口
        return null;
    }

    @Override
    protected PayResult parseResponse(String response) {
        // 解析银行响应
        return null;
    }

    // 覆盖钩子：银行渠道必须对账
    @Override
    protected boolean needReconciliation() {
        return true;
    }

    @Override
    protected void doReconciliation(PayRequest request, PayResult result) {
        // 银行对账逻辑
    }

    // 覆盖钩子：银行渠道走服务端推送
    @Override
    protected void notifyFront(PayRequest request, PayResult result) {
        // 服务端主动推送逻辑
    }
}

这个版本里，骨架流程已经能做到“按渠道自动裁剪”。微信、支付宝不覆盖钩子，就自动跳过对账流程；银行渠道覆盖两个钩子，就自动加入对账、改用服务端推送。新增渠道的时候，开发者只需要关注四个抽象方法加两个钩子方法，“哪些必须实现、哪些可选覆盖”一目了然。

3.4 重构之后客户端视角的变化

从调用方的视角看，重构前后也有明显区别。之前调用方要根据渠道类型走不同的类，到处都是 if-else：

java复制PayResult result = null;
if ("wechat".equals(channel)) {
    result = wechatPayService.pay(request);
} else if ("alipay".equals(channel)) {
    result = alipayPayService.pay(request);
} else if ("bankcard".equals(channel)) {
    result = bankCardPayService.pay(request);
}

配合简单工厂把渠道类型映射到对应 Service 之后，调用方收拢成一行：

java复制PayResult result = payServiceFactory.get(channel).pay(request);

以后新增渠道，调用方代码都不用改。工厂类稍作调整，把新渠道的 Service 注册进去即可。这就是模板方法模式配合 简单工厂 的组合拳，用最少量的代码改动应对系统未来的业务扩展。

4. 钩子机制才是模板方法的灵魂：从强约束走向灵活扩展

4.1 钩子方法与抽象方法的分工边界

很多初学者写完模板方法类，把所有的步骤全声明成抽象方法，子类全给实现了，结果发现代码确实不重复了，但灵活性很差。原因就在于他们没有用钩子。

理解钩子的关键，是搞清楚这三类方法的分工边界：

• 抽象方法表达的是“这个步骤必须有，但怎么做各不相同”。这是流程的强制变体，子类必须实现。
• 具体方法表达的是“所有子类都共用这一段逻辑”。这是流程的公共部分，子类无需关心。
• 钩子方法表达的是“这个步骤不一定需要，要做的话由子类说了算”。这是流程的可选变体，子类根据自己的情况决定是否触发。

打个比方，公司团建的流程骨架是：集合、出发、活动、吃饭、返程。抽象方法是“具体搞什么活动”——爬山还是桌游，必须选一个；具体方法是“集合点名”“返程清点人数”，这些都一样；钩子方法是“要不要安排晚宴”——默认不安排，但某个部门想加的话可以覆盖这个钩子。

4.2 三种高频钩子设计模式

我在实际项目里，用得最多的钩子设计有三种，这里直接列出来供参考。

第一种：布尔开关型钩子

就是控制某一步骤“要不要执行”。最典型的是 needNotify()、needRetry()、needValidate()。默认返回 true 或 false，子类按需覆盖。它的特点是代码侵入最小，只要在流程里加一个 if (xxx()) 就能完成步骤裁剪。

第二种：空实现扩展点型钩子

父类定义了一个空方法，比如 beforePay()、afterPay()、onError()，在流程的特定位置调用。子类就算不覆盖也不影响流程正常执行，覆盖之后则可以插入自己的业务逻辑。这种钩子非常适合做“流程埋点”和“定制扩展”，而且不会污染抽象方法的强制约束。

比如支付流程里，我可以加一个 afterSuccess(PayResult result) 空钩子，微信渠道覆盖它去做“发放微信渠道专享优惠券”，支付宝渠道覆盖它去做“支付宝积分累积”。父类骨架一行代码不动，就能通过空方法钩子挂接各种渠道差异需求。

第三种：条件定制型钩子

这种钩子本质上和第一种类似，但返回值不是单个布尔值，而是一个可定制的对象或策略。比如 notifyType() 返回 SMS、PUSH、SERVER_PUSH 等不同值，流程根据返回值来决定走哪个分支。在实际业务中这种设计对复杂场景特别实用。

4.3 钩子使用中要避开的坑

钩子虽好，但别贪多。我见过有些人把模板方法类写成了“钩子农场”，里面七八个钩子，子类接入的时候根本不知道该覆盖哪个、不覆盖哪个。

这是我在项目里总结出来的一套避坑策略：

• 钩子方法命名要有明确语义。 布尔型钩子统一用 needXxx() / enableXxx()，空实现扩展点统一用 onXxx() / beforeXxx() / afterXxx()，别人一看方法名就知道这个钩子是干嘛的。
• 钩子默认值要让“不覆盖”成为大多数场景的正确选择。 也就是说，默认行为必须是“什么都不做/允许执行”。如果一个钩子大多数子类都需要覆盖，那它更应该是一个抽象方法，别当钩子藏着。
• 不要让钩子和抽象方法职责重叠。 如果一个步骤既想让子类决定是否执行、又想让子类决定怎么执行，那就拆成两个方法：一个布尔钩子定开关，一个抽象方法定义实现。混在一起会让子类非常难写。
• 钩子需要在前置调用时设计好上下文。 比如钩子方法 needNotify() 如果要用到 PayRequest 里的字段，那么它的方法签名就应该带上 PayRequest request 参数。否则别人覆盖钩子的时候拿不到业务上下文，还得走成员变量传递，代码会变得很脏。

5. 模板方法模式的优缺点与适用场景盘点

5.1 优点：为什么说它是“封装不变，扩展可变”的典范

模板方法模式在实际工程里的优点，可以归结为四个方面。

第一，代码复用最大化。 所有公共逻辑都上收到父类，三个渠道共用的幂等校验、流水保存、日志记录只写一次。没有重复代码，就没有“改了这处忘了那处”的隐患。

第二，符合开闭原则。 新增渠道业务时，不需要修改父类骨架，只需要新增一个子类，实现抽象方法、按需覆盖钩子。系统对扩展开放，对修改关闭，这正是开闭原则的直观体现。

第三，流程结构清晰统一。 所有业务流程的骨架都定义在父类模板方法里，它是唯一的“流程权威文档”。新人上手时，读一个父类模板方法，就能搞清楚整个业务的全部环节；再看子类，就能快速定位渠道差异。

第四，钩子机制让扩展有弹性。 流程既能保持骨架稳定，又能通过钩子在关键节点插入可选的逻辑。这种“刚性骨架+柔性扩展”的组合，是模板方法模式最有魅力的地方。

5.2 缺点与约束：白盒复用带来的双刃剑

模板方法模式的缺点，同样值得认真对待。

继承是强耦合关系。 父类模板方法的一个改动，会影响所有继承它的子类。比如我突然在支付流程里加一步“敏感词校验”，全部渠道的支付都会被影响。这个看着像优点（公共逻辑一处修改全局生效），但反过来也是风险——如果某个渠道因为特殊原因不能做敏感词校验，你就得给它设计一个 needSensitiveCheck() 钩子来绕开，父类的复杂度会被这类“特例”一点点推高。

类数量会膨胀。 每个新渠道都要新增一个子类，业务线多了以后，“模板类 + 多个子类”的类数量增长很快。如果没做好包结构和命名规范，代码仓库会变得杂乱。

单继承限制。 Java 是单继承体系，如果一个类本身已经继承了其他业务基类（比如某个框架的 BaseController），就很难再继承我们的模板类。这种场景下，要么用“组合+模板方法思想”变体处理，要么考虑策略模式。

5.3 适用场景与反例对照

结合我自己的实践经验，下面这些场景非常适合用模板方法模式：

• 多个子类有相同的业务流程，只是细节不同。 比如多渠道支付、多物流商电子面单、多数据源导入。
• 流程步骤的先后顺序需要严格统一。 比如审批流、结算流，先做什么后做什么不能乱。
• 公共逻辑量较大，且需要统一修改。 比如日志记录、埋点上报、幂等校验、审计留痕。
• 框架代码需要给使用者预留扩展点。 比如定义好流程，在某些节点留钩子给上层业务做定制。

不适合的场景也有不少，别硬套：

• 子类之间的流程差异极大，只是个别步骤名相似。 那强行抽象出来的骨架都是虚的，硬套模板方法只会得到一个全是空实现的大父类。
• 流程本身变化频繁且每个子类都可能调整顺序。 模板方法的骨架是 final 的，顺序定死之后调整成本很高。这时候用策略模式组合出一套流程，反而更灵活。
• 当前用组合关系比继承关系更自然。 如果这个类已经继承了别的类，或者你不想让子类和父类绑得那么死，就不要强行用模板方法。

6. 模板方法模式 vs 策略模式：一次理清这对“流程兄弟”

6.1 一个场景，两种架构风格

模板方法模式和策略模式在实际开发里是“撞车”概率最高的两个模式，因为它们都在解决同一个问题：把变的部分和不变的部分拆开。但拆的手法完全不同。

还是拿支付流程举例。

模板方法模式的思路是，定义一个抽象父类，把流程骨架锁死在父类的 pay() 方法里，然后把具体的签名算法、请求发送、响应解析通过继承让子类去重写。它的核心关键字是继承，整个流程的控制权在父类手上。

策略模式的思路是，定义一个 PayStrategy 接口，里面只有一个 pay() 方法。微信、支付宝、银行卡各自实现这个策略，调用方持有 PayStrategy 接口，在运行时决定传哪一个策略进去。它的核心关键字是组合，流程的控制权在调用方手里。

对比一下就发现，同样是支付渠道差别的处理，模板方法把“整个算法的骨架”放进了父类，而策略把“整个算法”塞进了一个独立的策略对象里。前者是“你已经有了一个流程框架，来填细节”，后者是“你给我一个完整算法，我直接调用”。

6.2 维度对比

6.3 在 Android 和 Spring 源码中的影子

很多初学者学设计模式的时候，觉得这东西只活在课本示例里。其实模板方法模式在大厂开源框架里到处都是，几个我印象比较深的例子分享一下。

Android 的 AsyncTask。AsyncTask.execute() 就是典型的模板方法，它内部把线程池调度、主线程切换、结果回调都串好了，对外只暴露 onPreExecute()、doInBackground()、onProgressUpdate()、onPostExecute() 这几个扩展点。你只要覆写这四个方法，整个异步任务的骨架流程完全由父类控制。

Android 的 View.draw()。View 的 draw(Canvas canvas) 方法也是一个模板方法，它内部按照背景、图层、子视图、装饰等固定顺序依次绘制，子类通过重写 onDraw() 定制自己的绘制内容。整个绘制流程是系统定死的，子类只能在自己的环节里做文章。

Spring 的 JdbcTemplate。JdbcTemplate.execute() 里把获取连接、创建 Statement、处理异常、释放资源这些固定步骤全部封装好了，外部传进去的 StatementCallback 实际上就是模板方法里抽象方法的实现。你用 JdbcTemplate 写 SQL 查询时，基本感受不到资源释放、异常处理这些麻烦事，因为它们都被骨架吃掉了。

Spring 的 OncePerRequestFilter。这个过滤器类定义了请求过滤的流程骨架，doFilterInternal() 是抽象方法，子类实现具体的过滤逻辑。框架保证了每个请求过滤只执行一次，流程不被破坏。

这些例子说明一件事：真正优秀的框架代码，大量使用模板方法模式来封装“固定流程”，同时通过抽象方法或钩子给使用者留出扩展口子。学这个模式，不只是为了应付面试，更是为了以后读源码的时候能更快地理解作者的意图。

7. 我在实际项目中踩过的坑与使用建议

7.1 骨架方法没有加 final 的后果

这算是我踩过比较实在的一个坑。早期写模板类的时候，我把模板方法 pay() 没加 final，过程里被一个同事直接重写了，而且他在重写的时候少调了“保存流水”这一步。那个 bug 隐藏了很久，直到财务对账的时候才发现少了好几条流水记录。

排查的过程很痛苦，因为代码表面上没有任何报错。后来从 Git 日志里发现这个类的模板方法曾经被重写过，才定位到问题。

在这之后，我给团队定了一条硬性规则：模板方法必须加 final。既然叫模板方法，流程骨架就是权威，谁都不许改顺序、删步骤。如果确实有渠道需要特殊流程，那就通过钩子来做局部调整，而不是整体重写。这条规则后来在很多项目里都有效地防止了流程被无意破坏。

7.2 钩子方法越加越多的失控现场

还有一个反面教材。之前在一个订单模块里，我一开始只设计了两个钩子，后来需求各种变化，每来一个就加一个钩子，半年不到钩子方法积累了十几个。结果新同事接入的时候一脸懵，每个子类都要覆盖五六个钩子，代码又臭又长。

后来我反思了一下，问题的根源在于把个别场景的特例直接建模成了钩子。几个渠道都需要的扩展点，才值得设计成钩子；一两个渠道的特例需求，完全可以通过组合或者独立扩展类来解决，没必要全塞进模板类里。碰到这类情况，宁可让少数渠道自己单独处理，也别把共性模板类越改越重。

7.3 一套我自己用着很顺手的落地建议

最后分享几个经过实际项目检验的使用建议，你可以直接抄去用。

• 模板方法加 final。 流程骨架不允许重写，这是底线。
• 抽象方法控制在 3 到 5 个。 如果抽象方法太多，说明这个模板拆分粒度过细，子类实现负担太重。这时候考虑把多个相关步骤合并成一个步骤方法。
• 钩子方法要有默认值，且默认值必须让大多数场景直接用。 千万不要让每个子类都去覆盖同一个钩子，那是设计失误的信号。
• 钩子命名统一。 布尔开关用 needXxx() / enableXxx()，扩展点用 beforeXxx() / afterXxx() / onXxx()。命名即文档，省得额外写解释。
• 模板类和子类放同一包，用抽象类命名规范区分。 比如 AbstractPayService、BasePayService，一眼能看出来是模板类。
• 配合工厂模式使用。 模板方法模式负责定义流程骨架，工厂负责根据条件返回合适的子类实例。在调用方这层，代码会非常干净，扩充新子类时也不需要修改业务代码。

这个模式我个人的体会是：它是把“稳定性”和“扩展性”平衡得比较好的一个模式，特别适合那些业务环节成熟、流程相对固定的系统模块。但用在流程本身还在快速演变的早期需求上，骨架一旦定死反而会成为负担。判断要不要用模板方法，关键看你手里的流程到底是“稳定复制”还是“持续变形”，前者用它一劳永逸，后者直接上策略模式或者干脆先写冗余代码等稳定了再重构。

如果你正在设计一个多渠道、多供应商、多类型的业务模块，建议先画出流程的“最大公约数”，再标出每个环节的变体类型，最后决定哪些步骤设计成抽象方法、哪些步骤设计成钩子。这个图一旦画清楚了，代码怎么写基本就水到渠成了。