Ho visto alcuni commenti sui forum e sembra che la gente voglia essere in grado di ereditare da più classi in C#. Perché mai avresti bisogno di questo? Non posso pensare a nessun uso per questo, ma dal momento che ci sono persone che lo vogliono, ci deve essere un po '.Che uso di ereditare da più classi?
Bene, ecco un esempio di ASP.NET WebForms:
ho una classe di base, un controllo web, diciamo che è un semplice TextBox.
Quindi eredito dallo TextBox per fornire la formattazione - RichTextBox.
Quindi voglio avere un TextBox che può il controllo ortografico - SpellCheckingTextBox.
Cosa succede se ho bisogno di un SpellCheckingRichTextBox? Dovrei implementare nuovamente il controllo ortografico o la logica Rich Text ed ereditare da uno o dall'altro.
In realtà le definirei come interfacce: ISpellCheckingTextBox e IRichTextBox e implementarle in un SpellCheckingRichTextBox. È anche possibile scrivere i metodi di estensione per TextBox per ottenere la stessa operazione.
L'ereditarietà multipla è fondamentalmente errata perché considera le classi ereditate come uguali. Cosa accadrebbe se entrambe le classi base avessero un campo ID?
Le persone probabilmente vogliono farlo perché sono abituati a farlo in C++. Non è permesso in C#. Quale, IMO, è una buona cosa, dal punto di vista della manutenibilità delle applicazioni. Spesso, utilizzando più interfacce si ottiene la stessa cosa.n
Se si dispone di una classe base con metodi astratti progettati correttamente e si sa che l'oggetto ereditario richiederà solo i metodi definiti in quella classe, si dispone di una valida modello di progettazione che non richiede MI.
Pochissime persone usano effettivamente MI in C++. In realtà, le persone vogliono usare l'MI perché non sanno come farlo nel modo corretto. –
L'ereditarietà multipla è stata talvolta utilizzata in C++ (e in altri linguaggi) per consentire a una classe di ereditare proprietà e codice da più classi di base. Quando si hanno interfacce, come in C# e Java, non c'è davvero bisogno di ereditarietà multipla, quindi non è stato implementato in quelle lingue.
Ecco un buon articolo su l'ereditarietà multipla in Eiffel:
http://archive.eiffel.com/doc/manuals/technology/bmarticles/joop/multiple.html
"Nessuna necessità" è eccessiva: sì, le interfacce fanno la maggior parte di ciò che MI fornisce, ma le mixine forniscono un potente idioma per combinare politiche comportamentali ortogonali.Se questo potere valga i problemi del "diamante della morte" è un altro problema interamente. –
Un caso legittimo per volerlo in C# è creare un oggetto derivato MarshalByRef. Ad esempio, dire che voglio fare quanto segue:
public class FooCorpClass
{
// This class is defined in a 3rd party library and thus can't be changed
}
public class MyFoo : FooCorpClass, MarshalByRef
{
// I can't do this because MarshalByRef isnt' an interface
}
Personalmente lo vedo come un peccato che non si può avere l'ereditarietà multipla, se non ci sono collisioni, o di avere un meccanismo di gestione delle collisioni, ma sono loro la pause.
La maggior parte delle volte se hai bisogno di ereditarietà multipla, il tuo progetto è forse un po 'errato :) –
Nei giorni C++, a volte ne hai avuto bisogno, a causa della mancanza di interfacce –
Vedere [Un uso per eredità multipla?] (http://stackoverflow.com/questions/573913/a-use-for-multiple-inheritance) –