sealed
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.
Una delle funzionalità dei framework orientati agli oggetti è che gli sviluppatori possono estenderli e personalizzarli in modi imprevisti dalle finestre di progettazione del framework. Questo è sia il potere che il pericolo della progettazione estendibile. Quando si progetta il framework, è quindi molto importante progettare attentamente per l'estendibilità quando lo si desidera e limitare l'estendibilità quando è pericoloso.
Un meccanismo potente che impedisce l'estendibilità è il blocco (sealing). È possibile bloccare la classe o i singoli membri. Il blocco di una classe impedisce agli utenti di ereditare dalla classe. Il blocco di un membro impedisce agli utenti di eseguire l'override di un determinato membro.
❌ NON bloccare le classi senza avere un buon motivo per farlo.
Bloccare una classe perché non si può pensare a uno scenario di estendibilità non è un buon motivo. Gli utenti del framework amano ereditare da classi per diversi motivi non ovvi, ad esempio l'aggiunta di membri pratici. Vedere Classi unsealed per esempi di motivi non ovvi per cui gli utenti vogliono ereditare da un tipo.
I motivi validi per il blocco di una classe includono quanto segue:
La classe è una classe statica. Vedere Progettazione di classi statiche.
La classe archivia i segreti sensibili alla sicurezza in membri protetti ereditati.
La classe eredita molti membri virtuali e il costo di bloccarli singolarmente avrebbe superato i vantaggi di lasciare la classe unsealed.
La classe è un attributo che richiede una ricerca in fase di esecuzione molto veloce. Gli attributi sealed hanno livelli di prestazioni leggermente superiori rispetto a quelli unsealed. Vedere Attributi.
❌ NON dichiarare membri protetti o virtuali in tipi sealed.
Per definizione, i tipi sealed non possono essere ereditati. Ciò significa che non è possibile chiamare membri protetti su tipi sealed e non è possibile eseguire l'override dei metodi virtuali sui tipi sealed.
✔️ CONSIDERARE i membri sealing di cui si esegue l'override.
I problemi che possono derivare dall'introduzione di membri virtuali (descritti in Membri virtuali) si applicano anche agli override, anche se a un livello leggermente inferiore. Il blocco di un override protegge l'utente da questi problemi a partire da quel punto nella gerarchia di ereditarietà.
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.