Qual è il problema esatto con l'ereditarietà multipla?

Vedo persone che chiedono continuamente se l'ereditarietà multipla debba essere inclusa nella prossima versione di C # o Java. La gente del C ++, che ha la fortuna di avere questa capacità, dice che è come dare a qualcuno una corda per impiccarsi.

Qual è il problema con l'ereditarietà multipla? Ci sono campioni di cemento?

Il problema più ovvio è con l'override della funzione.

Supponiamo di avere due classi Ae B, entrambe definiscono un metodo doSomething. Ora definisci una terza classe C, che eredita da Ae B, ma non sovrascrivi il doSomethingmetodo.

Quando il compilatore esegue il seed di questo codice ...

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

... quale implementazione del metodo dovrebbe utilizzare? Senza ulteriori chiarimenti, è impossibile per il compilatore risolvere l'ambiguità.

Oltre all'override, l'altro grosso problema con l'ereditarietà multipla è il layout degli oggetti fisici in memoria.

Linguaggi come C ++ e Java e C # creano un layout basato su indirizzi fissi per ogni tipo di oggetto. Qualcosa come questo:

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

Quando il compilatore genera codice macchina (o bytecode), utilizza quegli offset numerici per accedere a ciascun metodo o campo.

L'ereditarietà multipla lo rende molto complicato.

Se la classe Ceredita da Ae B, il compilatore deve decidere se disporre i dati in ABordine o in BAordine.

Ma ora immagina di chiamare metodi su un Boggetto. È davvero solo un B? O è effettivamente un Coggetto chiamato polimorficamente, attraverso la sua Binterfaccia? A seconda dell'identità effettiva dell'oggetto, il layout fisico sarà diverso ed è impossibile conoscere l'offset della funzione da richiamare nel sito di chiamata.

Il modo per gestire questo tipo di sistema è abbandonare l'approccio del layout fisso, consentendo a ogni oggetto di essere interrogato per il suo layout prima di tentare di invocare le funzioni o accedere ai suoi campi.

Quindi ... per farla breve ... è una seccatura per gli autori di compilatori supportare l'ereditarietà multipla. Quindi, quando qualcuno come Guido van Rossum progetta python, o quando Anders Hejlsberg progetta c #, sa che supportare l'ereditarietà multipla renderà le implementazioni del compilatore significativamente più complesse e presumibilmente non pensano che il vantaggio valga il costo.

I problemi che menzionate non sono poi così difficili da risolvere. In effetti, ad esempio, Eiffel lo fa perfettamente! (e senza introdurre scelte arbitrarie o altro)

Ad esempio, se erediti da A e B, entrambi con metodo foo (), allora ovviamente non vuoi che una scelta arbitraria nella tua classe C erediti sia da A che da B. Devi ridefinire foo in modo che sia chiaro cosa sarà usato se si chiama c.foo () o altrimenti bisogna rinominare uno dei metodi in C. (potrebbe diventare bar ())

Inoltre penso che l'ereditarietà multipla sia spesso molto utile. Se guardi le librerie di Eiffel vedrai che è usato ovunque e personalmente ho perso la funzione quando sono dovuto tornare alla programmazione in Java.

Il problema del diamante :

un'ambiguità che sorge quando due classi B e C ereditano da A e la classe D eredita sia da B che da C.Se c'è un metodo in A che B e C hanno sovrascritto e D non lo sovrascrive, allora quale versione del metodo eredita D: quello di B o quello di C?

... Si chiama "problema del diamante" a causa della forma del diagramma di ereditarietà delle classi in questa situazione. In questo caso, la classe A è in alto, sia B che C separatamente sotto di essa, e D unisce i due insieme in basso per formare una forma di diamante ...

L'ereditarietà multipla è una di quelle cose che non viene utilizzata spesso e può essere utilizzata in modo improprio, ma a volte è necessaria.

Non ho mai capito di non aggiungere una funzionalità, solo perché potrebbe essere utilizzata in modo improprio, quando non ci sono buone alternative. Le interfacce non sono un'alternativa all'ereditarietà multipla. Per prima cosa, non ti consentono di applicare precondizioni o postcondizioni. Proprio come qualsiasi altro strumento, devi sapere quando è appropriato usarlo e come usarlo.

