模板方法模式用抽象类定义算法骨架，模板方法为final，强制子类实现abstract方法（如calculateFee）、选择性覆盖钩子方法（如beforePush），通过多态运行时绑定子类逻辑，确保流程稳定与扩展灵活。
Java 抽象类配合多态实现模板方法模式，核心是：用抽象类定义算法骨架（固定流程），把易变步骤声明为抽象方法或钩子方法，再靠多态让子类在运行时决定具体行为。
抽象类定骨架：封装不变逻辑
模板方法本身是 final 的具体方法，写死整体流程顺序，比如“校验→计算→调用→记录”。它内部调用的若干步骤，有些已实现（如统一日志、参数预处理），有些则留空：
- 用 abstract 方法 强制子类必须实现（如
calculateFee()、invokeChannel()） - 用 空 protected 方法（钩子）允许子类选择性覆盖（如
beforePush()、afterPush()）
子类靠继承 + 重写，注入变化逻辑
每个支付渠道（支付宝、微信、银行卡）都写一个具体子类，只专注自己那几块差异点：
- 不重复写校验、日志、异常包装等公共代码
- 只重写
calculateFee()—— 支付宝按笔收，微信阶梯计费，银行卡免手续费 - 只重写
invokeChannel()—— 调各自的 SDK 或 HTTP 接口 - 按需重写
beforePush()—— 比如微信要先统一下单，支付宝可跳过
多态驱动运行：父类引用调用子类实现
业务层不 new 具体类，而是通过工厂或策略上下文拿到抽象类型的引用：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
PaymentHandler handler = paymentHandlerFactory.getHandler("wechat");
handler.execute(paymentRequest); // 看似调父类方法，实际执行的是微信子类的全部重写逻辑
这依赖多态三要素同时成立：继承关系存在、子类重写了抽象/钩子方法、用抽象类类型持有子类对象。JVM 在运行期自动绑定到真实子类的方法上。
关键细节不能漏
模板方法模式不是“能跑就行”，几个实操要点直接影响可维护性：
- 模板方法必须加 final，防止子类意外重写打乱流程
- 抽象类构造器可接收配置（如商户号、密钥），通过
super(company)传给子类复用 - 钩子方法默认空实现，但命名要体现时机（
onSuccess()、onFailure()），避免子类误判调用顺序 - 如果某子类完全不想走某个钩子，就什么都不写；想增强，就重写——扩展自由，约束明确
