注释
此内容由 Pearson Education， Inc. 的许可从 框架设计指南：可重用 .NET 库的约定、习惯和模式（第 2 版）重新打印。 该版于2008年出版，此后该书已于 第三版全面修订。 此页上的一些信息可能已过期。
面向对象的框架的一个功能是，开发人员可以通过框架设计器意外的方式扩展和自定义它们。 这既是可扩展设计的力量和危险。 当您设计框架时，请务必在希望增加灵活性时仔细设计其扩展性，并在扩展性可能带来风险时加以限制。
限制扩展性的强大机制是封装。 可以密封类或单个成员。 将类限定为封闭类可以防止用户继承该类。 密封一个成员可防止用户替代特定成员。
❌ 若没有充分的理由，请勿密封类。
因为想不出扩展性场景而密封类不是一个充分的理由。 框架用户喜欢出于各种非显着性的原因而从类中继承，比如添加便捷成员。 有关用户想要从类型继承的非明显原因的示例，请参阅 未密封的类 。
密封一个类的充分理由包括：
该类是静态类。 请参阅 静态类设计。
类在继承的受保护成员中存储对安全性敏感的机密。
该类继承了许多虚拟成员，而对这些成员逐个进行密封的成本将超过保持该类不密封的好处。
该类是一个需要非常快速的运行时查找的属性。 密封属性的性能级别略高于未密封的属性。 请参阅 属性。
❌ 请勿在密封类型上声明受保护成员或虚拟成员。
根据定义，密封类型不可被继承。 这意味着不能调用密封类型的受保护成员，也不能替代密封类型的虚拟方法。
✔️ 请考虑密封你替代的成员。
引入虚拟成员（如虚拟成员中所述）可能导致的问题也同样适用于替代（尽管程度稍低）。 密封替代可以使你从继承层次结构中的这一点开始就避免这些问题。
部分内容 © 2005, 2009 Microsoft 公司。 保留所有权利。
获得皮尔逊教育公司许可后重印自 框架设计准则：可重用 .NET 库的约定、习惯和模式 ，由 Krzysztof Cwalina 和 Brad Abrams 编写，并作为微软 Windows 开发系列中的出版物之一，于 2008 年 10 月 22 日由 Addison-Wesley Professional 出版。