Pieczętowanie
Uwaga
Ta zawartość jest drukowana przez uprawnienie Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Wydanie to zostało opublikowane w 2008 roku, a książka została w pełni zmieniona w trzecim wydaniu. Niektóre informacje na tej stronie mogą być nieaktualne.
Jedną z funkcji platform zorientowanych na obiekty jest to, że deweloperzy mogą rozszerzać i dostosowywać je w sposób nieprzewidziany przez projektantów platform. Jest to zarówno moc, jak i niebezpieczeństwo rozszerzalnego projektu. Podczas projektowania struktury bardzo ważne jest więc, aby starannie zaprojektować rozszerzalność, gdy jest to konieczne, i ograniczyć rozszerzalność, gdy jest niebezpieczna.
Zaawansowany mechanizm, który zapobiega rozszerzalności, jest uszczelniony. Można przypieczętować klasę lub poszczególne elementy członkowskie. Uszczelnianie klasy uniemożliwia użytkownikom dziedziczenie z klasy. Uszczelnianie elementu członkowskiego uniemożliwia użytkownikom zastępowanie określonego elementu członkowskiego.
❌ NIE należy uszczelniać klas bez posiadania dobrego powodu, aby to zrobić.
Uszczelnianie klasy, ponieważ nie można myśleć o scenariuszu rozszerzalności nie jest dobrym powodem. Użytkownicy platformy lubią dziedziczyć klasy z różnych nieoczywistych powodów, takich jak dodawanie składowych wygody. Zobacz Niezaużytowane klasy , aby zapoznać się z przykładami nieoczywistych powodów, dla których użytkownicy chcą dziedziczyć po typie.
Dobrymi przyczynami uszczelnienia klasy są następujące:
Klasa jest klasą statyczną. Zobacz Projekt klas statycznych.
Klasa przechowuje poufne wpisy tajne zabezpieczeń w dziedziczonej składowej chronionej.
Klasa dziedziczy wiele wirtualnych elementów członkowskich, a koszt ich uszczelnienia indywidualnie przewyższa korzyści wynikające z pozostawienia klasy niezauważonej.
Klasa jest atrybutem, który wymaga bardzo szybkiego wyszukiwania w czasie wykonywania. Zapieczętowane atrybuty mają nieco wyższe poziomy wydajności niż niezauczętowane. Zobacz Atrybuty.
❌ Nie deklaruj chronionych lub wirtualnych elementów członkowskich w typach zapieczętowanych.
Z definicji nie można dziedziczyć zapieczętowanych typów. Oznacza to, że chronione elementy członkowskie w typach zapieczętowanych nie mogą być wywoływane, a metody wirtualne w typach zapieczętowanych nie mogą być zastępowane.
✔️ ROZWAŻ zastąpienie elementów członkowskich uszczelniających.
Problemy, które mogą wynikać z wprowadzenia wirtualnych elementów członkowskich (omówionych w temacie Wirtualne elementy członkowskie), mają zastosowanie do przesłonięć, chociaż w nieco mniejszym stopniu. Uszczelnianie przesłonięć osłony przed tymi problemami, począwszy od tego punktu w hierarchii dziedziczenia.
© Części 2005, 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.
Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, published oct 22, 2008 by Addison-Wesley Professional w ramach Microsoft Windows Development Series.