在Java中组合和继承如何取舍_Java面向对象设计原则解析

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《在Java中组合和继承如何取舍_Java面向对象设计原则解析》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

应优先使用组合而非继承，因继承仅适用于“是”关系（如Car是Vehicle），而“有”关系（如Car有Engine）须用组合；滥用继承导致ClassCastException、空实现、维护困难等问题，且易违反Liskov替换原则。

继承用在“是”关系，组合用在“有”关系

判断该不该用继承，就看子类是不是父类的一种。比如 Car 是 Vehicle 的一种，用继承合理；但 Car 有 Engine，就不能让 Car extends Engine——这是典型的组合误用。

常见错误现象：ClassCastException 频繁出现、子类被迫重写大量空实现、父类一改，多个子类全崩。这些问题往往源于把“能复用”当成了“该继承”。

• 如果只是为了代码复用，优先考虑组合 + 接口（比如让 Car 持有 Engine 类型的字段）
• 若使用继承，父类应尽量抽象、稳定，避免含具体实现逻辑（尤其是非 protected 的可变字段）
• Java 中 final 类（如 String）或 private 构造器类（如 Collections 工具类）天然排斥继承，这时组合是唯一选择

组合更易测试和替换，继承破坏封装

组合对象可以轻松被 mock 或替换，比如单元测试中把真实的 DatabaseService 换成 MockDatabaseService；而继承关系下，子类直接依赖父类的实现细节，测试时几乎无法隔离。

性能上差异极小，但可维护性差距明显：继承链越深，修改成本越高；组合则通过接口契约解耦，各模块演进互不干扰。

• 用组合时，优先依赖接口而非具体类（private DataSource dataSource 而非 private MySQLDataSource dataSource）
• 避免在父类里暴露 protected 方法供子类调用——这等于把内部逻辑“拱手让人”，后续想改都得同步通知所有子类
• IDE 重构时，“提取超类”（Extract Superclass）容易诱使人盲目建继承，要警惕；而“提取接口”（Extract Interface）+ 组合更安全

Liskov 替换原则（LSP）是继承的硬门槛

如果子类不能在任何场景下无缝替代父类，那继承就是错的。典型反例：Square extends Rectangle —— 当调用 setHeight() 时，正方形必须同步改宽度，违背了父类对长宽独立控制的契约。

这种问题不会在编译时报错，但运行时行为诡异，且难以调试。组合则天然规避这类陷阱，因为“拥有”不承诺行为一致性。

• 检查子类是否重写了父类方法并改变了前置/后置条件（比如父类允许 null 参数，子类抛 NullPointerException）
• 子类不应缩小父类方法的访问权限（如父类 public，子类改成 protected）
• 一旦发现子类需要 instanceof 判断自身类型再分支处理，大概率已违反 LSP，应回退到组合 + 策略模式

Java 8+ 默认方法让接口也能复用逻辑，进一步削弱继承必要性

过去接口只能定义契约，现在 default 方法允许提供默认实现，配合组合，能覆盖大部分“想复用又不想继承”的场景。

例如日志能力，不必让所有业务类继承 BaseLogger，而是定义 Loggable 接口带 default void log(String msg)，再由各类自行 implements Loggable 并组合具体日志器。

• 注意 default 方法不能访问实现类的私有字段，所以它适合通用行为（格式化、转发），不适合强状态耦合逻辑
• 若多个 default 方法存在冲突（如两个接口都定义了同签名 default 方法），实现类必须显式重写，这反而强化了设计意图的表达
• 比起继承，这种方式更轻量，且不强制类层级结构，对已有类添加能力零侵入

实际项目里最麻烦的不是选错组合或继承，而是混用：既继承又组合，又在父类里暴露内部状态，还让子类去“修复”父类设计缺陷。这种叠加态会让后续所有人不敢动、不敢测、不敢删。

以上就是《在Java中组合和继承如何取舍_Java面向对象设计原则解析》的详细内容，更多关于的资料请关注golang学习网公众号！