当C＃类的方法默认为非虚拟时，为什么默认情况下未密封C＃类？

Question

默认情况下，C＃中的方法是非虚拟的。这个对另一个问题的答案解释了这样做的好处：

应该为继承设计类，以便能够利用它。默认情况下，将方法虚拟化意味着可以将类中的每个函数插入并替换为另一个函数，这并不是一件好事。

甚至Anders Hejlsberg 似乎也给出了相同的原因：

当我们在API中发布虚拟方法时，我们不仅承诺在调用此方法时还会发生x和y。我们还承诺，当您重写此方法时，相对于其他方法，我们将以特定的顺序调用它，并且状态将处于此不变状态。[...]您不希望用户在API中的任意点上重写和挂接，因为您不一定会做出这些承诺。

我同意这种推理：通常，当我创建一个非私有方法时，我只想创建可以从类外部的某个地方调用的代码。通常，不考虑其他人如何覆盖此方法以及将产生何种效果。对于特殊情况，我可以用virtual信号表示确实以覆盖有意义的方式创建了代码。

但是，默认情况下仍未打开类。该默认假定我花确保继承一个类有意义的额外的努力。

在这方面，有什么使类不同于方法的吗？

---

编辑
我真的不知道要更改的内容-基于意见的内容。我从没问过意见。也许我必须明确地说出来？

我不要意见

正确的答案将提供类与方法不同的示例，或者声明在这种情况下没有区别。

Answer 1

我相信问题是“鉴于有充分的理由说明为什么默认情况下方法应为非虚拟方法，为什么默认情况下也不对类进行密封？”

还可以添加：C＃将默认可访问性设置为内部（对于顶级类型）或私有（对于类型的成员）；也就是说，它选择了更严格和更安全的选择；如果开发人员希望使用限制性较小，危险性更高的选项，则可以选择采用。默认情况下密封也将选择限制性更强，更安全的选项作为默认选项。

另外：启封课程绝不会是一项重大更改，但以后要确定您希望将课程密封起来，将其密封是一项重大更改。C＃通常更喜欢鼓励较少改动的设计选择，因此也出于这个原因，您会认为C＃类应默认密封。

我们已经确定了默认情况下密封是好主意并且与C＃中的其他设计选择一致的三个原因。为什么在这方面C＃会不一致，选择将未密封的类设置为默认类？

我不知道。作为C＃中的次要设计缺陷，它总是令我感到震惊。对于这种选择，我从未见过有力的论据，也不知道是否在早期的设计会议上进行了辩论。那是我在设计团队之前的时间。

除非您遇到2001年参加该设计会议的人并问他们，否则您可能无法获得满意的答案。

我习惯于封闭我编写的每个类，除非有理由为继承设计它。我鼓励大家也这样做。