Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Questo contenuto viene ristampato con il permesso di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Pattern per Librerie .NET Riutilizzabili, 2a Edizione. 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 di progettazione estendibile. Quando si progetta il framework, è quindi molto importante progettare attentamente per l'estendibilità quando si desidera e limitare l'estendibilità quando è pericoloso.
Un potente meccanismo che impedisce l'estendibilità è la sigillatura. È possibile bloccare la classe o i singoli membri. La chiusura di una classe impedisce agli utenti di ereditare dalla classe . La chiusura di un membro impedisce agli utenti di eseguire l'override di un determinato membro.
❌ NON sigillare le classi senza avere un buon motivo per farlo.
La chiusura di 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 non sigillate per esempi di motivi non ovvi per cui gli utenti vogliono ereditare da un tipo.
I motivi validi per la chiusura di una classe includono quanto segue:
La classe è una classe statica. Vedere Progettazione di classi statiche.
La classe archivia informazioni sensibili alla sicurezza nei membri protetti ereditati.
La classe eredita molti membri virtuali e il costo di sigillarli singolarmente supererebbe i vantaggi di lasciare la classe non sigillata.
La classe è un attributo che richiede una ricerca in fase di esecuzione molto veloce. Gli attributi sigillati hanno un livello di prestazioni leggermente superiore rispetto a quelli non sigillati. Vedere Attributi.
❌ NON dichiarare membri protetti o virtuali nei tipi sealed.
Per definizione, i tipi sigillati 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.
✔️ Considera di sigillare i membri di cui esegui l'override.
I problemi che possono derivare dall'introduzione di membri virtuali (descritti in Membri virtuali) si applicano anche alle sostituzioni, anche se a un livello leggermente inferiore. La chiusura di un override protegge l'utente da questi problemi a partire da quel punto nella gerarchia di ereditarietà.
© Porzioni 2005, 2009 Microsoft Corporation. Tutti i diritti riservati.
Ristampato dall'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Patterns for Reusable .NET Libraries, 2nd Edition di Krzysztof Cwalina e Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional come parte della Serie di sviluppo di Microsoft Windows.