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

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

这几天我正在理清Java的一些非常基础的概念。 所以我来到了Java的继承和接口主题。

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

比如说，我有 A 类和 B 类，这两个类是不同的（它们不是公共类的子类），但它们有一个公共方法，它们看起来像：-

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不支持多重继承的原因。那么这个概念有什么问题吗？

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

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

Edit:我在这里得到了接近的一票，表明这个问题尚不清楚。 这是主要问题：-

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

钻石继承的问题没那么大共同行为 but 共享状态 http://docs.oracle.com/javase/tutorial/java/IandI/multipleinheritance.html。可以看到，Java其实一直支持多重继承，但只是类型的多重继承.

只有三个类，通过引入像这样的简单构造，问题就可以相对容易地解决super.A or super.B。虽然您只查看重写的方法，但您是否具有共同的祖先或仅具有基本的三个类确实并不重要。

然而如果A and B有一个共同的祖先，他们都继承了这个国家，那么你就有大麻烦了。您是否存储这个共同祖先的状态的两个单独的副本？这更像是组合而不是继承。或者你只存储一个由双方共享的A and 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 and C宣告了自己的foo场地。仍然会存在名称冲突的问题，但这可以通过一些命名空间构造来解决（B.this.foo and C.this.foo也许，就像我们对内部类所做的那样？）。另一方面，真正的钻石问题不仅仅是命名冲突，而是当两个不相关的超类D (B and C）共享相同的状态，它们都继承自A。这就是为什么需要所有四个类来展示问题的全部范围。

多重继承中的共享行为不会出现同样的问题。以至于最近推出了默认方法 http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html正是这样做。这意味着现在也允许实现的多重继承。关于调用哪个实现的解决方案仍然存在一些复杂性，但由于接口是无状态的，因此避免了最大的问题。