抽象类配合模板方法模式是定义算法骨架最经典的方式：父类用final方法封装固定流程，抽象方法强制子类实现可变步骤，钩子方法提供可选扩展点。
抽象类配合模板方法模式，是定义算法骨架最经典、最干净的方式：把不变的流程控制逻辑放在父类中，把可变的具体步骤延迟到子类实现。
用抽象类定义算法骨架
抽象类作为模板方法的载体，负责声明整个算法的执行顺序。它不关心每一步怎么做，只规定“先做什么、再做什么、最后做什么”。关键点在于：
- 用 final 方法封装模板方法（如
execute()），禁止子类重写流程 - 把可变环节声明为 抽象方法（如
prepare()、process()、cleanup()），强制子类提供具体实现 - 允许定义 钩子方法（默认空实现的非抽象方法），供子类选择性覆盖，用于扩展点（比如日志、校验、回调）
典型结构示例（以数据处理任务为例）
假设要做“加载→解析→转换→保存”这一通用流程：
abstract class DataProcessor {
// 模板方法：不可重写，固定流程
public final void run() {
loadData();
parseData();
transformData();
saveData();
afterRun(); // 钩子，子类可选覆盖
}
// 抽象步骤：由子类实现
protected abstract void loadData();
protected abstract void parseData();
protected abstract void transformData();
protected abstract void saveData();
// 钩子方法：默认空实现，子类按需重写
protected void afterRun() {}
}
子类只需关注自己那部分逻辑，比如 JsonDataProcessor 实现 JSON 加载与解析，CsvDataProcessor 实现 CSV 相关操作——流程复用，行为定制。
结合策略或工厂提升灵活性
当算法分支较多（如不同压缩方式、不同序列化协议），可在模板中引入策略对象：
- 抽象类中声明策略接口字段（如
Serializer serializer） - 通过构造器或 setter 注入具体策略，让模板方法调用策略的
serialize()而非自己实现 - 配合简单工厂，根据配置自动创建对应子类或策略实例，进一步解耦
注意边界与设计分寸
模板方法不是万能框架，用得过重反而僵化：
- 避免模板方法过长或嵌套太深，一般建议步骤不超过 5～7 步，否则拆分成多个模板或组合使用
- 子类不应绕过模板直接调用抽象步骤——这破坏了流程约束，可通过包级私有或 protected + 文档明确约定调用方式
- 如果子类需要大幅修改流程顺序，说明这个“骨架”已不通用，应考虑用策略模式或职责链替代
