Po co zamykać zajęcia?

Klasy powinny być albo przeznaczone do dziedziczenia, albo zabronić tego. Istnieje koszt zaprojektowania dziedziczenia:

• może przypiąć Twoją implementację (musisz zadeklarować, które metody będą wywoływać inne metody, w przypadku, gdy użytkownik nadpisuje jedną, ale nie drugą)
• ujawnia Twoją implementację, a nie tylko efekty
• oznacza to, że musisz myśleć o większych możliwościach przy projektowaniu
• rzeczy takie jak równi są trudne do zaprojektowania w drzewo dziedziczenia
• wymaga większej dokumentacji
• Typ niezmienny, który jest podklasowany może stać się zmienny (ick)

Punkt 17 Effective Java wchodzi w szczegóły na ten temat - niezależnie od tego, że jest napisane w kontekście Javy, porady dotyczą również. NET.

Osobiście chciałbym, aby klasy były domyślnie zamknięte w .NET.

[1]} wydaje się, że oficjalne wytyczne Microsoftu dotyczące uszczelniania ewoluowały od tego pytania zadanego ~9 lat temu i przeszły z filozofii opt-in (domyślnie pieczęć) do opt-out (domyślnie nie pieczęć):

X nie klas pieczęci bez dobrego powodu do tego.

Zamykanie klasy, ponieważ nie można wymyślić scenariusza rozszerzalności to nie jest dobry powód. Użytkownicy frameworków lubią dziedziczyć po klasach dla różne nieoczywiste powody, takie jak dodawanie członków wygody. Zobacz też Niezabezpieczone klasy dla przykładów nieoczywistych powodów, dla których użytkownicy chcą dziedziczenie z rodzaju.

Dobre powody dla uszczelnienia klasy to:

• klasa jest klasą statyczną. Zobacz Statyczne Projektowanie Klas.
• klasa przechowuje poufne sekrety w odziedziczonych chronionych członkach.
• klasa dziedziczy wiele wirtualnych członków i koszt ich zapieczętowania indywidualnie przewyższa korzyści z opuszczenia klasy rozpieczętowane.
• klasa jest atrybutem wymagającym bardzo szybkiego uruchamiania poszukaj. Uszczelnione atrybuty mają nieco wyższy poziom wydajności niż niezabezpieczone. Zobacz Atrybuty.

X nie deklaruje chronionych lub wirtualnych członków na zamkniętych typach.

Z definicji typy zamknięte nie mogą być dziedziczone. Oznacza to, że protected members on sealed types cannot be called, and virtual metody na uszczelnionych typach nie można go przesłonić.

✓ rozważ uszczelnienie członków, które nadpisałeś. Problemy, które mogą wynikać z wprowadzenia wirtualnych członków (omówione w Virtual Members) stosuje się również do przesłonięć, choć w nieco mniejszym stopniu. Uszczelnienie obejścia chroni Cię przed tymi problemami począwszy od tego miejsce w hierarchii spadkowej.

Rzeczywiście, jeśli przeszukać ASP.Net Core codebase , Znajdziesz tylko około 30 wystąpień sealed class, większość które są atrybutami i klasami testowymi.

Znalazłem to zdanie w dokumentacji msdn: "klasy zamknięte są używane przede wszystkim do zapobiegania derywacji. Ponieważ nigdy nie mogą być używane jako klasy bazowe, niektóre optymalizacje czasu pracy mogą sprawić, że wywołanie zamkniętych członków klasy będzie nieco szybsze."

Nie wiem, czy wydajność jest jedyną zaletą klas zamkniętych i osobiście chciałbym też poznać inne powody ...

Wydajność jest ważnym czynnikiem na przykład, klasa string w Javie jest ostateczna (http://blogs.msdn.com/ericlippert/archive/2004/01/07/virtual-methods-and-brittle-base-classes.aspx

Jeśli udostępniasz framework, ważne jest, aby utrzymać starsze projekty i uaktualnić framework, aby uniknąć kruchej bazy problem klas

Sealed jest używany, aby zapobiec "problemowi kruchej klasy bazowej". Znalazłem Dobry artykuł w MSDN, który to wyjaśnia.

Uszczelnienie pozwala na osiągnięcie niewielkich wzrostów wydajności. Jest to mniej prawdziwe w świecie JIT i leniwej pesymizacji niż w świecie, powiedzmy C++, ale ponieważ. NET nie jest tak dobry jak pesymizacja, jak kompilatory Javy są głównie z powodu różnych filozofii projektowania, nadal jest przydatny. Mówi kompilatorowi, że może bezpośrednio wywoływać dowolne metody wirtualne, a nie wywoływać je pośrednio poprzez vtable.

Jest również ważne, gdy chcesz mieć "zamknięty świat" dla takich rzeczy jak porównanie równości. Normalnie, gdy zdefiniuję metodę wirtualną, jestem prawie gotowy do zdefiniowania pojęcia porównania równości, które naprawdę wdraża ideę. Z drugiej strony, mogę być w stanie zdefiniować go dla konkretnej podklasy klasy za pomocą metody wirtualnej. Zapieczętowanie tej klasy zapewnia, że równość naprawdę się trzyma.

Uszczelnienie klasy ułatwia zarządzanie jednorazowymi zasobami.

Aby określić, czy należy uszczelnić klasę, metodę lub właściwość, należy ogólnie wziąć pod uwagę następujące dwa punkty:

* potencjalne korzyści, jakie mogą zyskać klasy wynikające z możliwości dostosowania klasy.

•potencjał, że wyprowadzanie klas może zmodyfikować Twoje klasy w taki sposób, że nie będą już działać poprawnie lub zgodnie z oczekiwaniami.

Kolejną kwestią jest to, że zamknięte klasy nie mogą być używane w testach jednostkowych. Z dokumentacji Microsoftu :

Zamknięte klasy lub statyczne metody nie mogą być stubowane, ponieważ typy stub polegają na wirtualnym wysyłaniu metod. W takich przypadkach użyj typów shim, jak opisano w Using shims, aby odizolować aplikację od innych zespołów do testowania jednostek