Perché C # implementa i metodi come non virtuali per impostazione predefinita?

A differenza di Java, perché C # tratta i metodi come funzioni non virtuali per impostazione predefinita? È più probabile che si tratti di un problema di prestazioni piuttosto che di altri possibili risultati?

Mi viene in mente di aver letto un paragrafo di Anders Hejlsberg sui numerosi vantaggi che l'architettura esistente sta portando fuori. Ma per quanto riguarda gli effetti collaterali? È davvero un buon compromesso avere metodi non virtuali per impostazione predefinita?

Le classi dovrebbero essere progettate in modo che l'ereditarietà possa trarne vantaggio. Avere metodi virtualper impostazione predefinita significa che ogni funzione nella classe può essere scollegata e sostituita da un'altra, il che non è davvero una buona cosa. Molte persone credono addirittura che le classi avrebbero dovuto essere sealedpredefinite.

virtuali metodi possono anche avere una leggera implicazione sulle prestazioni. Tuttavia, è improbabile che questo sia il motivo principale.

Sono sorpreso che sembra esserci un tale consenso qui che il non virtuale per impostazione predefinita è il modo giusto di fare le cose. Scenderò dall'altra parte - penso pragmatica - del recinto.

La maggior parte delle giustificazioni mi si legge come il vecchio argomento "Se ti diamo il potere potresti farti del male". Dai programmatori ?!

Mi sembra che il programmatore che non sapeva abbastanza (o ha avuto abbastanza tempo) per progettare la propria libreria per ereditarietà e / o estensibilità sia il programmatore che ha prodotto esattamente la libreria che probabilmente dovrò aggiustare o modificare - esattamente il libreria in cui la possibilità di sovrascrivere sarebbe più utile.

