Почему для объяснения проблемы множественного наследования Java используется случай с ромбом и его общим предком, а не два несвязанных родительских класса?

Проблема с алмазным наследованием заключается не столько в общем поведении, сколько в общее состояние. Как видите, на самом деле 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 (B и C) имеют одно и то же состояние, которое они оба наследуют от A. Вот почему все четыре класса необходимы, чтобы продемонстрировать всю полноту проблемы.

Совместное поведение при множественном наследовании не вызывает такой же проблемы. Настолько, что недавно представленные методы по умолчанию делают именно это. Это означает, что теперь разрешено и множественное наследование реализаций. Все еще есть некоторые сложности, связанные с разрешением того, какую реализацию вызывать, но, поскольку интерфейсы не имеют состояния, можно избежать самой большой проблемы.

Java не поддерживает множественное наследование, потому что разработчики языка разработали Java именно таким образом. Другие языки, такие как C++, прекрасно поддерживают множественное наследование, так что это не техническая проблема, а просто критерии проектирования.

Проблема с множественным наследованием заключается в том, что не всегда ясно, к какому методу какого класса вы обращаетесь и к каким переменным экземпляра вы обращаетесь. Разные люди интерпретируют это по-разному, и разработчики Java в то время считали, что лучше вообще отказаться от множественного наследования.

C++ решает проблему класса в форме ромба с помощью виртуального наследования:

Виртуальное наследование — это метод, используемый в объектно-ориентированном программировании, где конкретный базовый класс в иерархии наследования объявляется для совместного использования своих экземпляров данных-членов с любыми другими включениями той же базы в дальнейших производных классах. Например, если класс A обычно (не виртуально) является производным от класса X (предполагается, что он содержит элементы данных), а класс B аналогичным образом, а класс C наследуется от обоих классов A и B, он будет содержать два набора элементов данных. связанный с классом X (доступный независимо, часто с подходящими квалификаторами устранения неоднозначности). Но если вместо этого класс A фактически является производным от класса X, то объекты класса C будут содержать только один набор элементов данных из класса X. Наиболее известным языком, реализующим эту функцию, является C++.

В отличие от Java, в C++ вы можете устранить неоднозначность, какой метод экземпляра вызывать, указав перед вызовом имя класса:

class X {
  public: virtual void f() { 

  } 
};

class Y : public X {
  public: virtual void f() { 

  } 
};

class Z : public Y {
  public: virtual void f() { 
    X::f();
  } 
};

Это только одна трудность, которую вам нужно решить для множественного наследования в языке. Поскольку существуют языки с множественным наследованием (например, Common Lisp, C++, Eiffel), это, очевидно, не является непреодолимым.

Common Lisp определяет точную стратегию приоритезации (упорядочивания) графа наследования, поэтому в тех редких случаях, когда это имеет значение на практике, двусмысленности не возникает.

С++ использует виртуальное наследование (я еще не пытался понять, что это значит).

Eiffel позволяет указать, как именно вы хотите наследовать, возможно, переименовав методы в подклассе.

Java просто пропустила множественное наследование. (Лично я думаю, что трудно не оскорбить его создателей, пытаясь рационализировать это решение. Конечно, трудно думать о чем-то, когда язык, на котором вы думаете, на котором это не поддерживает. .)

Проблема алмаза с четырьмя классами проще, чем проблема трех классов, описанная в вопросе.

Проблема с тремя классами добавляет еще одну проблему, которую необходимо решить в первую очередь: конфликт имен, вызванный двумя несвязанными методами add с одинаковой сигнатурой. На самом деле это не сложно решить, но это добавляет ненужную сложность. Вероятно, это было бы разрешено в Java (как уже разрешено реализовывать несколько несвязанных методов интерфейса с одной и той же сигнатурой), но могут быть языки, которые просто запрещают множественное наследование похожих методов без общего предка.

Добавляя четвертый класс, который определяет add, становится ясно, что и A, и B реализуют один и тот же метод add.

Таким образом, проблема алмаза более ясна, потому что она показывает проблему с использованием простого наследования, а не просто с использованием методов с одной и той же сигнатурой. Он хорошо известен и, вероятно, применим к более широкому кругу языков программирования, поэтому вариант с тремя классами (который добавляет дополнительную проблему конфликта имен) не имеет особого смысла и поэтому не был принят.

