我应该在默认情况下推荐密封类？ [英] Should I recommend sealing classes by default?

问题描述

在一个我，因为我正在考虑推荐其他程序员始终封住自己的班级，如果他们还没有考虑过他们的课应该怎么分归类工作的大项目。很多时候，经验不足的程序员从来没有考虑这一点。

In a big project I work for I am considering recommending other programmers to always seal their classes if they haven't considered how their classes should be sub classed. Often times less experienced programmers never consider this.

我觉得很奇怪，在Java和C＃归类为非密封/非最终PR默认。我觉得做密封类大大提高了code可读性。

I find it odd that in java and c# classed are non-sealed / non-final pr default. I think making classes sealed greatly improves readability of the code.

请注意，这是在房子code，我们可以随时更改应在罕见的情况下发生的，我们需要继承。

Notice that this is in house code that we can always change should the rare case occur that we need to subclass.

你有什么经验？我遇到这种想法相当一些阻力。人说懒，他们不能打扰键入封？

What are your experiences? I meet quite some resistance to this idea. Are people that lazy they could not be bothered to type "sealed" ?

推荐答案

好了，因为其他许多人都称在...

Okay, as so many other people have weighed in...

是的，我认为这是完全合理的建议类默认情况下密封。

Yes, I think it's entirely reasonable to recommend that classes are sealed by default.

这一起去与乔希布洛赫在他的优秀的的书有效的Java，第二版的建议：

This goes along with the recommendation from Josh Bloch in his excellent book Effective Java, 2nd edition:

设计继承，或者禁止。

设计为继承的硬盘的，并且可以让你实现的少的灵活性，特别是如果你有虚方法，其中一个调用其他。也许他们是过载，也许他们不是。一个叫对方的事实的必须记录的，否则你不能覆盖任何一种方法安全 - 你不知道什么时候会被调用，或者无论你安全地调用其他方法而不用担心堆栈溢出。

Designing for inheritance is hard, and can make your implementation less flexible, especially if you have virtual methods, one of which calls the other. Maybe they're overloads, maybe they're not. The fact that one calls the other must be documented otherwise you can't override either method safely - you don't know when it'll be called, or whether you're safe to call the other method without risking a stack overflow.

现在，如果你以后想更改的方法调用它在以后的版本中，你不能 - 你可能会破坏子类。因此，在灵活性的名字，你实际上已经取得了实施的少的灵活，并有更密切地记录您的实现细节。这听起来像一个伟大的想法给我。

Now if you later want to change which method calls which in a later version, you can't - you'll potentially break subclasses. So in the name of "flexibility" you've actually made the implementation less flexible, and had to document your implementation details more closely. That doesn't sound like a great idea to me.

接下来是不可改变的 - 我喜欢一成不变的类型。我觉得他们更容易推理比可变类型。这是原因之一乔达时间 API是比使用日期和更好的日历 Java编写的。但是，非密封类永远不可能的知的是一成不变的。如果我接受类型的参数富，我或许可以依靠的在富声明的属性的不随时间而改变，但我不能依靠本身不被修改的对象 - 有可能是在子类中的可变属性。上帝保佑我，如果该属性也使用一些虚拟方法的重写。挥手告别了许多永恒的利益。 （讽刺的是，约达时间有很大的继承层次 - 经常用的东西说：子类应该是一成不变的年表的大型继承层次结构使得它很难移植到C＃的时候明白。 ）

Next up is immutability - I like immutable types. I find them easier to reason about than mutable types. It's one reason why the Joda Time API is nicer than using Date and Calendar in Java. But an unsealed class can never be known to be immutable. If I accept a parameter of type Foo, I may be able to rely on the properties declared in Foo not to be changed over time, but I can't rely on the object itself not being modified - there could be a mutable property in the subclass. Heaven help me if that property is also used by an override of some virtual method. Wave goodbye to many of the benefits of immutability. (Ironically, Joda Time has very large inheritance hierarchies - often with things saying "subclasses should be immutable. The large inheritance hierarchy of Chronology made it hard to understand when porting to C#.)

最后，还有继承过度使用的方面。我个人倾向于组成了继承在可行的情况。我爱多态性接口和偶尔的我用执行继承 - 但它很少非常适合在我的经验。制作类密封避免其受到的不恰当的从那里成分会得出一个更好的选择。

Finally, there's the aspect of overuse of inheritance. Personally I favour composition over inheritance where feasible. I love polymorphism for interfaces, and occasionally I use inheritance of implementation - but it's rarely a great fit in my experience. Making classes sealed avoids them being inappropriately derived from where composition would be a better fit.

编辑：我也很喜欢在埃里克利珀的博客文章指向读者从2004年，了解为什么有这么多的框架类的密封。有很多，我想.NET提供了一个的接口的，我们可以合作，为可测试性的地方，但是这是一个稍微不同的请求......

I'd also like to point readers at Eric Lippert's blog post from 2004 on why so many of the framework classes are sealed. There are plenty of places where I wish .NET provided an interface we could work to for testability, but that's a slightly different request...

这篇关于我应该在默认情况下推荐密封类？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！