模板方法模式通过抽象类定义算法骨架，用final模板方法固定执行顺序，子类仅实现抽象步骤和钩子方法；适合主干一致、局部差异稳定的流程，如订单创建、报表导出。
模板方法模式的核心，是把一个算法中不变的部分抽出来固定在抽象类里，把可变的部分留给子类去实现。它不靠接口，而是靠抽象类的继承机制来约束流程，既保证了执行顺序，又留出了定制空间。
定义标准骨架：在抽象类中写死流程结构
抽象类负责声明整个算法的执行步骤和调用顺序，每个步骤可以是具体方法（如公共校验、日志记录），也可以是抽象方法（如核心业务逻辑）。关键在于，final修饰的模板方法不能被重写，确保子类无法破坏流程。
- 模板方法通常命名为execute()、process()或doOperation()
- 所有抽象方法用protected abstract声明，限定仅子类可见可实现
- 钩子方法（hook）用空实现的protected方法提供扩展点，比如beforeExecute()、afterExecute()
子类专注实现差异逻辑：只写该写的，不碰流程控制
子类继承抽象类后，只需覆盖抽象方法，完成具体业务，其余校验、包装、清理等通用动作自动执行。这样避免了重复代码，也防止开发人员误删或颠倒步骤。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 例如支付流程中，validate()、deductBalance()、sendNotification()分别由不同子类实现，但execute()始终按“校验→扣款→通知→记录”的顺序调用
- 若某子类无需通知，可重写钩子方法sendNotification()为空，不影响主干流程
实战注意点：避免常见陷阱
模板方法看似简单，但实际使用中容易出错。重点不在“怎么写”，而在“怎么设计得安全又灵活”。
- 抽象方法不要返回void以外的类型，除非你明确要求子类必须提供结果参与后续步骤；否则优先用protected final方法封装返回值处理
- 不要在模板方法中直接new子类实例——这会破坏继承关系，也违背开闭原则
- 如果多个子类共享某段逻辑（如统一加解密），把它提取成protected final方法放在抽象类中，而不是复制到每个子类
何时该用，何时不该用
适合用模板方法的场景：多个相似流程，主干一致、局部差异明显，且这些差异稳定、不易频繁变动。不适合的场景：流程本身还不清晰，或者子类之间差异太大、共性极少。
- 推荐用：订单创建、报表导出、审批链路、消息推送适配器
- 慎用或改用策略+工厂：算法分支多、条件复杂、运行时动态切换逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
