封闭班级

封闭班级并不是我在过去很注意的事情，但我发现自己想知道什么是最佳做法。如果你知道一个班级不会或不应该来源于你是否会密封它作为一个预防措施，只是让密封的关键字知道有人试图从它派生出来的机会很渺茫。封闭班级

我想我要问的是，你应该把所有不打算继承的类作为一个良好的习惯来封印吗？

2011-12-08 CSharpened

可能重复的[我应该密封我认识的所有类不应该用作基类吗？]（http://stackoverflow.com/questions/2164170/should-i-seal-all-classes-i - 知道应该永远不会被用作基地级） – BoltClock

您不应该随意密封所有不属于任何时候意味着要继承的类。

取而代之的是，你认识的印章类别永远不要从其他人那里继承，而应该让其他人打开。如果在稍后的某个时间点可以做出决定，那些类别不应该被继承，那么您可以密封它们。

2011-12-08 16:25:30

“在稍后的时间点......你可以密封他们。”只在应用程序代码中。在库代码中，只能解封类，但不能封装它们，而不破坏构建它的代码。因此，默认情况下作为图书馆作者密封是合理的。 – CodesInChaos

我觉得这与应该完成的事情完全相反。以后密封课程是一个突破性的改变，而不是开封。除非你仔细考虑过人们在你的类型中进行子类化时可能做什么，你可以引入脆弱的基类问题。 – Andy

@安迪 - 你是对的。不幸的是，在答案被接受之后，在其他评论中已经指出错误，并且您无法删除被认为是被接受的答案的帖子。 –

如果您按照open/closed原则处理该字母，则不应使用sealed关键字。但我想总有一些角落案例。

2011-12-08 16:25:43

+1对于SOLID的O/C – Yuck

您仍然可以遵循封闭类的开放/封闭原则，例如使用组合。推荐的优秀设计原则之一是赞成合成而不是继承。 http://lostechies.com/gabrielschenker/2009/02/13/the-open-closed-principle/ – cfwall

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

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

对于要封装的核心.NET框架类可能会有一定的意义，以便他们可以严格控制框架的行为，但我从来没有看到日常开发人员需要这样做的情况。你可能想阻止派生一个班级，但是封闭班级是相当终结的，谁知道你的下一周/月/年/一生会有什么需求？

2011-12-08 16:26:33

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

密封类可能给你一个（轻微）的性能优势。看到这个线程：

密封类往往与被继承您的代码实现共同嘲弄框架干涉。

对于进一步阅读：

在实践中，我常常不密封类。

2011-12-08 16:26:37 JohnD

是的，如果你想让你的课堂不能被继承，你只需添加“密封”关键字。这个类不能抽象，不能有保护或虚拟的方法/字段。

2011-12-08 16:28:06 Eugene

我了解这些基础知识，我只是好奇哪些被认为是最佳实践。 – CSharpened

尽管它可以拥有自己的基础，并可以继承它的虚拟成员。 –

在应用程序代码中，所有派生自你的类的代码都是由你自己控制的，所以默认情况下，大多数类都是未开启的。如果通过更改基类来破坏派生自类的代码，则可以简单地修复它。

但是密封在库代码中非常有用。如果您离开课程，您承诺不会破坏任何源自它的代码。即您增加公共表面面积。国际海事组织的库房应保持最小的表面面积默认情况下，这意味着密封。

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

另一种类应该经常被密封的类与价值语义。为非密封类实现正确的平等和伪增变要困难得多。所以我只是简单地将它们密封起来，避免额外的工作，除非真的必要

2011-12-08 16:35:12 CodesInChaos

回答