У чому полягає конкретна проблема багаторазового успадкування?

Я можу бачити людей, які весь час запитують, чи слід множинне спадкування включати до наступної версії C # або Java. Люди зі С ++, яким пощастило мати таку здатність, кажуть, що це як давати комусь мотузку, щоб врешті повіситися.

У чому справа з багаторазовим успадкуванням? Чи є конкретні зразки?

Найбільш очевидна проблема полягає в переборі функції.

Скажімо, є два класи Aі Bобидва визначають метод doSomething. Тепер ви визначаєте третій клас C, який успадковується від обох Aі B, але ви не перекриваєте doSomethingметод.

Коли компілятор запустить цей код ...

C c = new C();
c.doSomething();

... яку реалізацію методу він повинен використовувати? Без додаткового уточнення компілятор неможливо вирішити двозначність.

Окрім важливої ​​проблеми, інша велика проблема багаторазового успадкування - це розташування фізичних об'єктів у пам'яті.

Такі мови, як C ++ та Java та C #, створюють фіксований адресний макет для кожного типу об’єктів. Щось на зразок цього:

class A:
    at offset 0 ... "abc" ... 4 byte int field
    at offset 4 ... "xyz" ... 8 byte double field
    at offset 12 ... "speak" ... 4 byte function pointer

class B:
    at offset 0 ... "foo" ... 2 byte short field
    at offset 2 ... 2 bytes of alignment padding
    at offset 4 ... "bar" ... 4 byte array pointer
    at offset 8 ... "baz" ... 4 byte function pointer

Коли компілятор генерує машинний код (або байт-код), він використовує ці числові зсуви для доступу до кожного методу чи поля.

Багаторазове успадкування робить це дуже хитро.

Якщо клас Cуспадковує і те, Aі ін. B, Компілятор повинен вирішити, розміщувати дані в ABпорядку чи BAпорядку.

Але тепер уявіть, що ви викликаєте методи на Bоб’єкт. Це справді просто B? Або насправді Cоб'єкт називається поліморфно через його Bінтерфейс? Залежно від фактичної ідентичності об'єкта, фізичне розташування буде різним, і неможливо дізнатися про зміщення функції для виклику на сайті виклику.

Спосіб поводження з такою системою полягає у вириванні підходу з фіксованим компонуванням, що дозволяє кожному об'єкту запитувати його макет перед тим, як спробувати викликати функції або отримати доступ до його полів.

Отже ... короткий короткий сюжет ... це біль у шиї для авторів-компіляторів, які підтримують багатократне успадкування. Тож, коли хтось, як Гідо ван Россум, розробляє пітон, або коли Андерс Хейльсберг розробляє c #, вони знають, що підтримка багаторазового успадкування зробить реалізацію компілятора значно складнішою, і, мабуть, вони не вважають, що користь вартує витрат.

Проблеми, про які ви згадуєте, хлопці, насправді не так важко вирішити. Насправді, наприклад, Ейфель робить це абсолютно добре! (і не вводячи довільного вибору чи іншого)

Наприклад, якщо ви успадковуєте від A і B, обидва мають метод foo (), то, звичайно, ви не хочете, щоб довільний вибір у вашому класі C успадкував і від A і B. Ви повинні або переосмислити foo, щоб було зрозуміло, що буде використовується, якщо викликається c.foo () або потрібно іншим способом перейменувати один із методів у C. (він може стати бар ())

Також я думаю, що багаторазове успадкування часто буває досить корисним. Якщо ви подивитеся на бібліотеки Ейфеля, то побачите, що він використовується повсюдно, і особисто я пропустив цю функцію, коли мені довелося повернутися до програмування на Java.

Проблема з алмазами :

неоднозначність, яка виникає, коли два класи B і C успадковують від A, а клас D успадковує і B, і C. Якщо є метод A, що B і C мають перекрили , і D не переосмислює його, то яка версія метод успадковує D: B, чи C?

... Його називають "алмазною проблемою" через форму діаграми успадкування класу в цій ситуації. У цьому випадку клас A знаходиться у верхній частині, і B, і окремо під ним, і D з'єднується двома разом у нижній частині, утворюючи форму ромба ...

Багатократне успадкування - одна з тих речей, яка використовується не часто, і її можна неправильно використовувати, але іноді потрібна.

Я ніколи не розумів, що не додавати функцію, просто тому, що вона може бути неправильно використана, коли немає хороших альтернатив. Інтерфейси не є альтернативою багатократному успадкуванню. Для одного вони не дозволяють виконувати передумови чи постумови. Як і будь-який інший інструмент, ви повинні знати, коли його доречно використовувати, і як ним користуватися.