Il numero di volte in cui ho dovuto scrivere codice brutto e disperato (o abbandonare l'uso e lanciare la mia soluzione alternativa) perché non posso scavalcare di gran lunga, supera di gran lunga il numero di volte in cui sono stato morso ( ad esempio in Java) sovrascrivendo dove il progettista potrebbe non aver considerato che avrei potuto.

Non virtuale per impostazione predefinita mi rende la vita più difficile.

AGGIORNAMENTO: È stato sottolineato [abbastanza correttamente] che in realtà non ho risposto alla domanda. Quindi, e scusandomi per il ritardo ...

Volevo essere in grado di scrivere qualcosa di conciso come "C # implementa metodi come non virtuali per impostazione predefinita perché è stata presa una decisione sbagliata che apprezzava i programmi più dei programmatori". (Penso che potrebbe essere in qualche modo giustificato in base ad alcune delle altre risposte a questa domanda, come le prestazioni (ottimizzazione prematura, chiunque?) O la garanzia del comportamento delle classi.)

Tuttavia, mi rendo conto che sto solo affermando la mia opinione e non quella risposta definitiva che Stack Overflow desidera. Sicuramente, ho pensato, al livello più alto la risposta definitiva (ma inutile) è:

Per impostazione predefinita, non sono virtuali perché i progettisti del linguaggio avevano una decisione da prendere ed è quello che hanno scelto.

Ora immagino che il motivo esatto per cui hanno preso quella decisione non lo faremo mai ... oh, aspetta! La trascrizione di una conversazione!

Quindi sembrerebbe che le risposte e i commenti qui sui pericoli dell'override delle API e sulla necessità di progettare esplicitamente per l'ereditarietà siano sulla strada giusta, ma mancano tutti di un importante aspetto temporale: la preoccupazione principale di Anders era mantenere l'implicito di una classe o API contratto tra le versioni . E penso che in realtà sia più preoccupato di consentire alla piattaforma .Net / C # di cambiare sotto il codice piuttosto che preoccuparsi della modifica del codice utente sulla piattaforma. (E il suo punto di vista "pragmatico" è l'esatto opposto del mio perché guarda dall'altra parte.)

(Ma non potevano semplicemente aver scelto virtual-by-default e poi pepato "finale" attraverso il codice base? Forse non è proprio la stessa cosa .. e Anders è chiaramente più intelligente di me, quindi lascerò mentire.)

Perché è troppo facile dimenticare che un metodo può essere sovrascritto e non progettato per questo. C # ti fa pensare prima di renderlo virtuale. Penso che questa sia un'ottima decisione di design. Alcune persone (come Jon Skeet) hanno persino affermato che le classi dovrebbero essere sigillate per impostazione predefinita.

Per riassumere ciò che hanno detto gli altri, ci sono alcuni motivi:

1- In C #, ci sono molte cose nella sintassi e nella semantica che provengono direttamente da C ++. Il fatto che i metodi non fossero virtuali per impostazione predefinita in C ++ ha influenzato C #.

2- Avere ogni metodo virtuale per impostazione predefinita è un problema di prestazioni perché ogni chiamata di metodo deve utilizzare la tabella virtuale dell'oggetto. Inoltre, questo limita fortemente la capacità del compilatore Just-In-Time di incorporare metodi ed eseguire altri tipi di ottimizzazione.

3- Ancora più importante, se i metodi non sono virtuali per impostazione predefinita, puoi garantire il comportamento delle tue classi. Quando sono virtuali per impostazione predefinita, come in Java, non puoi nemmeno garantire che un semplice metodo getter funzioni come previsto perché potrebbe essere sovrascritto per fare qualsiasi cosa in una classe derivata (ovviamente puoi, e dovresti, fare il metodo e / o la classe finale).

Ci si potrebbe chiedere, come ha detto Zifre, perché il linguaggio C # non sia andato oltre e abbia reso le classi sigillate per impostazione predefinita. Questo fa parte dell'intero dibattito sui problemi dell'ereditarietà dell'implementazione, che è un argomento molto interessante.

C # è influenzato da C ++ (e altro). C ++ non abilita l'invio dinamico (funzioni virtuali) per impostazione predefinita. Un argomento (valido?) Per questo è la domanda: "Con che frequenza implementate classi che sono membri di una classe hiearchy?". Un altro motivo per evitare di abilitare l'invio dinamico per impostazione predefinita è l'impronta di memoria. Una classe senza un puntatore virtuale (vpointer) che punta a un file tabella virtuale , è ovviamente più piccola della classe corrispondente con l'associazione tardiva abilitata.

Non è così facile dire "sì" o "no" al problema delle prestazioni. La ragione di ciò è la compilazione Just In Time (JIT) che è un'ottimizzazione del tempo di esecuzione in C #.

Un'altra domanda simile sulla " velocità delle chiamate virtuali .. "

Il semplice motivo è il costo di progettazione e manutenzione oltre ai costi di prestazione. Un metodo virtuale ha un costo aggiuntivo rispetto a un metodo non virtuale perché il progettista della classe deve pianificare ciò che accade quando il metodo viene sovrascritto da un'altra classe. Ciò ha un grande impatto se ti aspetti che un particolare metodo aggiorni lo stato interno o abbia un comportamento particolare. Ora devi pianificare cosa succede quando una classe derivata cambia quel comportamento. È molto più difficile scrivere codice affidabile in quella situazione.

Con un metodo non virtuale hai il controllo totale. Tutto ciò che va storto è colpa dell'autore originale. Il codice è molto più facile da ragionare.

Se tutti i metodi C # fossero virtuali, vtbl sarebbe molto più grande.

Gli oggetti C # hanno metodi virtuali solo se la classe dispone di metodi virtuali definiti. È vero che tutti gli oggetti hanno informazioni sul tipo che includono un equivalente vtbl, ma se non vengono definiti metodi virtuali, saranno presenti solo i metodi Object di base.

@ Tom Hawtin: Probabilmente è più accurato dire che C ++, C # e Java appartengono tutti alla famiglia di linguaggi C :)

Provenendo da uno sfondo Perl, penso che C # abbia sigillato il destino di ogni sviluppatore che avrebbe potuto voler estendere e modificare il comportamento di una classe base attraverso un metodo non virtuale senza costringere tutti gli utenti della nuova classe a essere consapevoli di potenzialmente dietro le quinte dettagli.

Considera il metodo Add della classe List. Cosa succede se uno sviluppatore desidera aggiornare uno dei numerosi potenziali database ogni volta che viene "aggiunto" un determinato elenco? Se "Add" fosse stato virtuale per impostazione predefinita, lo sviluppatore potrebbe sviluppare una classe "BackedList" che sovrascrisse il metodo "Add" senza forzare tutto il codice client a sapere che era un "BackedList" invece di un normale "List". Per tutti gli scopi pratici, "BackedList" può essere visto come un altro "List" dal codice client.

Ciò ha senso dal punto di vista di una grande classe principale che potrebbe fornire accesso a uno o più componenti di elenco che a loro volta sono supportati da uno o più schemi in un database. Dato che i metodi C # non sono virtuali per impostazione predefinita, l'elenco fornito dalla classe principale non può essere un semplice IEnumerable o ICollection o anche un'istanza di List, ma deve invece essere annunciato al client come "BackedList" per garantire che la nuova versione dell'operazione "Aggiungi" viene chiamata per aggiornare lo schema corretto.

Non è certamente un problema di prestazioni. L'interprete Java di Sun utilizza lo stesso codice per l'invio ( invokevirtualbytecode) e HotSpot genera esattamente lo stesso codice, indipendentemente dal fatto che lo stesso final. Credo che tutti gli oggetti C # (ma non le strutture) abbiano metodi virtuali, quindi avrai sempre bisogno divtbl dell'identificazione della classe / runtime. C # è un dialetto di "linguaggi simili a Java". Suggerire che provenga da C ++ non è del tutto onesto.

C'è l'idea che dovresti "progettare per l'eredità o altrimenti proibirla". Il che suona come un'ottima idea fino al momento in cui hai un caso aziendale serio da mettere in una soluzione rapida. Forse ereditando da codice che non controlli.