在我工作的一个大项目中，我正在考虑建议其他程序员如果没有考虑如何对他们的类进行子类化，则始终密封他们的类。很多时候，经验不足的程序员从来不会考虑这一点。
我觉得奇怪的是，在 Java 和 C# 中，类默认是非密封/非最终的。我认为将类密封可以大大提高代码的可读性。
请注意，这是内部代码，如果发生需要子类化的罕见情况，我们随时可以更改它。
你有什么经历？我对这个想法遇到了相当大的阻力。难道人们都懒得连打字都懒得了吗？sealed?
好吧，既然很多人都已经考虑过了……
是的，我认为建议默认情况下密封类是完全合理的。
这与乔什·布洛赫 (Josh Bloch) 在他的著作中的建议相一致。出色的 book 有效的 Java，第二版 https://rads.stackoverflow.com/amzn/click/com/0321356683:
为继承而设计，或者禁止继承。
为继承而设计是hard，并且可以使您的实施less灵活，特别是如果您有虚拟方法，其中一个方法调用另一个方法。也许它们是超载的，也许不是。一个人打电话给另一个人这一事实必须记录在案否则，您无法安全地重写任一方法 - 您不知道何时会调用它，也不知道是否可以安全地调用另一个方法而不会面临堆栈溢出的风险。
现在，如果您以后想要更改哪个方法在更高版本中调用哪个方法，则不能 - 您可能会破坏子类。因此，以“灵活性”的名义，您实际上已经实现了less灵活，并且必须更仔细地记录您的实施细节。对我来说这听起来不是一个好主意。
接下来是不可变性——我喜欢不可变类型。我发现它们比可变类型更容易推理。这就是为什么乔达时间 http://joda-time.sf.netAPI 比使用更好Date and Calendar在爪哇。但未密封的类永远不可能known是一成不变的。如果我接受类型的参数Foo，我也许可以依赖这些属性声明于Foo不会随着时间的推移而改变，但我不能依赖对象本身不被修改 - 子类中可能有一个可变属性。如果该属性也被某些虚拟方法的重写所使用，请上帝帮助我。告别不变性的许多好处。 （具有讽刺意味的是，Joda Time 具有非常大的继承层次结构 - 通常会说“子类应该是不可变的。Chronology移植到 C# 时很难理解。）
最后，还有过度使用继承的问题。在可行的情况下，我个人更喜欢组合而不是继承。我喜欢接口的多态性，并且偶尔我使用实现的继承 - 但它很少适合我的经验。将类密封起来可以避免它们被不恰当地从组合更适合的地方得出。
编辑：我还想指出读者Eric Lippert 2004 年的博客文章 https://learn.microsoft.com/en-gb/archive/blogs/ericlippert/why-are-so-many-of-the-framework-classes-sealed为什么这么多框架类是密封的。我希望 .NET 在很多地方提供界面我们可以努力提高可测试性，但这是一个略有不同的要求......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
