密封类答案 - 爱码网

【问题标题】：Sealing a class密封类
【发布时间】：2011-12-08 16:20:55
【问题描述】：

过去我并没有特别注意封闭课程，但我发现自己想知道什么是最佳实践。如果您知道一个类不会或不应该派生自某个类，您是否会出于预防目的而将其密封，因为您知道有人试图从它派生的可能性很小，因此只需将密封关键字留在外面。

我想我要问的是，您是否应该密封所有不打算用于继承的类，作为一种良好做法？

【问题讨论】：

【解决方案1】：

如果您信守open/closed 原则，则永远不应该使用sealed 关键字。但我想总会有一些极端情况。

【讨论】：

您仍然可以通过使用组合来遵循密封类的开/关原则。推荐的良好设计原则之一是支持组合而不是继承。 lostechies.com/gabrielschenker/2009/02/13/…

【解决方案2】：

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

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

但并不总是需要密封整个班级。密封部分或全部虚拟方法就足够了。这样，从您的类派生的代码只能扩展它，但不能通过覆盖方法来修改其当前功能。

另一种类，通常应该是具有值语义的密封类。为未密封的类实现正确的相等和伪变异器要困难得多。所以除非真的有必要，否则我会简单地密封它们并避免额外的工作。

【讨论】：

【解决方案3】：

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

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

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

进一步阅读：

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

【讨论】：

【解决方案4】：

在任何给定时间，您都不应随意封印所有不打算从其继承的类。

相反，您知道永远不应该继承的密封类并让其他类保持打开状态。如果在以后的某个时间点，可以决定永远不要从您那里继承这些类，那么您可以密封它们。

【讨论】：

“在以后的某个时间点……你可以密封它们。”仅在应用程序代码中。在库代码中，您只能解封类，但不能密封它们，而不会破坏基于它的代码。所以默认封为库作者是合理的。
我觉得这与应该做的完全相反。稍后密封一个类是一个重大变化，而解封则不是。除非您仔细考虑过人们在子类化您的类型时可能会做什么，否则您可能会引入脆弱的基类问题。
@Andy - 你是对的。不幸的是，在接受答案后，其他评论中已指出错误，您无法删除被视为已接受答案的帖子。
@Andy 你不应该编辑一个问题只说“见 cmets”。如果 cmets 很重要，请编辑问题以将信息纳入其中。
@JustinNiessner，以及其他可能阅读此内容的人：介意帮助我 trying to understand the whole sealed concept?

【解决方案5】：

我唯一注意到一个类是密封的是当我真的需要从中派生一些东西，但后来发现我不能。

我从来没有觉得有必要封闭自己的课程。我根本不认为我足够聪明，不知道什么时候不应该派生一个类。我很聪明，但我无法预测未来。

对核心 .NET Framework 类进行密封可能有一定意义，这样它们就可以严格控制框架的行为，但我从未见过日常开发人员需要这样做的情况。您可能不想阻止派生课程，但密封它是最后的任务，谁知道您下周/月/年/一生的需求是什么？

【讨论】：

【解决方案6】：

是的，如果您希望您的类不能被继承，您只需添加“密封”关键字。此类不能是抽象的，不能有受保护的或虚拟的方法/字段。

【讨论】：