скажімо, у вас є об'єкти A і B, які успадковуються C. A і B обидва реалізують foo (), а C - ні. Я називаю C.foo (). Яка реалізація буде обрана? Є й інші питання, але цей тип речей - великий.

Основна проблема багаторазового успадкування добре підсумована на прикладі tloach. При успадкуванні від декількох базових класів, які реалізують ту саму функцію чи поле, компілятору належить прийняти рішення про те, яку реалізацію слід успадкувати.

Це стає гірше, коли ви успадковуєте з декількох класів, які успадковують від одного базового класу. (успадкування алмазу, якщо ви намалюєте дерево спадщини, ви отримаєте форму алмазу)

Ці проблеми насправді не є проблематичним для подолання компілятора. Але вибір, який тут повинен зробити компілятор, є досить довільним, це робить код набагато менш інтуїтивним.

Я вважаю, що, роблячи хороший дизайн OO, мені ніколи не потрібно багаторазове успадкування. У тих випадках, коли мені це потрібно, я зазвичай вважаю, що я використовую спадщину для повторного використання функціоналу, тоді як успадкування підходить лише для відносин "є-а".

Існують і інші методи, такі як міксин, які вирішують ті самі проблеми і не мають проблем із багаторазовим успадкуванням.

Я не думаю, що проблема з алмазами є проблемою, я вважав би цю софістику, нічого іншого.

Найгірша проблема, з моєї точки зору, з багаторазовим успадкуванням - це жертви RAD і люди, які заявляють, що є розробниками, але насправді застрягли з половинними знаннями (у кращому випадку).

Особисто я був би дуже радий, якби нарешті я міг щось зробити в Windows Forms (це неправильний код, але він повинен дати вам думку):

public sealed class CustomerEditView : Form, MVCView<Customer>

Це головне питання, у якого я не маю багаторазового успадкування. Ви МОЖЕТЕ зробити щось подібне з інтерфейсами, але є те, що я називаю "s *** code", це болісний повторюваний c ***, який ви повинні написати в кожному з своїх класів, щоб отримати, наприклад, контекст даних.

На мою думку, не повинно бути абсолютно ніякої необхідності, не найменшої, у повторенні коду в сучасній мові.

Загальна система об'єктів Lisp (CLOS) - це ще один приклад того, що підтримує MI, уникаючи проблем у стилі C ++: успадковуванню надається розумний дефолт , при цьому все ж ви дозволяєте чітко вирішувати, як саме, скажімо, називати поведінку супер .

Немає нічого поганого в самому багатократному успадкуванні. Проблема полягає в тому, щоб додати кілька успадковань до мови, яка не була створена з урахуванням багатократного успадкування з самого початку.

Ейфелева мова підтримує багатократне успадкування без обмежень дуже ефективним і продуктивним способом, але мова була розроблена з цього початку для її підтримки.

Цю особливість складно реалізувати для розробників-компіляторів, але, схоже, цей недолік можна було б компенсувати тим, що хороша підтримка множинного успадкування може уникнути підтримки інших функцій (тобто не потрібно інтерфейсу чи методу розширення).

Я думаю, що підтримка багаторазового успадкування чи ні - це більше питання вибору, питання пріоритетів. Більш складна функція потребує більше часу для правильної реалізації та експлуатації та може бути більш суперечливою. Реалізація C ++ може бути причиною того, що множинне успадкування не було реалізовано в C # та Java ...

Однією з цілей дизайну рамок, таких як Java та .NET, є можливість коду, який складається, працювати з однією версією попередньо складеної бібліотеки, однаково добре працювати з наступними версіями цієї бібліотеки, навіть якщо ці наступні версії додати нові функції. У той час як звичайна парадигма на таких мовах, як C або C ++, полягає в поширенні статично пов'язаних виконуваних файлів, що містять усі необхідні їм бібліотеки, парадигма в .NET і Java полягає в розповсюдженні програм у вигляді колекцій компонентів, які "пов'язані" під час виконання. .

Модель COM, що передувала .NET, намагалася використовувати цей загальний підхід, але насправді наслідування не мало - натомість кожне визначення класу ефективно визначало як клас, так і інтерфейс з тим же ім'ям, який містив усіх його публічних членів. Екземпляри були типу класу, тоді як посилання були типу інтерфейсу. Оголошено клас таким, що походить від іншого, було рівнозначним оголошенню класу як інтерфейсу іншого та вимагав від нового класу повторної реалізації всіх публічних членів класів, з яких похідний. Якщо Y і Z походять від X, а тоді W походить від Y і Z, не має значення, якщо Y і Z по-різному реалізують члени X, тому що Z не зможе використовувати їх реалізацію - доведеться визначити його власний. W може інкапсулювати екземпляри Y та / або Z,