diciamo che hai oggetti A e B che sono entrambi ereditati da C. A e B entrambi implementano foo () e C no. Chiamo C.foo (). Quale implementazione viene scelta? Ci sono altri problemi, ma questo tipo di cose è importante.

Il problema principale con l'ereditarietà multipla è ben riassunto con l'esempio di tloach. Quando si eredita da più classi base che implementano la stessa funzione o campo, è il compilatore a dover prendere una decisione su quale implementazione ereditare.

La situazione peggiora quando erediti da più classi che ereditano dalla stessa classe di base. (eredità del diamante, se disegni l'albero dell'eredità ottieni una forma a diamante)

Questi problemi non sono realmente problematici da superare per un compilatore. Ma le scelte che il compilatore deve fare qui sono piuttosto arbitrarie, questo rende il codice molto meno intuitivo.

Trovo che quando eseguo un buon design OO non ho mai bisogno di eredità multipla. Nei casi in cui ne ho bisogno, di solito trovo che sto usando l'ereditarietà per riutilizzare la funzionalità mentre l'ereditarietà è appropriata solo per le relazioni "è-a".

Esistono altre tecniche come i mixin che risolvono gli stessi problemi e non hanno i problemi che ha l'ereditarietà multipla.

Non credo che il problema del diamante sia un problema, considererei quel sofisma, nient'altro.

Il problema peggiore, dal mio punto di vista, con l'ereditarietà multipla è RAD - vittime e persone che affermano di essere sviluppatori ma in realtà sono bloccate con una mezza conoscenza (nella migliore delle ipotesi).

Personalmente, sarei molto felice se potessi finalmente fare qualcosa in Windows Forms come questo (non è il codice corretto, ma dovrebbe darti l'idea):

public sealed class CustomerEditView : Form, MVCView<Customer>

Questo è il problema principale che ho con l'assenza di eredità multipla. PUOI fare qualcosa di simile con le interfacce, ma c'è quello che io chiamo "s *** code", è questo doloroso ripetitivo c *** che devi scrivere in ciascuna delle tue classi per ottenere un contesto dati, per esempio.

A mio parere, non dovrebbe esserci assolutamente alcuna necessità, nemmeno la minima, di NESSUNA ripetizione di codice in un linguaggio moderno.

Il Common Lisp Object System (CLOS) è un altro esempio di qualcosa che supporta MI evitando i problemi in stile C ++: all'ereditarietà viene dato un valore predefinito ragionevole , pur consentendo la libertà di decidere esplicitamente come esattamente, ad esempio, chiamare il comportamento di un super .

Non c'è niente di sbagliato nell'ereditarietà multipla stessa. Il problema è aggiungere l'ereditarietà multipla a una lingua che non è stata progettata pensando all'ereditarietà multipla sin dall'inizio.

Il linguaggio Eiffel supporta l'ereditarietà multipla senza restrizioni in un modo molto efficiente e produttivo, ma il linguaggio è stato progettato sin dall'inizio per supportarlo.

Questa funzionalità è complessa da implementare per gli sviluppatori di compilatori, ma sembra che tale inconveniente possa essere compensato dal fatto che un buon supporto per l'ereditarietà multipla potrebbe evitare il supporto di altre funzionalità (cioè nessuna necessità di interfaccia o metodo di estensione).

Penso che supportare l'ereditarietà multipla o meno sia più una questione di scelta, una questione di priorità. Una funzionalità più complessa richiede più tempo per essere implementata correttamente e operativa e potrebbe essere più controversa. L'implementazione C ++ potrebbe essere il motivo per cui l'ereditarietà multipla non è stata implementata in C # e Java ...

Uno degli obiettivi di progettazione di framework come Java e .NET è di consentire al codice compilato di funzionare con una versione di una libreria precompilata, di funzionare altrettanto bene con le versioni successive di quella libreria, anche se quelle versioni successive aggiungere nuove funzionalità. Mentre il paradigma normale in linguaggi come C o C ++ è quello di distribuire eseguibili collegati staticamente che contengono tutte le librerie di cui hanno bisogno, il paradigma in .NET e Java è quello di distribuire le applicazioni come raccolte di componenti che sono "collegati" in fase di esecuzione .

Il modello COM che ha preceduto .NET ha tentato di utilizzare questo approccio generale, ma in realtà non aveva ereditarietà - invece, ogni definizione di classe definisce efficacemente sia una classe che un'interfaccia con lo stesso nome che conteneva tutti i suoi membri pubblici. Le istanze erano del tipo di classe, mentre i riferimenti erano del tipo di interfaccia. Dichiarare una classe come derivante da un'altra equivaleva a dichiarare una classe come implementazione dell'interfaccia dell'altra e richiedeva che la nuova classe reimplementasse tutti i membri pubblici delle classi da cui una derivava. Se Y e Z derivano da X, e quindi W deriva da Y e Z, non importa se Y e Z implementano i membri di X in modo diverso, perché Z non sarà in grado di usare le loro implementazioni - dovrà definirne proprio. W potrebbe incapsulare istanze di Y e / o Z,

La difficoltà in Java e .NET è che il codice può ereditare i membri e gli accessi ad essi si riferiscono implicitamente ai membri principali. Supponiamo che uno avesse classi WZ correlate come sopra:

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();
  }
}

