[面试题] 为什么 Java 不支持多继承？接口和抽象类该怎么选？

📖 版块 A：知识讲解版 (温故知新)

• Java 为什么不支持类的多继承：

  1. 多继承容易带来菱形继承问题。
  2. 如果两个父类里有同名方法或字段，子类语义会变得模糊。
  3. Java 更倾向通过“单继承 + 接口”降低复杂度。

• 接口的特点：

  1. 更强调“能做什么”。
  2. 适合定义行为规范和能力边界。
  3. 一个类可以实现多个接口。

• 抽象类的特点：

  1. 更强调“是什么”以及一组共享基础实现。
  2. 可以有成员变量、构造器、非抽象方法。
  3. 更适合表达稳定的父类模板。

• 怎么选：

  1. 需要表达能力规范、支持多实现时，优先接口。
  2. 需要复用公共状态和默认实现时，优先抽象类。
  3. 真实项目中经常是“接口做边界，抽象类做骨架”。

🎤 版块 B：面试实战版 (高手逐字稿)

Q：为什么 Java 不支持多继承？接口和抽象类该怎么选？

💬 高手逐字稿：

Java 不支持类的多继承，核心原因就是为了避免复杂继承体系带来的歧义，最典型的就是菱形继承问题。

比如类 D 同时继承类 B 和类 C，而 B、C 又都继承自 A。如果 B 和 C 都实现了同名方法，D 到底该继承哪一份语义？这种冲突会让类层次结构变得非常难维护。Java 作为一门面向工程的语言，宁愿牺牲一点继承自由度，也要换来更清晰、更稳定的模型，所以它选择了“类单继承，接口多实现”。

这也就引出了接口和抽象类的定位差异。

我通常会这么区分：

• 接口更偏“能力规范”，回答的是“这个类能做什么”；
• 抽象类更偏“基础模板”，回答的是“这个类本质上是什么”。

接口最大的价值，是它天然支持一个类实现多个能力边界，比如既能支付、又能审计、又能序列化，这非常适合做解耦和扩展点。抽象类则更适合沉淀公共字段、公共逻辑和默认实现，比如一套统一的模板流程。

所以在实际项目里，如果我只是想定义一组行为契约，让不同实现类各自落地，我会优先用接口；如果我已经能明确这是一类对象，并且它们之间有稳定的共性状态和默认行为，我会考虑抽象类。

真实工程里最常见的做法其实不是二选一，而是组合使用：

• 用接口定义对外能力边界；
• 用抽象类承接内部通用骨架。

这也是 Java 不支持多继承之后给出的主流解法：不用多父类叠加状态，而是用接口扩展能力、用抽象类复用骨架。