为什么默认情况下类不被密封？
我只是想知道，既然 sealed 关键字的存在表明是否允许其他类继承它是类作者的决定，为什么类不默认密封，用一些关键字来标记它们明确是可扩展的？
我知道这有些不同，但访问修饰符是这样工作的。 默认情况下是限制性的，只有插入关键字才能授予更完整的访问权限。
不过，我很可能没有考虑清楚这一点，所以请人性化一点！
I was just wondering, since the sealed keyword's existence indicates that it's the class author's decision as to whether other classes are allowed to inherit from it, why aren't classes sealed by default, with some keyword to mark them explicitly as extensible?
I know it's somewhat different, but access modifiers work this way. With the default being restrictive and fuller access only being granted with the insertion of a keyword.
There's a large chance that I haven't thought this through properly, though, so please be humane!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我想说这只是一个错误。 我认识很多人（包括我自己），他们认为默认情况下确实应该密封类。 该阵营的 C# 设计团队中至少有几个人。 自 C# 首次设计以来，钟摆已经偏离了继承的方向。 （当然，它有它的地位，但我发现自己相对很少使用它。）
就其价值而言，这并不是与 Java 过于接近的唯一错误：就我个人而言，我宁愿 Equals 和 GetHashCode 不是在对象中，并且您也需要特定的 Monitor 实例来锁定......
I'd say it was just a mistake. I know many people (including myself) who believe that classes should indeed be sealed by default. There are at least a couple of people in the C# design team in that camp. The pendulum has swung somewhat away from inheritance since C# was first designed. (It has its place, of course, but I find myself using it relatively rarely.)
For what it's worth, that's not the only mistake along the lines of being too close to Java: personally I'd rather Equals and GetHashCode weren't in object, and that you needed specific Monitor instances for locking too...
在我看来不应该有默认语法，这样你就可以明确地编写你想要的内容。 这迫使编码人员更多地理解/思考。
如果你希望一个类是可继承的，那么你可以另外编写
顺便
说一句，我认为访问修饰符也应该如此，禁止默认访问修饰符。
In my opinion there should be no default syntax, that way you always write explicitly what you want. This forces the coder to understand/think more.
If you want a class to be inheritable then you write
otherwise
BTW I think the same should go with access modifiers, disallow default access modifiers.
继承是面向对象的基本原则，因此可以说，默认情况下禁止继承并不直观。
Inheritance is a foundational principle of OO, so arguably, disallowing it by default wouldn't be intuitive.
您可能会提出与反对默认密封一样多的论据。 如果反过来，就会有人提出相反的问题。
You could probably make just as many arguments in favor of sealed-by-default as you could against it. If it were the other way around, someone would be posting the opposite question.
我不记得曾听过关于默认不密封课程的决定的理由。 然而，肯定有不少人认为 C# 应该被指定为默认的：
http://codebetter.com/blogs/patricksmacchia/archive/2008/01/05/rambling-on-the-sealed-keyword。 ASPX
I can't recall having heard a rationale for the decision to have classes not sealed by default. However, there are certainly quite a few people who believe that C# should have been spec'ed to have sealed be the default:
http://codebetter.com/blogs/patricksmacchia/archive/2008/01/05/rambling-on-the-sealed-keyword.aspx
密封类阻止继承，因此是面向对象的憎恶。 有关详细信息，请参阅此咆哮;-)
sealed classes prevent inheritance and therefore are an OO abombination. see this rant for details ;-)
Word 80% 的功能未被使用。 80% 的类不会被继承。 在这两种情况下，偶尔会有人出现并想要使用或重用某个功能。 原设计者为何要禁止重复使用？ 让重用者决定他们想要重用什么。
80% of the features of Word go unused. 80% of classes don't get inherited from. In both cases, once in a while, someone comes along and wants to use or reuse a feature. Why should the original designer prohibit reuse? Let the reuser decide what they want to reuse.
仅仅从未密封的类派生不会改变该类的行为。 最糟糕的情况是基类的新版本将添加一个与派生类同名的成员（在这种情况下，只会出现编译器警告，提示您应该使用new或覆盖修饰符）或者基类被密封（如果该类已经被释放到野外，这是一个设计禁忌）。 任意子类化仍然符合里氏替换原则。
C# 中默认情况下成员不可重写的原因是，重写方法可能会以基类作者未预料到的方式更改基类的行为。 通过使其明确抽象或虚拟，这表明作者意识到它可以改变或超出他们的控制范围，并且作者应该考虑到这一点。
Merely deriving from an unsealed class doesn't change the class's behavior. The worst that can happen is that a new version of the base class will add a member with the same name as the deriving class (in which case there will just be a compiler warning saying you should use the new or override modifier) or the base class is sealed (which is a design no-no if the class has already been released into the wild). Arbitrary sublassing still complies with the Liskov Substitution Principle.
The reason that members are not overridable by default in C# is that because overriding a method can change the base class's behaviour in a way that the base class's author didn't anticipate. By making it explicitly abstract or virtual, it's saying that the author is aware that that it can change or is otherwise beyond their control and the author should have taken this into account.
出于同样的原因，为什么对象默认情况下不是私有的
，或者
与对象类似物保持一致，即对象默认情况下不是私有的
只是猜测，因为归根结底，这是一种语言的设计决策，而创建者所说的是佳能材料。
For the same reason why objects are not private by default
or
to be consistent with the object analogue, which is objects are not private by default
Just guessing, coz at the end of the day it's a language's design decision and what the creators say is the canon material.