java - 为什么使用具有共同祖先的菱形案例来解释 Java 多继承问题，而不是两个不相关的父类？

Question

这个问题对 Java 人来说可能听起来很奇怪，但如果你试着解释一下，那就太好了。

这些天来，我正在清除一些 Java 的非常基本的概念。 所以我来到Java的继承和接口(interface)主题。

在阅读本文时，我发现 Java 不支持多重继承并且也理解，我无法理解为什么到处讨论钻石图形问题(创建钻石的至少 4 个类)来解释这种行为，可以我们仅使用 3 个类就无法理解这个问题。

说，我有 A 类和 B 类，这两个类是不同的(它们不是公共(public)类的子类)但它们有一个公共(public)方法，它们看起来像:-

class A {
    void add(int a, int b) {

    }
}

class B {
    void add(int a, int b) {

    }
}

好的，现在说Java是否支持多重继承，如果有一个类是A和B的子类，如下所示:-

class C extends A,B{ //If this was possible
    @Override
    void add(int a, int b) { 
        // TODO Auto-generated method stub
        super.add(a, b); //Which version of this, from A or B ?
    }
 }

然后编译器将无法找到从 A 或 B 调用哪个方法，这就是 Java 不支持多重继承的原因。那么这个概念有什么问题吗？

当我读到这个主题时，我能够理解 Diamond 问题，但我无法理解为什么人们没有给出三个类的示例(如果这是有效的一个，因为我们只使用了 3 个类来演示问题所以通过将其与菱形继承(钻石问题)进行比较，它很容易理解。)

让我知道这个例子是否不适合解释问题，或者这也可以用来理解问题。

编辑: 我在这里获得了一张近距离投票，表明这个问题尚不清楚。 这是主要问题:-

我能理解为什么“Java 不支持多重继承”只有如上所述的 3 个类，或者我必须有 4 个类(菱形结构)才能理解这个问题。

Answer 1

菱形继承(钻石问题)的问题并不多shared behaviour but shared state .可以看到，Java其实一直都支持多重继承，但只支持类型的多重继承。

只有三个类，通过引入像 super.A 或 super.B 这样的简单结构，这个问题相对容易解决。虽然您只查看被覆盖的方法，但您是否有共同的祖先或只有基本的三个类确实无关紧要。

但是，如果 A 和 B 有一个共同的祖先，并且它们都继承了它们的状态，那么你就有大麻烦了。您是否存储了这个共同祖先状态的两个单独副本？这更像是组合而不是继承。或者你只存储一个由 A 和 B 共享的，当他们操纵它们继承的共享状态时导致奇怪的交互？

class A {
  protected int foo;
}

class B extends A {
  public B() {
    this.foo = 42;
  }
}

class C extends A {
  public C() {
    this.foo = 0xf00;
  }
}

class D extends B,C {
  public D() {
    System.out.println( "Foo is: "+foo ); //Now what?
  }
}

请注意，如果类 A 不存在并且 B 和 C 都声明了它们自己的 foo 字段。仍然存在名称冲突的问题，但这可以通过一些命名空间结构(B.this.foo 和 C.this.foo 可能，就像我们所做的那样)来解决与内部类？)。另一方面，真正的菱形问题不仅仅是命名冲突，而是当 D 的两个不相关的父类(super class)(B 和 C) 共享相同的状态，它们都从 A 继承。这就是为什么需要所有四个类来展示问题的全部范围。

多重继承中的共享行为不会出现同样的问题。以至于最近推出的default methods正是这样做。这意味着现在也允许实现的多重继承。关于调用哪个实现的解析仍有一些复杂性，但由于接口(interface)是无状态的，因此避免了最大的问题。