密封
注意
此内容根据 Pearson Education, Inc. 许可转载自《框架设计指南：可重用 .NET 库的约定、习语和模式第二版》。 该版本于 2008 年出版，并在此后于第三版对该书进行了全面修订。 此页上的一些信息可能已过时。
面向对象的框架的一项功能是，开发人员可采用框架设计者无法预料的方式对其进行扩展和自定义。 这是可扩展设计的强大之处，也是危险之处。 因此，当你设计框架时，非常重要的一点是在需要时仔细设计以实现扩展性，而在有风险时限制扩展性。
阻止扩展性的强大机制是密封的。 可以密封类或单个成员。 密封一个类可防止用户从该类继承。 密封一个成员可防止用户替代特定成员。
❌ 若没有充分的理由，请勿密封类。
因为想不出扩展性场景而密封类不是一个充分的理由。 框架用户喜欢出于各种非显着性的原因而从类中继承，比如添加便捷成员。 有关用户要从某类型继承的非显着性原因的示例，请参阅非密封类。
密封一个类的充分理由包括：
类是一个静态类。 请参阅静态类设计。
类在继承的受保护成员中存储对安全性敏感的机密。
类继承许多虚拟成员，且单独密封它们的成本将超过使该类不密封的好处。
类是一个需要非常快速的运行时查找的特性。 密封特性的性能水平略高于非密封特性。 请参阅特性。
❌ 请勿对密封类型声明受保护的成员或虚拟成员。
按照定义，不能从密封类型继承。 这意味着不能调用密封类型的受保护成员，也不能替代密封类型的虚拟方法。
✔️ 请考虑密封你替代的成员。
引入虚拟成员（如虚拟成员中所述）可能导致的问题也同样适用于替代（尽管程度稍低）。 密封替代可以使你从继承层次结构中的这一点开始就避免这些问题。
Portions © 2005, 2009 Microsoft Corporation 版权所有。 保留所有权利。
在 Pearson Education, Inc. 授权下，由 Addison-Wesley Professional 作为 Microsoft Windows 开发系列的一部分再版自 Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition（Framework 设计准则：可重用 .NET 库的约定、惯例和模式第 2 版），由 Krzysztof Cwalina 和 Brad Abrams 发布于 2008 年 10 月 22 日。