密封一个class级

密封课程不是我过去常常注意到的事情，但是我发现自己想知道什么是最佳实践。 如果你知道一个课程不会或不应该从中得出你是否会密封它作为预防措施，只需将密封的关键字留下来，知道某人试图从中获取的机会很小。

我想我要问的是，你是否应该密封所有不用于inheritance的类，只是作为一种良好的实践？

Answer 1

你不应该随意密封所有在任何特定时间都没有inheritance的类。

相反，你知道的密封类不应该inheritance而是让其他人保持开放状态。 如果在某个以后的某个时间点，可以决定不inheritance这些类，那么就可以将它们封存起来。

Answer 2

如果您遵循开放/封闭原则，则不应使用sealed关键字。 但我想总有一些案例。

Answer 3

在应用程序代码中，从您的类派生的所有代码都是由您自己控制的，我会默认将大多数类保持为未密封。 如果您通过更改基类来破坏从您的类派生的代码，您可以简单地修复它。

但是密封在库代码中非常有用。 如果您保持一个未密封的类，您承诺不会破坏从中派生的任何代码。 即你增加公共表面积。 IMO图书馆默认情况下应保持表面积最小，这意味着密封。

但并不总是需要密封整个class级。 密封一些或所有虚拟方法就足够了。 这样，从您的类派生的代码只能扩展它，但不能通过重写方法来修改其当前function。

另一种类通常应该是具有值语义的密封类。 为未密封的类实现正确的相等和伪变换器要困难得多。 因此，除非确实有必要，否则我只需密封它们并避免额外的工作。

Answer 4

我不打算给你一个直接的答案，但这里有一些事情需要考虑：

密封类可能会给您带来（轻微）性能优势。 看到这个post：

密封课真的提供性能优势吗？

密封类通常会干扰通过子类化代码实现的常见模拟框架。

进一步阅读：

为什么.Net中存在’sealed’关键字？

在实践中，我经常不上课。

Answer 5

我注意到课程被密封的唯一一次是我真的需要从中得到一些东西，但后来发现我不能。

我从来没有觉得需要密封我自己的课程。 我根本不认为自己足够聪明，不知道什么时候永远不应该派生一个class级。 我很聪明，但我说不出未来。

对于要密封的核心.NET Framework类可能有一定意义，以便他们可以严格控制框架的行为，但我从未见过日常开发人员需要这样做的情况。 您可能希望不鼓励派出一个class级，但密封它是非常最终的，谁知道您的下周/月/年/终身需求是什么？

Answer 6

是的，如果您希望无法inheritance您的课程，只需添加“密封”关键字即可。 这个类不能是抽象的，不能有protected或virtual方法/字段。