问什么时候以及为什么要封存一个类？

EN

在实现安全功能的类上，这样原始对象就不能被“模拟”。

更广泛地说，我最近与微软的一位人士进行了交流，他告诉我，他们试图将继承限制在真正有意义的地方，因为如果不进行处理，它在性能方面会变得昂贵。

sealed关键字告诉CLR再也没有要查找方法的类了，这就加快了速度。

在当今市场上的大多数性能增强工具中，您会发现一个复选框，它将封存所有未继承的类。

但是要小心，因为如果你想通过MEF发现插件或程序集，你就会遇到问题。

附录

路易斯·考特曼的精彩回答

如果类不是

设计

对于继承，子类可能会中断

类不变量

..。当然，这只适用于创建公共API的情况，但根据我的经验，我会封存任何未显式设计为子类化的类。

在相关注释中，仅适用于未密封的类:创建的任何方法

是一个扩展点，或者至少看起来应该是一个扩展点。声明方法

这也应该是一个有意识的决定。(在C#中，这是一个有意识的决定；在Java语言中则不是。)

然后是这样的：

密封会使单元测试更加困难，因为它禁止more。

一些相关链接：

Edition，第2版

作者: Joshua Bloch。见项目17 (需要Safari订阅)

有效的Java项目17:继承的设计和文档，否则禁止它

(同一项目的讨论)

还要注意的是

Kotlin

默认封存类；

its

关键字与Java相反

或者

C#的

..。(可以肯定的是，

没有普遍的共识认为这是一件好事。

。)

将类标记为

防止篡改可能损害安全性或影响性能的重要类。

很多时候，当我们正在设计一个具有固定行为的实用类时，密封一个类也是有意义的，这是我们不想改变的。

例如，

中的命名空间

提供许多密封的类，例如

..。如果不密封，就有可能扩展它的功能，这可能是不可取的，因为它是具有给定功能的基本类型。

类似地，

在

总是隐式密封的。因此，不能从一个结构/类派生出另一个结构。这样做的理由是

仅用于建模

独立、原子、用户定义

数据类型，我们不想修改这些类型。

有时，当您构建类层次结构时，您可能希望根据您的域模型或业务规则来限制继承链中的某个分支。

例如，一个

和

都是

但是在你的组织中，除了兼职员工之外，你没有任何角色。在这种情况下，您可能希望将

以防止进一步的分支。另一方面，如果您有按小时或每周兼职的员工，则从

..。