Sembrerebbe che la W.Test()creazione di un'istanza di W richiami l'implementazione del metodo virtuale Foodefinito in X. Supponiamo, tuttavia, che Y e Z fossero effettivamente in un modulo compilato separatamente, e sebbene fossero definiti come sopra quando X e W sono stati compilati, sono stati successivamente modificati e ricompilati:

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

Ora quale dovrebbe essere l'effetto della chiamata W.Test()? Se il programma dovesse essere collegato staticamente prima della distribuzione, la fase di collegamento statico potrebbe essere in grado di discernere che mentre il programma non aveva ambiguità prima che Y e Z venissero modificati, le modifiche a Y e Z hanno reso le cose ambigue e il linker potrebbe rifiutarsi di farlo costruire il programma a meno che o fino a quando tale ambiguità non viene risolta. D'altra parte, è possibile che la persona che ha sia W che le nuove versioni di Y e Z sia qualcuno che vuole semplicemente eseguire il programma e non ha codice sorgente per nessuno di essi. Quando W.Test()viene eseguito, non sarebbe più chiaro cosaW.Test() dovrebbe funzionare, ma fino a quando l'utente non avesse provato a eseguire W con la nuova versione di Y e Z non ci sarebbe stato alcun modo in cui nessuna parte del sistema potesse riconoscere che c'era un problema (a meno che W non fosse considerato illegittimo anche prima delle modifiche a Y e Z) .

Il diamante non è un problema, a patto che non usi nulla come l'ereditarietà virtuale C ++: nell'ereditarietà normale ogni classe base assomiglia a un campo membro (in realtà sono disposte nella RAM in questo modo), dandoti un po 'di zucchero sintattico e un capacità aggiuntiva di sovrascrivere metodi più virtuali. Ciò può imporre alcune ambiguità in fase di compilazione, ma di solito è facile da risolvere.

D'altra parte, con l'eredità virtuale va troppo facilmente fuori controllo (e poi diventa un pasticcio). Considera come esempio un diagramma a "cuore":

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

In C ++ è del tutto impossibile: non appena Fe Gvengono fusi in una singola classe, anche le loro Avengono unite, punto. Ciò significa che potresti non considerare mai le classi base opache in C ++ (in questo esempio devi costruire Ain Hmodo da sapere che è presente da qualche parte nella gerarchia). In altre lingue potrebbe funzionare, tuttavia; per esempio, Fe Gpotrebbe dichiarare esplicitamente A come "interna", impedendo così la conseguente fusione e rendendosi effettivamente solidi.

Un altro esempio interessante ( non specifico per C ++):

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

Qui Butilizza solo l'ereditarietà virtuale. Quindi Econtiene due messaggi Bche condividono lo stesso A. In questo modo, puoi ottenere un A*puntatore che punta a E, ma non puoi lanciarlo a un B*puntatore sebbene l'oggetto sia effettivamente B come tale il cast è ambiguo e questa ambiguità non può essere rilevata in fase di compilazione (a meno che il compilatore non veda il intero programma). Ecco il codice di prova:

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;
}

Inoltre, l'implementazione può essere molto complessa (dipende dalla lingua; vedere la risposta di benjismith).