Perché C # non supporta l'ereditarietà multipla?


10

Anche se potrebbe essere una cattiva pratica, direi che c'è tempo per raggiungere il suo scopo.


1
Adoro il modo in cui tutti fanno tutte queste scuse per l'assenza di una capacità totalmente utile in qualsiasi cosa Microsoft produca (gli MVP sono particolarmente abili in questo). La mia ipotesi è che la maggior parte della gente che non capisce i benefici dell'eredità multipla è in primo luogo quella che non capisce (e non usa) l'eredità, perché preferisce il sempre popolare copy-and- incolla il codice 20 volte che vedo in quasi tutti i progetti ovunque. Non c'è dubbio se e quando Microsoft deciderà di implementare l'MI, tutti diventeranno improvvisamente un appassionato entusiasta, senza aspettare un "evangelista", affermando di

1
@DaveZiffer probabilmente, ma sembra difficile da ottenere. Conosci un linguaggio o un'implementazione in cui funziona davvero bene?

4
@Dave O semplicemente sopravvaluti la sua utilità. L'ereditarietà in generale è sopravvalutata e i casi mancanti possono essere facilmente modellati utilizzando interfacce e composizione. L'ereditarietà multipla è davvero inutile in C #. L'unico vantaggio che ha è che ovvia alla necessità di delegare manualmente i metodi di interfaccia all'implementazione nei membri compositi. Ciò avrebbe potuto essere risolto meglio (ad esempio introducendo i mixin) ma non è una buona ragione per introdurre l'ereditarietà multipla.
Konrad Rudolph,

Ho codificato OO in Java per molti anni facendo un uso ragionevole dell'ereditarietà (pesantemente a volte, meno quando ho imparato meglio) e ho trovato esattamente 1 volta in cui era davvero difficile aggirare l'ereditarietà multipla e forse 10 volte dove avrei potuto usarlo per semplificare il mio progetto attuale - e esattamente zero volte in cui non potevo ridisegnarlo per non aver bisogno di ereditarietà multipla e avere il design complessivo migliore di come sarebbe stato con esso.
Bill K,

Risposte:


14

/programming/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c copre bene questa domanda.

La mia opinione è questa: i progettisti probabilmente volevano creare un linguaggio che promuovesse buoni principi di progettazione. Ok, quindi ci sono volte in cui l'ereditarietà multipla è perfetta. Quelle sono l'eccezione, piuttosto che la regola, e possono essere facilmente abusate. Quindi, i progettisti hanno deciso di renderlo impossibile da fare.

Per quei casi in cui andrebbe bene, è necessario utilizzare le interfacce. Funzionano, anche se goffamente; ma non ne avrai bisogno così tanto.


8

Giusto per illustrare perché no, l'ereditarietà multipla è supportata da C ++, ma è fortemente scoraggiata in quanto è possibile eseguire la maggior parte delle cose con una composizione che si farebbe con MI, ma in modo molto più pulito. A differenza di C ++, C # non è un linguaggio OOP di tipo "ibrido", ovvero non si è evoluto da una lingua precedente.

Se hai davvero bisogno di ereditarietà multipla, puoi implementare più interfacce.


6

Walter Bright è sia il creatore di D, che non include MI, sia l'unica persona a scrivere un intero compilatore C ++ da solo. Secondo lui, la ragione per cui D manca di MI è che è troppo difficile creare un sistema di MI che sia contemporaneamente efficiente, semplice e utile. Sospetto che Java e C # utilizzino un ragionamento simile. Lingue come Perl e Python non hanno l'efficienza come obiettivo primario, quindi hanno un sistema semplice e utile, ma difficile da implementare in modo efficiente. Il C ++ non sembra avere come obiettivo la semplicità, quindi ha creato un sistema enormemente complicato che quasi nessuno capisce.

Penso che Walter abbia ragione. Se esiste una lingua che ha un sistema MI che soddisfa ragionevolmente tutti e tre questi criteri, si prega di lasciare un commento.


2
Che cosa pensi di Eiffel, Common Lisp e Dylan? So che tutti e tre sono sia semplici che utili. E so che sia Common Lisp che Dylan possono competere e persino battere C ++ (e spesso anche C) in termini di prestazioni, quindi sembra soddisfare l'efficienza. Io non so che l'Eiffel compilatore è terribilmente lento ma so quasi nulla circa le prestazioni del codice compilato che produce.
Jörg W Mittag,


-1

Perché i progettisti del linguaggio apparentemente volevano produrre un C ++ migliore, non un linguaggio migliore in generale. (Quanto successo hanno potuto essere discussi.)

L'ereditarietà multipla in stile C ++ ha alcuni problemi, e quindi le persone che derivano dal C ++ generalmente la omettono (Java, C #, D). Altre lingue, Eiffel e Common Lisp per nominarne due, lo fanno diversamente e non sembrano avere gli stessi problemi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.