In C # e C ++ / CLI la parola chiave sealed(o NotInheritablein VB) viene utilizzata per proteggere una classe da qualsiasi possibilità di ereditarietà (la classe non sarà ereditabile). So che una caratteristica della programmazione orientata agli oggetti è l'ereditarietà e sento che l'uso di sealedva contro questa caratteristica, ferma l'ereditarietà. C'è un esempio che mostra i vantaggi sealede quando è importante utilizzarlo?
Risposte:
Su una classe che implementa funzionalità di sicurezza, in modo che l'oggetto originale non possa essere "impersonato".
Più in generale, ho recentemente scambiato con una persona in Microsoft, che mi ha detto di aver cercato di limitare l'eredità ai luoghi in cui aveva davvero senso, perché diventa costoso dal punto di vista delle prestazioni se non trattata.
La parola chiave sealed dice al CLR che non esiste una classe più in basso per cercare metodi e ciò accelera le cose.
Nella maggior parte degli strumenti per il miglioramento delle prestazioni oggi sul mercato, troverai una casella di controllo che sigillerà tutte le tue classi che non sono ereditate.
Fai attenzione però, perché se vuoi consentire la scoperta di plugin o assembly tramite MEF, incorrerai in problemi.
Un'aggiunta all'eccellente risposta di Baboon :
In una nota correlata, applicabile solo alle classi non sigillate: qualsiasi metodo creato virtualè un punto di estensione, o almeno sembra che dovrebbe essere un punto di estensione. Anche la dichiarazione dei metodi virtualdovrebbe essere una decisione consapevole. (In C # questa è una decisione consapevole; in Java non lo è.)
EDIT : alcuni link rilevanti:
Si noti inoltre che Kotlin sigilla le classi per impostazione predefinita; la sua openparola chiave è l'opposto di Java finalo sealeddi C # . (A dire il vero, non esiste un accordo universale che questa sia una buona cosa .)
Contrassegnare una classe come Sealedimpedisce la manomissione di classi importanti che possono compromettere la sicurezza o influire sulle prestazioni.
Molte volte, sigillare una classe ha senso anche quando si progetta una classe di utilità con un comportamento fisso, che non vogliamo cambiare.
Ad esempio, lo Systemspazio dei nomi in C#fornisce molte classi che sono sigillate, come String. Se non sigillato, sarebbe possibile estenderne le funzionalità, il che potrebbe essere indesiderabile, in quanto è un tipo fondamentale con una determinata funzionalità.
Allo stesso modo, structuresin C#sono sempre implicitamente sigillati. Quindi non si può derivare una struttura / classe da un'altra struttura. Il motivo è che structuresvengono utilizzati per modellare solo tipi di dati autonomi, atomici e definiti dall'utente , che non si desidera modificare.
A volte, quando crei gerarchie di classi, potresti voler limitare un determinato ramo nella catena di ereditarietà, in base al tuo modello di dominio o alle regole aziendali.
Ad esempio, un Managere PartTimeEmployeesono entrambi Employee, ma non hai alcun ruolo dopo i dipendenti part-time nella tua organizzazione. In questo caso, potresti voler sigillare PartTimeEmployeeper evitare ulteriori ramificazioni. D'altra parte, se hai dipendenti part-time orari o settimanali, potrebbe avere senso ereditarli da PartTimeEmployee.
unsealclasse più tardi, se necessario, piuttosto che sigillarlo e rompere tutte le classi che dipendono da esso.
Penso che questo post abbia qualche buon punto, il caso specifico era quando si tentava di eseguire il cast di una classe non sigillata su qualsiasi interfaccia casuale, il compilatore non genera errori; ma quando viene utilizzato sealed, il compilatore genera un errore che non può convertire. La classe Sealed offre una protezione aggiuntiva dall'accesso al codice.
https://www.codeproject.com/Articles/239939/Csharp-Tweaks-Why-to-use-the-sealed-keyword-on-cla