W C # i C ++ / CLI słowo kluczowe sealed(lub NotInheritablew VB) służy do ochrony klasy przed jakąkolwiek szansą na dziedziczenie (klasa nie będzie dziedziczona). Wiem, że jedną z cech programowania obiektowego jest dziedziczenie i czuję, że użycie sealedjest sprzeczne z tą funkcją, zatrzymuje dziedziczenie. Czy istnieje przykład, który pokazuje korzyści sealedi kiedy ważne jest, aby z niego korzystać?
Odpowiedzi:
W klasie, która implementuje funkcje zabezpieczeń, tak że oryginalny obiekt nie może być „podszywany”.
Mówiąc bardziej ogólnie, niedawno wymieniłem się z osobą w firmie Microsoft, która powiedziała mi, że próbowała ograniczyć dziedziczenie do miejsc, w których ma to naprawdę sens, ponieważ nieleczone staje się kosztowne pod względem wydajności.
Sealed słowo kluczowe mówi CLR, że nie ma już klasy, która mogłaby szukać metod, a to przyspiesza działanie.
W większości narzędzi zwiększających wydajność dostępnych obecnie na rynku znajduje się pole wyboru, które zapieczętuje wszystkie klasy, które nie są dziedziczone.
Należy jednak zachować ostrożność, ponieważ jeśli chcesz zezwolić na wykrywanie wtyczek lub zestawu za pośrednictwem MEF, napotkasz problemy.
Dodatek do doskonałej odpowiedzi Baboon :
W związku z tym, ma zastosowanie tylko do niezapieczętowanych klas: każda utworzona metoda virtualjest punktem rozszerzenia lub przynajmniej wygląda na to, że powinna być punktem rozszerzenia. Deklarowanie metod również virtualpowinno być świadomą decyzją. (W C # jest to świadoma decyzja; w Javie tak nie jest).
EDYCJA : Kilka odpowiednich linków:
Należy również zauważyć, że Kotlin domyślnie pieczętuje klasy; jego opensłowo kluczowe jest przeciwieństwem języka Java finallub sealedC # . (Z pewnością nie ma powszechnej zgody, że to dobra rzecz ).
Oznaczenie klasy jako Sealedzapobiega manipulowaniu ważnymi klasami, które mogą zagrozić bezpieczeństwu lub wpłynąć na wydajność.
Często zapieczętowanie klasy ma również sens, gdy projektujemy klasę użytkową o stałym zachowaniu, którego nie chcemy zmieniać.
Na przykład Systemprzestrzeń nazw w C#zawiera wiele klas, które są zapieczętowane, takie jak String. Gdyby nie był zamknięty, możliwe byłoby rozszerzenie jego funkcjonalności, co mogłoby być niepożądane, ponieważ jest to typ podstawowy o danej funkcjonalności.
Podobnie, structuresw C#są zawsze domyślnie zapieczętowane. Dlatego nie można wyprowadzić jednej struktury / klasy z innej struktury. Powodem tego jest to, że structuressą one używane do modelowania tylko samodzielnych, niepodzielnych, zdefiniowanych przez użytkownika typów danych, których nie chcemy modyfikować.
Czasami podczas budowania hierarchii klas możesz chcieć ograniczyć określoną gałąź w łańcuchu dziedziczenia na podstawie modelu domeny lub reguł biznesowych.
Na przykład, a Manageri PartTimeEmployeesą oba Employee, ale nie pełnisz żadnej roli po pracownikach zatrudnionych w niepełnym wymiarze godzin w Twojej organizacji. W takim przypadku możesz chcieć zapieczętować, PartTimeEmployeeaby zapobiec dalszemu rozgałęzianiu. Z drugiej strony, jeśli masz pracowników zatrudnionych w niepełnym wymiarze godzinowym lub tygodniowym, warto odziedziczyć ich po PartTimeEmployee.
unsealJeśli zajdzie taka potrzeba, łatwiej będzie później klasie niż zapieczętować ją i rozbić wszystkie klasy, które od niej zależą.
Myślę, że ten post ma dobry punkt, konkretny przypadek dotyczył próby rzutowania niezamykanej klasy na dowolny przypadkowy interfejs, kompilator nie zgłasza błędu; ale kiedy jest używany Seal, kompilator zgłasza błąd, którego nie może przekonwertować. Klasa Sealed zapewnia dodatkowe zabezpieczenie dostępu do kodu.
https://www.codeproject.com/Articles/239939/Csharp-Tweaks-Why-to-use-the-sealed-keyword-on-cla