Складність у Java та .NET полягає в тому, що коду дозволено успадковувати членів і мати доступ до них неявно посилається на батьківські члени. Припустимо, один з класів WZ, як описано вище:

class X { public virtual void Foo() { Console.WriteLine("XFoo"); }
class Y : X {};
class Z : X {};
class W : Y, Z  // Not actually permitted in C#
{
  public static void Test()
  {
    var it = new W();
    it.Foo();
  }
}

Здавалося б, W.Test()слід створити екземпляр W call реалізації віртуального методу, Fooвизначеного в X. Припустимо, однак, що Y і Z насправді були окремо складеним модулем, і хоча вони були визначені як вище, коли компілюються X і W, вони пізніше були змінені і перекомпільовані:

class Y : X { public override void Foo() { Console.WriteLine("YFoo"); }
class Z : X { public override void Foo() { Console.WriteLine("ZFoo"); }

Тепер яким повинен бути ефект дзвінка W.Test()? Якщо програму довелося статично зв’язати перед розповсюдженням, етап статичного зв’язку може виявити, що, хоча програма не мала двозначності перед зміною Y і Z, зміни Y і Z зробили речі неоднозначними, і лінкер міг відмовитись будувати програму, доки не буде вирішена така двозначність. З іншого боку, можливо, що людина, яка має і W, і нові версії Y і Z, - це хтось, хто просто хоче запустити програму і не має вихідного коду для жодної з неї. Коли W.Test()працює, то вже не буде зрозуміло, щоW.Test() слід робити, але поки користувач не спробував запустити W з новою версією Y і Z, жодна частина системи не змогла б визнати, що виникає проблема (якщо тільки W не вважалася нелегітимною ще до зміни Y і Z ).

Діамант не є проблемою, якщо ви не використовуєте нічого подібного до віртуальної спадщини C ++: у звичайному успадкуванні кожен базовий клас нагадує поле члена (насправді вони викладені в оперативній пам'яті таким чином), що дає вам синтаксичний цукор і додаткова можливість перекрити більше віртуальних методів. Це може ввести певну неоднозначність під час компіляції, але це зазвичай легко вирішити.

З іншого боку, з віртуальною спадщиною він занадто легко виходить з-під контролю (і тоді стає безладом). Розглянемо в якості прикладу діаграму «серця»:

  A       A
 / \     / \
B   C   D   E
 \ /     \ /
  F       G
    \   /
      H

У C ++ це абсолютно неможливо: як тільки Fі Gоб'єднаються в єдиний клас, їх As теж об'єднуються, проміжок часу. Це означає , що ви ніколи не розглядати базові класи непрозорих в C ++ (в цьому прикладі ви повинні побудувати Aв Hтак що ви повинні знати , що вона присутня де - то в ієрархії). Однак іншими мовами це може працювати; наприклад, Fі Gможе явно оголосити A як "внутрішній", забороняючи таким чином послідовні злиття і ефективно роблячи себе міцними.

Ще один цікавий приклад ( не специфічний для C ++):

  A
 / \
B   B
|   |
C   D
 \ /
  E

Тут Bвикористовується лише віртуальне успадкування. Так Eміститься два Bs, які поділяють одне і те ж A. Таким чином, ви можете отримати A*покажчик , який вказує на E, але ви не можете кинути його до B*вказівником , хоча об'єкт є на насправді B як такої кидок неоднозначна, і ця невизначеність не може бути виявлена під час компіляції (якщо компілятор не бачить ціла програма). Ось код тесту:

struct A { virtual ~A() {} /* so that the class is polymorphic */ };
struct B: virtual A {};
struct C: B {};
struct D: B {};
struct E: C, D {};

int main() {
        E data;
        E *e = &data;
        A *a = dynamic_cast<A *>(e); // works, A is unambiguous
//      B *b = dynamic_cast<B *>(e); // doesn't compile
        B *b = dynamic_cast<B *>(a); // NULL: B is ambiguous
        std::cout << "E: " << e << std::endl;
        std::cout << "A: " << a << std::endl;
        std::cout << "B: " << b << std::endl;
// the next casts work
        std::cout << "A::C::B: " << dynamic_cast<B *>(dynamic_cast<C *>(e)) << std::endl;
        std::cout << "A::D::B: " << dynamic_cast<B *>(dynamic_cast<D *>(e)) << std::endl;
        std::cout << "A=>C=>B: " << dynamic_cast<B *>(dynamic_cast<C *>(a)) << std::endl;
        std::cout << "A=>D=>B: " << dynamic_cast<B *>(dynamic_cast<D *>(a)) << std::endl;
        return 0;
}

Більше того, реалізація може бути дуже складною (залежить від мови; див. Відповідь Бенджисміта).