抽象类不能直接实例化，普通类可以；抽象类定义通用结构并强制子类实现抽象方法，普通类封装具体功能；模板方法模式利用该特性将算法骨架放在抽象类中，可变步骤延迟至子类实现。
抽象类不能直接实例化，而普通类可以；抽象类用来定义通用结构和强制子类实现特定行为，普通类侧重具体功能封装。模板方法模式正是基于抽象类的这种特性设计的——它把算法骨架放在抽象类中，把可变步骤延迟到子类实现。
继承规则差异：抽象类 vs 普通类
Java 中抽象类与普通类在继承上的核心区别在于语义约束和编译检查：
- 抽象类用 abstract 修饰，允许包含抽象方法（无方法体）和具体方法；普通类必须为所有方法提供实现，且不能含抽象方法
- 子类继承抽象类时，必须实现全部抽象方法（除非子类也声明为 abstract）；继承普通类则无此强制要求
- 抽象类可以有构造方法，但仅用于子类调用 super() 初始化，不能 new 抽象类实例；普通类可自由实例化
- 抽象类更强调“是什么”（类型契约），普通类更强调“能做什么”（行为实现）
模板方法模式：抽象类的典型应用场景
模板方法模式把一个算法的不变部分（骨架）提取到抽象类中，将可变部分（细节）交给子类定制。关键在于：父类定义流程，子类填充步骤。
- 抽象类中定义 final 的模板方法（如 execute()），按固定顺序调用若干钩子方法（如 init()、doWork()、cleanup()）
- 钩子方法可为 abstract（强制重写）或 default（可选重写），由子类决定是否覆盖
- 子类只需关注业务逻辑差异点，无需重复控制流程，避免了代码复制和流程错乱
例如：数据库操作模板中，connect → executeSQL → close 是固定流程，但 SQL 内容和连接参数由不同子类决定。
实际编码中的常见误区与建议
用抽象类实现模板方法时，容易忽略设计意图导致灵活性下降或职责混乱：
- 不要在模板方法中加入条件分支来“绕过”抽象方法——这违背了模板方法的初衷；应通过钩子方法的空实现或模板参数控制行为
- 抽象类中的具体方法应保持稳定；若某方法频繁被子类重写，考虑改为 abstract 或提取为策略接口
- 避免抽象类过度继承层次（如 A ← B ← C ← D），三层以内较易维护；深层继承往往说明职责未合理切分
- 当子类差异仅是数据或配置时，优先用组合+策略模式替代继承，减少类膨胀
与接口的协同使用：更灵活的扩展方式
现代 Java 开发中，抽象类常与接口配合使用，兼顾规范性与灵活性：
- 接口定义能力契约（如 Runnable、Comparable），抽象类提供默认实现和状态管理
- 从 Java 8 起，接口可含 default/static 方法，但无法持有字段或构造逻辑；抽象类仍不可替代
- 推荐实践：用接口描述“能做什么”，用抽象类实现“怎么做”的共性，子类继承抽象类并实现额外接口
比如网络请求模块可定义 HttpRequest 接口，再提供 AbstractHttpClient 抽象类封装重试、日志、超时等通用逻辑，各业务客户端继承它并实现具体请求构造逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
