Java通过接口实现多重继承，规避菱形问题：类可同时实现多个接口，提供各自方法的实现，如Duck类实现Flyable和Swimmable接口，具备飞行与游泳能力；接口仅定义行为契约，无实例变量，避免状态冲突；Java 8引入默认方法，允许接口提供默认实现，增强复用性与兼容性，当多个接口存在同名默认方法时，需显式重写以解决冲突。
Java中，我们无法让一个类直接继承多个父类，因为这会带来复杂的“菱形问题”和状态冲突。但通过接口，Java巧妙地规避了这些难题，实现了“多重继承”的效果——一个类可以同时实现多个接口，从而履行多份契约，拥有多重行为特征。这是一种强大的设计机制，让我们的代码在保持单继承清晰性的同时，获得了极大的灵活性和扩展性。
解决方案
在Java中实现接口的多重继承，核心在于一个类可以同时声明实现多个接口。这意味着该类必须提供所有这些接口中声明的方法的具体实现。
一个简单的例子可以这样来展示：
假设我们有两个接口，
Flyable和
Swimmable：
立即学习“Java免费学习笔记（深入）”；
interface Flyable {
void fly();
default void takeOff() {
System.out.println("准备起飞...");
}
}
interface Swimmable {
void swim();
default void dive() {
System.out.println("准备潜水...");
}
}现在，我们创建一个
Duck类，让它同时具备飞行和游泳的能力：
class Duck implements Flyable, Swimmable {
@Override
public void fly() {
System.out.println("鸭子扇动翅膀飞起来了！");
}
@Override
public void swim() {
System.out.println("鸭子在水里划水游泳！");
}
// 也可以选择性地重写接口的默认方法
@Override
public void takeOff() {
System.out.println("鸭子笨拙地从地面起飞！");
}
public static void main(String[] args) {
Duck mallard = new Duck();
mallard.takeOff();
mallard.fly();
mallard.dive();
mallard.swim();
}
}在这个例子中，
Duck类通过
implements Flyable, Swimmable语法，同时实现了
Flyable和
Swimmable两个接口。它必须提供
fly()和
swim()这两个抽象方法的具体实现。同时，它还可以选择性地重写接口中定义的默认方法，比如
takeOff()。这样，一个
Duck对象就拥有了两种完全不同的行为能力，这就是接口带来的多重继承的效果。
为什么Java选择通过接口而非类实现多重继承？
这其实是Java设计哲学的一个核心体现，背后有着深刻的考量。简单来说，Java避免了类层面的多重继承，主要是为了规避“菱形问题”（Diamond Problem）以及由此带来的复杂性。
想象一下，如果一个类
C同时继承了
A和
B，而
A和
B又都继承了同一个父类
P，并且
P中有一个方法
doSomething()。那么当
C调用
doSomething()时，它到底应该调用
A提供的实现，还是
B提供的实现？如果
A和
B都重写了这个方法，这种歧义性就会导致巨大的困扰。更糟糕的是，如果
A和
B都引入了相同的实例变量名，那么
C的对象中到底应该包含哪个变量？这种状态上的冲突是类多重继承最难解决的问题。
本文档主要讲述的是Android JNI开发入门与提高；JNI在Android系统中有着广泛的应用。Android系统底层都是C/C++实现的，上层提供的API都是Java的，Java通过JNI调用底层的实现。比如：Android API多媒体接口MediaPlayer类，其实底层通过JNI调用libmedia库。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
接口则不然。接口只定义了行为的契约，不包含任何实例变量（除了
static final常量），也不包含具体的方法实现（Java 8之前的接口）。当一个类实现多个接口时，它只是承诺会实现这些接口所定义的所有抽象方法。所有的实现细节都由实现类自己负责，所以不会有方法实现上的歧义，也不会有状态上的冲突。接口提供了一种纯粹的“行为多重继承”，避免了类多重继承的复杂性，保持了Java语言的简洁性和健壮性。这种设计让开发者能够专注于“做什么”，而不是“怎么做”的继承细节，从而更好地管理复杂性。
接口多重继承在实际项目中有哪些应用场景？
接口的多重继承在实际项目中的应用非常广泛，它几乎是Java企业级开发和各种框架设计的基石。
-
角色扮演与行为组合： 这是最直观的应用。一个对象可能需要扮演多种角色，拥有多种行为。例如，一个
Employee
对象可能同时是Payable
（可支付的）、Reportable
（可报告的）和Auditable
（可审计的）。通过实现这三个接口，Employee
对象就具备了这三种独立的能力，而无需关心它们是如何实现的。 -
API设计与扩展性： Java的核心API大量使用了接口多重继承。例如，
ArrayList
实现了List
,RandomAccess
,Cloneable
,Serializable
等多个接口。这意味着ArrayList
不仅是一个列表，它还支持随机访问、可克隆和可序列化。这种设计让API既清晰又富有弹性，方便未来的功能扩展。 - 设计模式的实现： 许多设计模式都依赖于接口。例如，策略模式中，不同的策略可以实现同一个接口；装饰器模式中，装饰者和被装饰者可以实现同一个接口。通过实现多个接口，一个类可以轻松地参与到不同的设计模式中，实现高度解耦和灵活的系统架构。
- 回调机制与事件处理： 在事件驱动编程中，监听器通常会实现特定的接口，以便在事件发生时被回调。一个类可能需要监听多种类型的事件，因此它会实现多个事件监听接口。
- 模块化与可测试性： 接口定义了模块之间的契约，降低了模块间的耦合。当一个类实现多个接口时，它明确地声明了自己提供的所有服务。这有助于单元测试，因为我们可以为每个接口创建独立的模拟对象，从而更容易地测试特定行为。
Java 8 引入的默认方法如何改变了接口多重继承的格局？
Java 8 引入的默认方法（Default Methods），又称之为扩展方法（Extension Methods），确实为接口带来了革命性的变化，几乎改变了我们对接口多重继承的传统认知。在此之前，接口是纯粹的抽象契约，不包含任何实现。默认方法允许在接口中提供方法的具体实现，这使得接口在某种程度上具备了抽象类的某些特性。
默认方法的核心影响：
- 向后兼容性： 这是默认方法诞生的主要原因之一。在Java 8之前，如果向一个已发布的接口添加新方法，所有实现该接口的类都必须修改以实现新方法，这会破坏现有代码。有了默认方法，可以在接口中添加新方法并提供一个默认实现，这样现有的实现类就不需要立即修改，保证了API的向后兼容性。
- “mixin”能力： 默认方法使得接口能够提供一些通用的、可复用的行为。一个类通过实现多个带有默认方法的接口，可以“混合”进多种行为，而无需在类层次结构中进行复杂的继承。这有点像多重继承类所提供的功能，但仍然避免了状态冲突。
-
冲突解决机制： 当一个类实现多个接口，并且这些接口包含同名的默认方法时，或者当一个类继承了一个父类的方法，同时又实现了包含同名默认方法的接口时，Java有一套明确的规则来解决这种冲突：
- 类中的方法优先： 如果一个类自身定义了一个方法，或者从父类继承了一个方法，这个方法会优先于任何接口中的默认方法。
- 子接口中的方法优先： 如果一个类实现了两个接口，其中一个接口继承了另一个接口，那么更具体的子接口中的默认方法会优先被使用。
-
显式重写： 如果上述规则无法解决冲突（例如，两个不相关的接口定义了同名的默认方法），那么实现类必须显式地重写这个方法，并可以选择调用
InterfaceName.super.methodName()
来指定使用哪个接口的默认实现。
代码示例：默认方法冲突解决
假设我们有以下接口：
interface A {
default void greet() {
System.out.println("Hello from A!");
}
}
interface B {
default void greet() {
System.out.println("Hello from B!");
}
}
class MyClass implements A, B {
// 必须显式重写 greet() 方法来解决冲突
@Override
public void greet() {
System.out.println("Hello from MyClass!");
// 如果需要，可以调用某个接口的默认实现
// A.super.greet();
// B.super.greet();
}
}
class AnotherClass extends MyClass implements A {
// MyClass 已经重写了 greet()，所以这里不会有冲突
// 如果 MyClass 没有重写，那么 MyClass 的父类方法会优先于 A 的默认方法
}默认方法让接口变得更加强大和灵活，模糊了接口和抽象类之间的界限。它们让Java在保持单继承模型的同时，为行为复用提供了更丰富的可能性，使得接口在构建复杂系统时扮演了更重要的角色。但同时，它也要求开发者对接口的冲突解决规则有清晰的理解，以避免潜在的运行时问题。