Множественное наследование не проблема, если вы найдете разумное решение для разрешения методов. Когда вы вызываете метод для объекта, разрешение метода — это действие по выбору версии метода класса, которую следует использовать. Для этого граф наследования линеаризуется. Затем выбирается первый класс в этой последовательности, обеспечивающий реализацию запрошенного метода.

Чтобы проиллюстрировать следующие примеры стратегий разрешения конфликтов, мы будем использовать этот алмазный график наследования:

    +-----+
    |  A  |
    |=====|
    |foo()|
    +-----+
       ^
       |
   +---+---+
   |       |
+-----+ +-----+
|  B  | |  C  |
|=====| |=====|
|foo()| |foo()|
+-----+ +-----+
   ^       ^
   |       |
   +---+---+
       |
    +-----+
    |  D  |
    |=====|
    +-----+

• Наиболее гибкая стратегия требует от программиста явного выбора реализации при создании неоднозначного класса путем явного переопределения конфликтующего метода. Вариантом этого является запрет множественного наследования. Если программист хочет наследовать поведение от нескольких классов, придется использовать композицию и написать ряд прокси-методов. Однако наивно явно разрешенные конфликты наследования имеют те же недостатки, что и…

• Поиск в глубину, который может привести к линеаризации D, B, A, C. Но таким образом A::foo() считается перед C::foo(), хотя C::foo() переопределяет A::foo()! Это не может быть тем, что мы хотели. Примером языка, использующего DFS, является Perl.

• Используйте хитрый алгоритм, гарантирующий, что если X является подклассом Y, то при линеаризации он всегда будет стоять перед Y. Такой алгоритм не сможет разгадать все графы наследования, но в большинстве случаев он обеспечивает разумную семантику: если класс переопределяет метод, он всегда будет предпочтительнее переопределенного метода. Этот алгоритм существует и называется C3. Это создаст линеаризацию D, B, C, A. C3 был впервые представлен в 1996 году. К сожалению, Java был опубликован в 1995 году, поэтому C3 не был известен, когда Java изначально проектировался.

• Используйте композицию, а не наследование — новый взгляд. Некоторые решения для множественного наследования предлагают избавиться от бита «наследования классов» и вместо этого предлагают другие единицы композиции. Одним из примеров являются mixins, которые «копируют и вставляют» определения методов в ваш класс. Это невероятно грубо.

  Идея примесей была переработана в черты (представлены в 2002 г., тоже слишком поздно для Java). ). Черты — это более общий случай как классов, так и интерфейсов. Когда вы «наследуете» трейт, определения встраиваются в ваш класс, так что это не усложняет разрешение методов. В отличие от примесей, трейты предоставляют более тонкие стратегии для разрешения конфликтов. Особенно важен порядок, в котором составляются признаки. Признаки играют заметную роль в объектной системе Perl «Moose» (называемой ролями) и в Scala.

Java предпочитает одиночное наследование по другой причине: если у каждого класса может быть только один суперкласс, нам не нужно применять сложные алгоритмы разрешения методов — цепочка наследования уже является порядком разрешения методов. Это делает методы немного более эффективными.

В Java 8 появились методы по умолчанию, похожие на трейты. Однако правила разрешения методов Java делают интерфейсы с методами по умолчанию гораздо менее функциональными, чем трейты. Тем не менее, это шаг в направлении адаптации современных решений проблемы множественного наследования.

В большинстве схем разрешения методов множественного наследования порядок суперклассов имеет значение. То есть между class D extends B, C и class D extends C, B есть разница. Поскольку порядок можно использовать для простого устранения неоднозначности, пример с тремя классами недостаточно демонстрирует проблемы, связанные с множественным наследованием. Для этого вам понадобится полная задача о бриллиантах с четырьмя классами, так как она показывает, как наивный поиск в глубину приводит к неинтуитивному порядку разрешения методов.

Проблема алмаза, о которой вы говорите, является одной из причин (и очень хорошей) не поддерживать множественное наследование. Есть и другие причины, о которых вы можете почитать немного. здесь.

Многие причины сводятся к сложности (это довольно сложно сделать правильно), относительно редкой законной необходимости использовать его и всевозможным другим проблемам с диспетчеризацией (кроме только проблемы с бриллиантом), которые он создает.