2009-08-11 24 views
8

Java non consente l'ereditarietà da più classi (ancora consente l'ereditarietà da più interfacce). So che è molto in linea con il classico problema dei diamanti. Ma le mie domande sono perché java non consente l'ereditarietà multipla come C++ quando non c'è ambiguità (e quindi non c'è possibilità di problemi con i diamanti) mentre si eredita da più classi di base?Ereditarietà multipla in java

+2

Se si desidera mixin (= le parti buone di MI) in un linguaggio jvm, dare un'occhiata a scala. –

+0

In base alla mia esperienza, l'ereditarietà multipla può creare codice molto fragile. L'utilizzo delle interfacce è molto più salutare. Se si desidera riutilizzare la logica di implementazione, utilizzare la delega. I moderni IDE come Eclipse facilitano la delega del lavoro da una classe all'altra. – JohnnySoftware

+0

Per chiunque cerchi un articolo dettagliato su "Mixin", [qui è uno] (http://csis.pace.edu/~bergin/patterns/multipleinheritance.html). Come afferma l'articolo, è necessaria solo 1 interfaccia se le classi non hanno bisogno di servizi l'una dall'altra. In questo caso, leggi la seconda sezione. – MattC

risposta

16

Era un design decision di Java. Non lo capirai mai, quindi non preoccuparti troppo. Sebbene MI possa aiutarti a creare Mixins, questo è l'unico buon MI che ti farà mai.

6

Ho letto che molti programmatori non utilizzano l'ereditarietà multipla in modo corretto. "Basta andare avanti e ereditare da una classe solo per riutilizzare il codice" non è la migliore pratica in caso di ereditarietà multipla.

Molti programmatori non sanno quando utilizzare l'ereditarietà semplice nella maggior parte dei casi. L'ereditarietà multipla deve essere usata con cautela e solo se sai cosa stai facendo se vuoi avere un buon design.

Non credo che la mancanza di ereditarietà multipla in java (come in C++) metterà delle restrizioni nella progettazione del codice/applicazione/mappatura del problema in classi.

0

Una risposta semplice è che tutte le classi in Java derivano da java.lang.Object IIRC. Quindi, si farebbe sempre hanno un problema di diamante ... :-D

+0

Non proprio. Parent> Child> Oggetto. Quindi Parent estende Child, Child estende Object, semplicemente non è scritto esplicitamente in quest'ultimo caso, poiché è implicito automaticamente. –

+0

@Massa: il problema del diamante si verifica quando esistono più implementazioni in più classi di base (da cui viene derivata la classe figlio) dello stesso metodo. Se non stiamo sovrascrivendo i metodi definiti nella classe java.lang.Object, in sostanza non porta all'ambiguità e al problema dei diamanti. –

+0

"Se non si esegue l'override dei metodi definiti in java.lang.Object" Sovrascrivo toString, hashcode ed equivale molto più spesso di quanto voglio ereditarietà multipla –

-1

Il problema si pone quando il diamante più classi genitore definire i propri implementazioni di qualcosa e la classe figlia di questi due deve fare i conti con l'ambiguità di quale implementazione utilizzare. Che cosa succede se tutte le classi in Java derivano da Object, che è una classe monoparentale. "Genitori single, classi derivate multiple" non è la stessa di "Genitori multipli, classe derivata singola"

+0

N. "problema diamante" si riferisce a più classi base che condividono una classe base, non membri con lo stesso nome. – curiousguy

2

Semplicità. Per citare Tom Sintes,

Il team di progettazione di Java è sforzato di rendere Java:

  • Semplice, object oriented, e familiare
  • robusto e sicuro
  • Architettura neutro e portatile
  • ad alte prestazioni
  • Interpretato, filettato e dinamico

Le ragioni per omettere l'ereditarietà multipla dal linguaggio Java derivano principalmente dall'obiettivo "semplice, orientato agli oggetti e familiare". Come un linguaggio semplice, i creatori di Java volevano un linguaggio che la maggior parte degli sviluppatori di potesse cogliere senza un addestramento approfondito. A tal fine, il loro numero ha lavorato per rendere il linguaggio simile al C++ possibile (familiare) senza portare a termine la complessità inutile del C++ (semplice).

Secondo i progettisti, l'ereditarietà multipla causa più problemi e confusione di quanto non risolva. Così hanno tagliato l'ereditarietà multipla dalla lingua (proprio come hanno ridotto il sovraccarico dell'operatore). L'esperienza estesa del C++ degli designer ha insegnato loro che l'ereditarietà multipla solo non valeva il mal di testa.

1

Progettisti Java hanno deciso che. L'ereditarietà multipla può essere simulata dall'uso di interfacce.

2

se il supporto Java l'ereditarietà multipla allora può effettuare altre caratteristiche di java
considerare super() il metodo che viene utilizzato per chiamare super-programma di classe constructor.if ha più classe di super (a causa di ereditarietà multipla) allora compilatore si confonderà su quale costruttore di super class dovrebbe essere chiamato e lanciare un errore

+0

correggimi se mi sono sbagliato –

0

È vero che Java non ha usato per supportare l'ereditarietà multipla dell'implementazione (solo di tipo ie interfaccia). Questa è stata una decisione di progettazione.

Tuttavia, poiché Java 8, supporta l'ereditarietà multipla utilizzando i metodi predefiniti. Vedere http://docs.oracle.com/javase/tutorial/java/IandI/multipleinheritance.html:

multipla eredità della realizzazione è la possibilità di ereditare definizioni dei metodi di più classi. I problemi sorgono con questo tipo di ereditarietà multipla , come conflitti di nome e ambiguità. ... I metodi predefiniti introducono una forma di ereditarietà multipla dell'implementazione di .

+0

Anche il conflitto di nomi dall'ereditarietà di "interfacce" (classi degenerate) può sorgere. – curiousguy

Problemi correlati