Kotlin与Java8采用抽象类+接口替代多继承的原因是什么？

1 抽象类与接口的适用场景 #

二者本质差异即使在Kotlin/Java8之后依然存在：抽象类可以持有状态（普通成员属性、私有属性），接口不允许持有状态（Kotlin中接口属性只能是抽象的，或自定义访问器且不能依赖幕后字段），基于这个差异的选型逻辑如下：

• 抽象类：适合给存在明确“is-a”从属关系的同类对象定义核心模板。比如所有动物都属于Animal类别，可以将Animal定义为抽象类，内部存放所有动物共有的属性（如年龄、名称）、共有的具体方法实现（如进食逻辑），同时定义抽象方法（如发声逻辑）留给子类自定义实现，一个子类只能继承一个抽象类，符合从属关系的本质。
• 接口：适合给不存在从属关系的不同类对象定义公共能力契约，对应“can-do”关系。比如飞这个能力，鸟类、无人机、民航飞机都可以具备，但三者不属于同一个父类，就可以定义Flyable接口约定飞行相关的方法，所有需要该能力的类都可以实现这个接口，一个类可以同时实现多个接口。

2 Kotlin 不支持直接多继承的原因 #

这一设计并非技术上无法实现，而是综合权衡后的选择：

• 首先规避了多继承的固有缺陷：最典型的就是菱形继承问题——如果A类有方法test()，B、C都继承A并重写了test()，D同时继承B和C，调用D.test()时会出现歧义，不知道该调用B还是C的实现。C++通过虚拟继承解决该问题，但大幅提升了语言复杂度和运行时开销，也容易让开发者写出隐含歧义的代码。
• 其次是兼容Java生态的要求：Kotlin的核心设计目标之一就是和Java 100%互操作，Java本身不支持多继承，Kotlin如果新增多继承特性会直接破坏和现有Java类体系的兼容性，无法实现无缝迁移。
• 最后单继承+多接口的组合已经能覆盖绝大多数多继承的使用场景，不需要为了极个别小众场景提升语言的学习和使用成本。

3 抽象类+接口组合和多继承的差异与优势 #

这个组合并不是多继承的另一种实现形式，是针对性解决多继承缺陷的替代设计，相比原生多继承有明确的优势，也直接影响二者的选型逻辑：

• 无隐式歧义：接口即便有默认方法实现，出现多父类方法冲突时，Kotlin会强制要求子类显式重写冲突方法，指定要调用的父类实现，不会出现C++多继承中隐式继承导致的未察觉的逻辑错误。
• 语义更清晰：单继承对应从属关系，多接口对应能力扩展，代码的分层逻辑更明确，不会出现为了复用多个方法乱继承多个无关类、导致类的从属关系混乱的问题。
• 耦合度更低：接口是纯能力契约，不依赖具体实现，修改接口默认方法不会影响整个继承链的其他类；而多继承中任意父类的状态、实现改动都可能波及所有子类，维护成本更高。

内容的提问来源于stack exchange，提问作者Josael Perez