为什么默认情况下没有密封课程？

我只是想知道,因为密封关键字的存在表明它是类作者关于是否允许其他类继承它的决定,为什么默认情况下没有类密封,有一些关键字将它们显式标记为可扩展？

我知道它有些不同,但访问修饰符以这种方式工作.默认情况下是限制性的,只有通过插入关键字才能获得更全面的访问权限.

尽管如此,我很有可能没有想到这一点,所以请保持人性化!

1> Jon Skeet..：

---

我说这只是一个错误.我知道许多人(包括我自己)认为课程确实应该默认密封.该阵营的C#设计团队中至少有几个人.自从C#首次设计以来,钟摆摆脱了遗传.(当然,它有它的位置,但我发现自己很少使用它.)

对于它的价值而言,这并不是与Java过于接近的唯一错误:我个人认为Equals和GetHashCode不在对象中,并且您需要特定的Monitor实例来锁定...

---

@Windows:两者都不是这样的.您可以*可选地*实现相等性和GetHashCode,它有意义,实现一个接口.可以包括系统IEqualityComparer,其进行身份比较.其他比较可以基于公共财产.没关系.

---

C#的三个主要错误:默认可变,默认未密封,默认为可空.

2> Pablo Retyk..：

---

在我看来,应该没有默认语法,这样你总是明确地写出你想要的.这迫使编码人员理解/思考更多.

如果你想让一个类可以继承,那么你就写了

public extensible class MyClass

除此以外

public sealed class MyClass

顺便说一下,我认为访问修饰符也应该这样,不允许使用默认访问修饰符.

---

我会重用现有的`base`关键字"公共基类......"

3> Cory House..：

---

我看到两个简单的原因:

继承是OO的基本原则,因此默认情况下不允许它是不直观的.

大多数类都设计为允许继承,因此默认情况下允许继承可以节省输入.

---

我认为很多人会认为大多数类都不是*设计为继承的.

---

@Chris:没办法.大多数类永远不会从中衍生出来,并且猜测哪些元素需要专门化,不仅浪费时间,而且构建对未来实现决策过程的限制.有关此问题的详细讨论,请参阅Effective Java.

---

我还认为大多数开发人员都没有考虑继承而构建他们的类.

---

如果我可以投票评论,我会这样做Jon的评论 - 这是基本点 - 设计继承确实需要大量的预见,绝大多数时间是不需要的 - 所以为什么要默认需要开发人员浪费脑循环？

---

Mike和Steve,如果您遵循良好的OO实践,那么您将设计要继承和重用的类.