Có vẻ như các nguyên tắc chính thức của Microsoft về niêm phong đã phát triển kể từ khi câu hỏi này được hỏi cách đây ~ 9 năm và họ đã chuyển từ triết lý chọn tham gia (đóng dấu theo mặc định) sang chọn không tham gia (không niêm phong theo mặc định):
X KHÔNG niêm phong các lớp học mà không có lý do chính đáng để làm như vậy.
Việc niêm phong một lớp vì bạn không thể nghĩ ra một kịch bản có thể mở rộng không phải là một lý do chính đáng. Người dùng Framework thích kế thừa từ các lớp vì nhiều lý do rõ ràng khác nhau, như thêm các thành viên tiện lợi. Xem Lớp chưa được niêm phong để biết ví dụ về những lý do rõ ràng mà người dùng muốn kế thừa từ một loại.
Những lý do chính đáng để niêm phong một lớp bao gồm những điều sau:
- Lớp là một lớp tĩnh. Xem Thiết kế lớp tĩnh.
- Lớp lưu trữ các bí mật nhạy cảm về bảo mật trong các thành viên được bảo vệ kế thừa.
- Lớp kế thừa nhiều thành viên ảo và chi phí niêm phong chúng riêng lẻ sẽ lớn hơn lợi ích của việc bỏ niêm phong lớp.
- Lớp là một thuộc tính yêu cầu tra cứu thời gian chạy rất nhanh. Thuộc tính được niêm phong có mức hiệu suất cao hơn một chút so với thuộc tính chưa được niêm phong. Xem Các thuộc tính.
X KHÔNG tuyên bố các thành viên được bảo vệ hoặc ảo trên các loại được niêm phong.
Theo định nghĩa, các kiểu niêm phong không thể được kế thừa từ. Điều này có nghĩa là không thể gọi các thành viên được bảo vệ trên các loại được niêm phong và không thể ghi đè các phương thức ảo trên các loại được niêm phong.
✓ XEM XÉT niêm phong các thành viên mà bạn ghi đè. Các vấn đề có thể xảy ra từ việc giới thiệu thành viên ảo (được thảo luận trong Thành viên ảo) cũng áp dụng cho các ghi đè, mặc dù ở mức độ nhẹ hơn một chút. Niêm phong ghi đè bảo vệ bạn khỏi những vấn đề này bắt đầu từ thời điểm đó trong hệ thống phân cấp kế thừa.
Thật vậy, nếu bạn tìm kiếm cơ sở mã ASP.Net Core , bạn sẽ chỉ tìm thấy khoảng 30 lần xuất hiện sealed class, hầu hết là thuộc tính và lớp thử nghiệm.
Tôi nghĩ rằng bảo toàn tính bất biến là một lập luận tốt ủng hộ việc niêm phong.