Perché sigillare una classe?

Mi piacerebbe sapere qual è la motivazione dietro la maggior parte delle classi sigillate nel framework .Net. Qual è il vantaggio di suggellare una classe? Non riesco a capire come non consentire l'eredità possa essere utile e molto probabilmente non l'unico a combattere queste classi.

Allora, perché il framework è stato progettato in questo modo e non sarebbe un cambiamento radicale aprire tutto? Ci deve essere un'altra ragione, ma solo essere malvagi?

• A volte le classi sono troppo preziose e non progettate per essere ereditate.
• Runtime / Reflection può fare ipotesi di ereditarietà sulle classi sigillate quando si cercano i tipi. Un ottimo esempio di ciò è: si consiglia di sigillare gli attributi per la velocità di runtime della ricerca. type.GetCustomAttributes (typeof (MyAttribute)) funzionerà molto più velocemente se MyAttribute è bloccato.

L'articolo MSDN per questo argomento è Limitare l'estensibilità per classi di sigillatura .

Le classi dovrebbero essere progettate per l'eredità o proibirla. C'è un costo per la progettazione per l'ereditarietà:

• Può definire la tua implementazione (devi dichiarare quali metodi chiameranno quali altri metodi, nel caso in cui un utente sovrascriva uno ma non l'altro)
• Rivela la tua implementazione piuttosto che solo gli effetti
• Significa che devi pensare a più possibilità durante la progettazione
• Cose come Equals sono difficili da progettare in un albero di ereditarietà
• Richiede più documentazione
• Un tipo immutabile che è sottoclasse può diventare mutabile (ick)

L'articolo 17 di Effective Java entra in maggiori dettagli su questo - indipendentemente dal fatto che sia scritto nel contesto di Java, il consiglio si applica anche a .NET.

Personalmente vorrei che le classi fossero sigillate per impostazione predefinita in .NET.

Sembra che le linee guida ufficiali di Microsoft sul sigillo si siano evolute da quando questa domanda è stata posta ~ 9 anni fa, e sono passate da una filosofia di opt-in (sigillo per impostazione predefinita) a opt-out (non sigillo per impostazione predefinita):

X NON sigillare le classi senza avere una buona ragione per farlo.

Sigillare una classe perché non riesci a pensare a uno scenario di estensibilità non è una buona ragione. Agli utenti di Framework piace ereditare dalle classi per vari motivi non ovvi, come l'aggiunta di membri di convenienza. Vedere Classi non sigillate per esempi di motivi non ovvi che gli utenti desiderano ereditare da un tipo.

Buoni motivi per suggellare una classe includono quanto segue:

• La classe è una classe statica. Vedere Static Class Design.
• La classe archivia i segreti sensibili alla sicurezza in membri protetti ereditati.
• La classe eredita molti membri virtuali e il costo di sigillarli individualmente supererebbe i vantaggi di lasciare la classe non sigillata.
• La classe è un attributo che richiede una ricerca di runtime molto veloce. Gli attributi sigillati hanno livelli di prestazioni leggermente superiori rispetto a quelli non sigillati. Vedi Attributi.

X NON dichiarare membri protetti o virtuali sui tipi sealed.

Per definizione, i tipi sealed non possono essere ereditati. Ciò significa che i membri protetti sui tipi sigillati non possono essere chiamati e i metodi virtuali sui tipi sigillati non possono essere sostituiti.

✓ CONSIDERATE i membri di suggellamento che ignorate. I problemi che possono derivare dall'introduzione di membri virtuali (discussi in Membri virtuali) si applicano anche alle sostituzioni, sebbene in misura leggermente inferiore. Sigillare un override ti protegge da questi problemi a partire da quel punto nella gerarchia di ereditarietà.

In effetti, se si cerca nella base di codice ASP.Net Core , si trovano solo circa 30 occorrenze sealed class, la maggior parte delle quali sono attributi e classi di test.

Penso che la conservazione dell'immutabilità sia un buon argomento a favore della sigillatura.

Ho trovato questa frase nella documentazione di msdn: "Le classi Sealed vengono utilizzate principalmente per impedire la derivazione. Poiché non possono mai essere utilizzate come classe base, alcune ottimizzazioni in fase di esecuzione possono rendere la chiamata dei membri della classe Sealed leggermente più veloce."

Non so se la prestazione sia l'unico vantaggio delle classi sigillate e personalmente vorrei conoscere anche altri motivi ...

Le prestazioni sono un fattore importante, ad esempio, la classe stringa in java è finale (<- sealed) e la ragione di ciò è solo la prestazione. Penso che un altro punto importante sia evitare il fragile problema della classe base descritto in dettaglio qui: http://blogs.msdn.com/ericlippert/archive/2004/01/07/virtual-methods-and-brittle-base-classes. aspx

Se fornisci un framework, è importante per i progetti legacy di manutenibilità e per aggiornare il tuo framework per evitare il fragile problema della classe base

Sealed viene utilizzato per prevenire il "problema della fragile classe base". Ho trovato un buon articolo in MSDN che lo spiega.

La sigillatura consente di realizzare alcuni piccoli miglioramenti delle prestazioni. Questo è meno vero nel mondo dei JIT e della pessimizzazione pigra che nel mondo, diciamo C ++, ma poiché .NET non è buono come la pessimazione come i compilatori java lo sono principalmente a causa di diverse filosofie di progettazione, è ancora utile. Indica al compilatore che può chiamare direttamente qualsiasi metodo virtuale piuttosto che chiamarli indirettamente tramite vtable.

È anche importante quando si desidera un "mondo chiuso" per cose come il confronto dell'uguaglianza. Normalmente, una volta definito un metodo virtuale, sono praticamente indifferente a definire una nozione di confronto di uguaglianza che implementa davvero l'idea. D'altra parte, potrei essere in grado di definirlo per una particolare sottoclasse della classe con il metodo virtuale. Sigillare quella classe assicura che l'uguaglianza regga davvero.

Sigillare una classe semplifica la gestione delle risorse usa e getta.

Per determinare se sigillare una classe, un metodo o una proprietà, dovresti generalmente considerare i seguenti due punti:

• I potenziali benefici che le classi derivate potrebbero ottenere dalla possibilità di personalizzare la propria classe.

• La possibilità che le classi derivate possano modificare le classi in modo tale che non funzionino più correttamente o come previsto.

Un'ulteriore considerazione è che le classi sigillate non possono essere bloccate nei test unitari. Dalla documentazione di Microsoft :

Le classi sigillate oi metodi statici non possono essere sottoposti a stub perché i tipi di stub si basano sull'invio di metodi virtuali. In questi casi, utilizzare i tipi di shim come descritto in Utilizzo di shim per isolare l'applicazione da altri assembly per i test unitari