Java继承与组合的对比与最佳选择_技术教程

优先选择组合而非继承，因继承导致类耦合紧、脆弱基类问题频发；组合通过接口隔离依赖，提升可替换性与可测性，且避免状态泄露；接口default方法不可替代继承，仅适用于无状态逻辑。

继承导致类耦合过紧，修改父类常引发子类意外行为

当子类 extends 父类时，它不仅获得方法和字段，还继承了父类的实现细节、生命周期约束（如构造顺序）、甚至可能被覆盖的 protected 方法逻辑。一旦父类添加新方法或改变 final 状态，子类编译可能失败；若父类某方法内部调用另一个可重写的方法（模板方法模式中常见），子类重写后可能破坏原有流程——这种“脆弱基类问题”在大型项目中极难排查。

典型错误现象包括：NullPointerException 出现在子类构造器中调用父类未初始化完成的字段，或 StackOverflowError 因重写方法时误调自身（如忘记 super.xxx()）。

除非明确需要“是某种类型”的语义（如 Dog extends Animal），否则优先避开继承
避免让父类包含业务逻辑强、易变的状态管理代码
若必须继承，将父类设计为 final 或所有可重写方法标注 @Override 并加详细注释说明契约

组合通过接口隔离依赖，替换与测试更可控

组合的核心是“有一个”，即类内部持有其他类的实例，并通过接口（而非具体实现）交互。这天然支持依赖倒置：只要接口不变，底层实现可随时替换（如用 MockDatabase 替换 MySQLDatabase），且不影响使用方。

常见陷阱是直接暴露组合对象的引用，导致外部绕过当前类的封装逻辑去操作内部对象。例如，返回 getLogger() 得到一个 Logger 实例后，调用方可能直接 logger.setLevel(...)，破坏该类预设的日志策略。

组合对象应声明为接口类型（如 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) { ... }），此时继承是必要代价。但多数业务代码不需要这种能力。

更多时候，你真正需要的是“能执行某操作”，而不是“属于某类”。这时定义接口 + 组合实现类，既满足扩展性，又不绑定实现细节。