Здається, що офіційні вказівки Microsoft щодо ущільнення змінилися з часу, коли це питання було задано ~ 9 років тому, і вони перейшли від філософії вибору (печать за замовчуванням) до відмови (за замовчуванням не печать):
X НЕ запечатуйте класи, не маючи для цього поважних причин.
Запечатування класу, оскільки ви не можете подумати про сценарій розширюваності, не є вагомою причиною. Користувачі Framework люблять успадковувати класи з різних не очевидних причин, наприклад, додавання зручних членів. Див. Unseated Classes для прикладів неочевидних причин, які користувачі хочуть успадкувати від типу.
Вагомими причинами запечатування класу є такі:
- Клас - це статичний клас. Див. Дизайн статичного класу.
- Клас зберігає секрети, чутливі до безпеки, у успадкованих захищених членах.
- Клас успадковує багатьох віртуальних членів, і вартість їхнього індивідуального запечатування перевищить переваги залишення класу незапечатаним.
- Клас - це атрибут, який вимагає дуже швидкого пошуку. Запечатані атрибути мають трохи вищий рівень продуктивності, ніж незапечатані. Див. Атрибути.
X НЕ оголошуйте захищені або віртуальні члени на закритих типах.
За визначенням, герметичні типи неможливо успадкувати. Це означає, що захищені елементи на запечатаних типах не можна викликати, а віртуальні методи на запечатаних типах не можна замінити.
✓ ВИМІТІТЕ герметизацію елементів, які ви перевизначаєте. Проблеми, які можуть виникнути внаслідок введення віртуальних членів (обговорюються у "Віртуальних членах"), стосуються і заміщення, хоча і в дещо меншій мірі. Запечатування заміни захищає вас від цих проблем, починаючи з того моменту в ієрархії успадкування.
Дійсно, якщо ви шукаєте в кодовій базі ASP.Net Core , ви знайдете лише близько 30 випадків sealed class, більшість з яких є атрибутами та тестовими класами.
Я вважаю, що збереження незмінності є вагомим аргументом на користь ущільнення.