设计时防御继承破坏封装的核心是控制子类与父类的耦合深度和方式：构造器禁用可重写方法调用，初始化逻辑移至显式setup()或final外壳方法；工具方法private、字段private+受控getter/setter、主流程方法final；警惕自调用链中可覆盖点；优先组合+接口，必要时用sealed class限定继承。
设计时防御继承对封装的破坏，核心是让子类“知道能做什么”，而不是“必须知道怎么做”。关键不在禁止继承，而在控制子类与父类之间的耦合深度和方式。
构造阶段杜绝可重写方法调用
父类构造器中一旦调用被子类重写的方法，子类字段尚未初始化，极易触发 null 异常或逻辑错乱。这不是偶发问题，而是确定性风险。
- 把所有初始化逻辑移出构造器，改用显式 setup() 或 init() 方法，在对象构建完成后由使用者主动调用
- 若需预留钩子，定义 final 的初始化外壳方法（如 final void safeInit()），内部调用子类可重写的 protected 方法，确保调用时机可控
- 避免使用 init()、configure() 等常见命名作为可重写方法，防止子类误判调用上下文
限制可重写范围，用访问控制收口
不是所有方法都该开放重写——开放即承诺，承诺就要担责。过度暴露 protected 成员，等于把封装交到子类手上。
- 工具方法一律声明为 private，不参与继承契约；需要复用时提取为静态工具类
- 字段全部设为 private，提供受控的 protected getter/setter，必要时返回不可变视图（如 Collections.unmodifiableList(items)）
- 主流程方法加 final，只留少数语义清晰的 abstract 或 protected hook（如 doProcess()），并配 Javadoc 明确前置/后置条件
警惕自调用链中的可覆盖点
父类公开方法内部调用另一个可被重写的方法，会导致子类重写后行为静默变更。这种间接依赖最难排查，也最易引发线上事故。
- 检查所有 public/protected 方法体，确认是否直接调用了其他可重写方法；若有，优先将被调用方改为 private
- 对组合型逻辑（如 addAll 调用 add），采用模板方法模式：把 add 提取为 final void add(int n) { doAdd(n); }，子类只实现 doAdd()
- 在单元测试中加入断言，验证父类方法调用链不因子类重写而改变行为边界
优先组合，用接口定义能力而非类继承
当复用意图强于 is-a 关系时，继承天然带来脆弱性。组合+接口能解耦实现细节，同时保留扩展弹性。
- 用 private final 持有依赖对象，通过委托调用替代继承，例如 private final Validator validator; 而非 extends BaseValidator
- 定义 interface 描述能力（如 Resumable、Retryable），让不同类独立实现，不共享状态或初始化逻辑
- 对必须有限扩展的场景，用 Java 17+ 的 sealed class 明确许可子类范围，配合 non-sealed 或 final 精细控制继承深度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
