优先选择组合而非继承，因继承导致类耦合紧、脆弱基类问题频发；组合通过接口隔离依赖，提升可替换性与可测性，且避免状态泄露；接口default方法不可替代继承，仅适用于无状态逻辑。
继承导致类耦合过紧，修改父类常引发子类意外行为
当子类 extends 父类时，它不仅获得方法和字段，还继承了父类的实现细节、生命周期约束（如构造顺序）、甚至可能被覆盖的 protected 方法逻辑。一旦父类添加新方法或改变 final 状态，子类编译可能失败；若父类某方法内部调用另一个可重写的方法（模板方法模式中常见），子类重写后可能破坏原有流程——这种“脆弱基类问题”在大型项目中极难排查。
典型错误现象包括：NullPointerException 出现在子类构造器中调用父类未初始化完成的字段，或 StackOverflowError 因重写方法时误调自身（如忘记 super.xxx()）。
- 除非明确需要“是某种类型”的语义（如
Dog extends Animal），否则优先避开继承 - 避免让父类包含业务逻辑强、易变的状态管理代码
- 若必须继承，将父类设计为
final或所有可重写方法标注@Override并加详细注释说明契约
组合通过接口隔离依赖，替换与测试更可控
组合的核心是“有一个”，即类内部持有其他类的实例，并通过接口（而非具体实现）交互。这天然支持依赖倒置：只要接口不变，底层实现可随时替换（如用 MockDatabase 替换 MySQLDatabase），且不影响使用方。
常见陷阱是直接暴露组合对象的引用，导致外部绕过当前类的封装逻辑去操作内部对象。例如，返回 getLogger() 得到一个 Logger 实例后，调用方可能直接 logger.setLevel(...)，破坏该类预设的日志策略。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 组合对象应声明为接口类型（如
private final DataSource dataSource），而非具体类 - 禁止通过 getter 暴露可变内部对象；如需访问，提供受限的委托方法（如
logInfo(String msg)） - 构造器中传入依赖项，避免在方法内 new 具体实现，便于单元测试注入模拟对象
Java 8+ 接口默认方法不是继承的替代方案
有人试图用接口 + default 方法模拟“多重继承”，但这是危险的权宜之计。接口本应表达能力契约（Runnable、Comparable），而非提供可复用的实现。当多个接口含同名 default 方法时，实现类必须显式覆写，否则编译报错：class A inherits unrelated defaults for method xxx() from types B and C。
更严重的是，default 方法无法访问实现类的私有字段或 this 的非公开状态，导致逻辑被迫外移或重复判断，反而增加维护成本。
-
default方法只适合无状态、纯计算型逻辑（如Collections.sort()的简化版） - 涉及状态变更、资源管理（如打开/关闭连接）、或需访问
protected成员时，必须用组合封装具体类 - 不要为了复用几行代码而把业务逻辑塞进接口——那是类的职责
真实场景下如何选：看是否需要运行时多态 + 类型检查
如果框架强制要求某种类型（如 Spring 的 @Controller 类必须继承 BaseController 才能被扫描），或你需要用 instanceof 判断类型并做分支处理（如 if (obj instanceof PaymentProcessor) { ... }），此时继承是必要代价。但多数业务代码不需要这种能力。
更多时候，你真正需要的是“能执行某操作”，而不是“属于某类”。这时定义接口 + 组合实现类，既满足扩展性，又不绑定实现细节。
- 对外暴露 API 时，参数/返回值用接口（如
process(Validator validator)），内部用组合持有具体实现 - 已有继承体系难以重构？先提取公共逻辑为工具类或服务类，再逐步将子类中的重复代码替换为对该服务的调用
- 警惕“为了复用而继承”：Java 不支持多继承，但一个类可以组合任意多个对象——这才是更灵活的复用路径
组合不是银弹，但它把“怎么实现”和“要做什么”分得更清楚。继承容易写，组合需要多想两步接口怎么切、责任怎么划——而这一步，恰恰是系统长期可维护的关键所在。
