抽象类与模板方法模式详解

本文深入剖析了如何利用抽象类与模板方法模式构建稳定、可扩展的通用算法骨架，强调必须将模板方法声明为final以严防子类破坏流程顺序，合理运用abstract步骤方法与语义清晰的钩子方法（如shouldXXX）替代脆弱的条件判断，同时警惕子类误调模板方法引发的隐匿递归风险；文章还指出泛型应谨慎用于模板主流程，避免过度约束子类灵活性，并揭示真正考验架构功力的并非语法实现，而是对变化边界的精准预判——何时新增子类、何时调整钩子，直接决定骨架能否长期坚挺。

抽象类必须定义模板方法且设为 final

模板方法模式的核心是把算法骨架固定在父类，子类只能改步骤实现、不能破坏流程顺序。所以 templateMethod() 一定要声明为 final，否则子类可能覆写它，整个骨架就失效了。

常见错误是只把步骤方法设为 abstract 或 protected，却忘了锁住主流程。Java 和 C# 都要求显式加 final（C# 是 sealed），Python 虽无语法强制，但应在文档和命名（如 _execute()）上明确约束。

• 骨架流程中不该被重写的入口方法，一律加 final
• 步骤方法用 abstract（强制子类实现）或 protected + 默认空实现（可选覆盖）
• 避免在模板方法里调用 this 的非 final 方法——可能触发子类过早初始化

钩子方法（hook method）比条件判断更易扩展

当算法某步需要“有则执行、无则跳过”，别在模板方法里写 if (shouldDoX()) 判断逻辑。应该提取成受保护的钩子方法，比如 shouldValidateInput()，默认返回 false，子类按需覆写。

这样既保持父类纯净，又避免把分支逻辑散落在模板中。一旦后续新增校验类型，只需新增子类并覆写钩子，不用动父类代码。

• 钩子方法命名建议以 should、is、after、before 开头，语义清晰
• 不要在钩子里做重操作（如 IO、网络），它本意是轻量决策
• 多个钩子之间注意执行时序依赖，比如 beforeProcess() 必须早于 process()

子类覆写步骤时，禁止调用父类同名模板方法形成递归

这是非常隐蔽的坑：子类在实现 doStepA() 时，误调了 super.templateMethod()，而该方法内部又调了 doStepA() ——直接栈溢出。JVM 报错类似 java.lang.StackOverflowError，但堆栈里全是 doStepA 和 templateMethod 循环。

根本原因是混淆了“算法骨架”和“具体步骤”的职责边界。模板方法是顶层协调者，步骤方法只是执行单元，二者不可互相调用。

• 子类中所有 super.xxx() 调用，只允许针对父类提供的钩子或工具方法，绝不能指向任何模板方法
• IDE 里给模板方法加 @Deprecated 注解并写明 “DO NOT CALL FROM SUBCLASSES” 是实用提醒手段
• 单元测试应覆盖子类构造后直接调用模板方法的场景，验证无意外递归

泛型抽象基类要谨慎暴露类型参数给模板方法

如果抽象类定义为 AbstractProcessor，而模板方法签名是 final void execute(T input)，看似灵活，实则限制子类自由：所有子类必须处理同一类型 T，无法支持不同输入结构。

更合理的方式是让模板方法不绑定具体类型，靠步骤方法各自适配。例如父类定义 execute() 无参，子类在 parseInput() 里做类型转换，返回内部统一的上下文对象。

• 泛型参数适合约束工具方法（如 validate(T item)），而非模板主流程
• 若真需多类型支持，用组合优于继承：把共用逻辑抽成工具类，由不同算法类持有引用
• Java 中 ? extends T 等通配符会让子类覆写变得更复杂，多数情况下纯属过度设计

真正难的不是写出能跑的模板，而是预判哪些步骤未来一定变化、哪些必须死死锁住。每次加新子类前，先问一句：这个改动，是应该新增一个子类，还是该调整钩子逻辑？答错一次，骨架就开始松动。

以上就是《抽象类与模板方法模式详解》的详细内容，更多关于的资料请关注golang学习网公众号！