Membri virtuali
Nota
Questo contenuto viene ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms and Patterns for Reusable .NET Libraries, 2nd Edition. Tale edizione è stata pubblicata nel 2008 e il libro è stato completamente rivisto nella terza edizione. Alcune informazioni in questa pagina potrebbero non essere aggiornate.
I membri virtuali possono essere sottoposti a override, modificando così il comportamento della sottoclasse. Sono molto simili ai callback in termini di estendibilità che forniscono, ma sono migliori in termini di prestazioni di esecuzione e consumo di memoria. Inoltre, i membri virtuali si sentono più naturali negli scenari che richiedono la creazione di un tipo speciale di un tipo esistente (specializzazione).
I membri virtuali offrono prestazioni migliori rispetto ai callback e agli eventi, ma non offrono prestazioni migliori rispetto ai metodi non virtuali.
Lo svantaggio principale dei membri virtuali è che il comportamento di un membro virtuale può essere modificato solo al momento della compilazione. Il comportamento di un callback può essere modificato in fase di esecuzione.
I membri virtuali, ad esempio i callback (e forse più dei callback), sono costosi per progettare, testare e gestire perché qualsiasi chiamata a un membro virtuale può essere sottoposta a override in modi imprevedibili e può eseguire codice arbitrario. Inoltre, molto più sforzo è in genere necessario per definire chiaramente il contratto dei membri virtuali, quindi il costo della progettazione e della documentazione è superiore.
❌ NON rendere virtuali i membri, a meno che non si abbia un buon motivo per farlo e si sia consapevoli di tutti i costi correlati alla progettazione, al test e alla gestione dei membri virtuali.
I membri virtuali sono meno indulgenti in termini di modifiche che vi possono essere apportate senza interrompere la compatibilità. Inoltre, sono più lenti rispetto ai membri non virtuali, principalmente perché le chiamate ai membri virtuali non sono inlined.
✔️ CONSIDERARE la limitazione dell'estendibilità solo a ciò che è assolutamente necessario.
✔️ PREFERIRE l'accessibilità protetta rispetto all'accessibilità pubblica per i membri virtuali. I membri pubblici devono fornire estendibilità (se necessario) chiamando in un membro virtuale protetto.
I membri pubblici di una classe devono fornire il set corretto di funzionalità per i consumer diretti di tale classe. I membri virtuali sono progettati per essere sottoposti a override nelle sottoclassi e l'accessibilità protetta è un ottimo modo per definire l'ambito di tutti i punti di estendibilità virtuale in cui possono essere usati.
Parti protette da copyright © 2005, 2009 Microsoft Corporation. Tutti i diritti sono riservati.
Ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2a edizione di Krzysztof Cwalina and Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional nella collana Microsoft Windows Development Series.