entityMap|blocks|key|846cs|text|在实现安全功能的类上，这样原始对象就不能被“模拟”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2saka|更广泛地说，我最近与微软的一位人士进行了交流，他告诉我，他们试图将继承限制在真正有意义的地方，因为如果不进行处理，它在性能方面会变得昂贵。|46a81|sealed关键字告诉CLR再也没有要查找方法的类了，这就加快了速度。|eer5l|在当今市场上的大多数性能增强工具中，您会发现一个复选框，它将封存所有未继承的类。|bpgek|但是要小心，因为如果你想通过MEF发现插件或程序集，你就会遇到问题。^0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|K|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|L|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|M|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|N|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|O|9|@]|A|@]|B|$]]]]

<ol>
<li>On a class that implements security features, so that the original object cannot be "impersonated".</li>
<li>More generally, I recently exchanged with a person at Microsoft, who told me they tried to limit the inheritance to the places where it really made full sense, because it becomes expensive performance-wise if left untreated. The sealed keyword tells the CLR that there is no class further down to look for methods, and that speeds things up.</li>
</ol>

In most performance-enhancing tools on the market nowadays, you will find a checkbox that will seal all your classes that aren't inherited. 
Be careful though, because if you want to allow plugins or assembly discovery through MEF, you will run into problems.

entityMap|blocks|key|29rm6|text|附录|type|unstyled|depth|inlineStyleRanges|entityRanges|data|rncl|路易斯·考特曼的精彩回答|2m7en|如果类不是|4cbvu|设计|9uadd|对于继承，子类可能会中断|5ukif|类不变量|avr1h|..。当然，这只适用于创建公共API的情况，但根据我的经验，我会封存任何未显式设计为子类化的类。|53br6|在相关注释中，仅适用于未密封的类:创建的任何方法|475h1|是一个扩展点，或者至少看起来应该是一个扩展点。声明方法|f44mg|这也应该是一个有意识的决定。(在C#中，这是一个有意识的决定；在Java语言中则不是。)|clmre|然后是这样的：|cssl3|密封会使单元测试更加困难，因为它禁止more。|3gsbm|一些相关链接：|1dcnh|Edition，第2版|2b1u|作者:+Joshua+Bloch。见项目17+(需要Safari订阅)|9vmro|有效的Java项目17:继承的设计和文档，否则禁止它|654lo|(同一项目的讨论)|2sc8k|还要注意的是|codcg|Kotlin|3i9hq|默认封存类；|3ccm9|its|brp8j|关键字与Java相反|fc9qh|或者|5971t|C#的|9cl2h|..。(可以肯定的是，|3pj1b|没有普遍的共识认为这是一件好事。|4ln7t|。)^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|1S|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|1T|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|1U|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|1V|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|1W|9|@]|A|@]|B|$]]|$2|K|4|L|6|7|8|1X|9|@]|A|@]|B|$]]|$2|M|4|N|6|7|8|1Y|9|@]|A|@]|B|$]]|$2|O|4|P|6|7|8|1Z|9|@]|A|@]|B|$]]|$2|Q|4|R|6|7|8|20|9|@]|A|@]|B|$]]|$2|S|4|T|6|7|8|21|9|@]|A|@]|B|$]]|$2|U|4|V|6|7|8|22|9|@]|A|@]|B|$]]|$2|W|4|X|6|7|8|23|9|@]|A|@]|B|$]]|$2|Y|4|Z|6|7|8|24|9|@]|A|@]|B|$]]|$2|10|4|11|6|7|8|25|9|@]|A|@]|B|$]]|$2|12|4|13|6|7|8|26|9|@]|A|@]|B|$]]|$2|14|4|15|6|7|8|27|9|@]|A|@]|B|$]]|$2|16|4|17|6|7|8|28|9|@]|A|@]|B|$]]|$2|18|4|19|6|7|8|29|9|@]|A|@]|B|$]]|$2|1A|4|1B|6|7|8|2A|9|@]|A|@]|B|$]]|$2|1C|4|1D|6|7|8|2B|9|@]|A|@]|B|$]]|$2|1E|4|1F|6|7|8|2C|9|@]|A|@]|B|$]]|$2|1G|4|1H|6|7|8|2D|9|@]|A|@]|B|$]]|$2|1I|4|1J|6|7|8|2E|9|@]|A|@]|B|$]]|$2|1K|4|1L|6|7|8|2F|9|@]|A|@]|B|$]]|$2|1M|4|1N|6|7|8|2G|9|@]|A|@]|B|$]]|$2|1O|4|1P|6|7|8|2H|9|@]|A|@]|B|$]]|$2|1Q|4|1R|6|7|8|2I|9|@]|A|@]|B|$]]]]

An addendum to <a href="https://stackoverflow.com/a/7777674/4671754">Louis Kottmann's excellent answer</a>:
<ol start="3">
<li>If a class isn't designed for inheritance, subclasses might break <a href="https://en.wikipedia.org/wiki/Class_invariant" rel="nofollow noreferrer">class invariants</a>. This really only applies if you're creating a public API, of course, but as I rule of thumb I seal any class not explicitly designed to be subclassed.</li>
</ol>
On a related note, applicable to unsealed classes only: any method created <code>virtual</code> is an extension point, or at least looks like it should be an extension point. Declaring methods <code>virtual</code> should be a conscious decision as well. (In C# this is a conscious decision; in Java it isn't.)
And then there's this:
<ol start="4">
<li>Sealing can make unit testing more difficult, as it prohibits mocking.</li>
</ol>
<hr />
Some relevant links:
<ul>
<li><a href="https://www.safaribooksonline.com/library/view/effective-java-2nd/9780137150021/" rel="nofollow noreferrer">Effective Java, 2nd Edition</a> by Joshua Bloch. See item 17 (requires Safari subscription)</li>
<li><a href="https://medium.com/@rufuszh90/effective-java-item-17-design-and-document-for-inheritance-or-else-prohibit-it-be6041719fbc" rel="nofollow noreferrer">Effective Java Item 17: Design and document for inheritance or else prohibit it</a> (discussion of same item)</li>
</ul>
Also note that <a href="https://kotlinlang.org/" rel="nofollow noreferrer">Kotlin</a> seals classes by default; <a href="https://kotlinlang.org/docs/reference/classes.html#inheritance" rel="nofollow noreferrer">its <code>open</code> keyword is the opposite of Java's <code>final</code> or the <code>sealed</code> of C#</a>. (To be sure, <a href="https://discuss.kotlinlang.org/t/classes-final-by-default/166" rel="nofollow noreferrer">there is no universal agreement that this is a good thing</a>.)

entityMap|blocks|key|ebhbv|text|我认为这篇文章有一些好的观点，具体的例子是当试图将一个非密封的类转换为任何随机接口时，编译器不会抛出错误；但当使用密封时，编译器会抛出它无法转换的错误。密封类带来了额外的代码访问安全性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3vub0|8koti|https://www.codeproject.com/Articles/239939/Csharp-Tweaks-Why-to-use-the-sealed-keyword-on-cla^0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|F|9|@]|A|@]|B|$]]|$2|C|4|-4|6|7|8|G|9|@]|A|@]|B|$]]|$2|D|4|E|6|7|8|H|9|@]|A|@]|B|$]]]]

I think this post has some good point, the specific case was when trying to cast a non-sealed class to any random interface, compiler doesn't throw error; but when sealed is used the compiler throws error that it can't convert. Sealed class brings additional code access security. 
<a href="https://www.codeproject.com/Articles/239939/Csharp-Tweaks-Why-to-use-the-sealed-keyword-on-cla" rel="nofollow noreferrer">https://www.codeproject.com/Articles/239939/Csharp-Tweaks-Why-to-use-the-sealed-keyword-on-cla</a>

entityMap|blocks|key|80oed|text|将类标记为|type|unstyled|depth|inlineStyleRanges|entityRanges|data|7su3u|防止篡改可能损害安全性或影响性能的重要类。|6hbjp|很多时候，当我们正在设计一个具有固定行为的实用类时，密封一个类也是有意义的，这是我们不想改变的。|8kl09|例如，|bheam|中的命名空间|f94op|提供许多密封的类，例如|4vg2c|..。如果不密封，就有可能扩展它的功能，这可能是不可取的，因为它是具有给定功能的基本类型。|77gv9|类似地，|eka51|在|4jjl3|总是隐式密封的。因此，不能从一个结构/类派生出另一个结构。这样做的理由是|v2po|仅用于建模|sftv|独立、原子、用户定义|86j8f|数据类型，我们不想修改这些类型。|6cji2|有时，当您构建类层次结构时，您可能希望根据您的域模型或业务规则来限制继承链中的某个分支。|4gqmg|例如，一个|ae22p|和|e1i1|都是|6ieai|但是在你的组织中，除了兼职员工之外，你没有任何角色。在这种情况下，您可能希望将|dqn2c|以防止进一步的分支。另一方面，如果您有按小时或每周兼职的员工，则从|1si4n|..。^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|$]|1|@$2|3|4|5|6|7|8|1E|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|1F|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|1G|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|1H|9|@]|A|@]|B|$]]|$2|I|4|J|6|7|8|1I|9|@]|A|@]|B|$]]|$2|K|4|L|6|7|8|1J|9|@]|A|@]|B|$]]|$2|M|4|N|6|7|8|1K|9|@]|A|@]|B|$]]|$2|O|4|P|6|7|8|1L|9|@]|A|@]|B|$]]|$2|Q|4|R|6|7|8|1M|9|@]|A|@]|B|$]]|$2|S|4|T|6|7|8|1N|9|@]|A|@]|B|$]]|$2|U|4|V|6|7|8|1O|9|@]|A|@]|B|$]]|$2|W|4|X|6|7|8|1P|9|@]|A|@]|B|$]]|$2|Y|4|Z|6|7|8|1Q|9|@]|A|@]|B|$]]|$2|10|4|11|6|7|8|1R|9|@]|A|@]|B|$]]|$2|12|4|13|6|7|8|1S|9|@]|A|@]|B|$]]|$2|14|4|15|6|7|8|1T|9|@]|A|@]|B|$]]|$2|16|4|17|6|7|8|1U|9|@]|A|@]|B|$]]|$2|18|4|19|6|7|8|1V|9|@]|A|@]|B|$]]|$2|1A|4|1B|6|7|8|1W|9|@]|A|@]|B|$]]|$2|1C|4|1D|6|7|8|1X|9|@]|A|@]|B|$]]]]

Marking a class as <code>Sealed</code> prevents tampering of important classes that can compromise security, or affect performance. 

Many times, sealing a class also makes sense when one is designing a utility class with fixed behaviour, which we don't want to change. 

For example, <code>System</code> namespace in <code>C#</code> provides many classes which are sealed, such as <code>String</code>. If not sealed, it would be possible to extend its functionality, which might be undesirable, as it's a fundamental type with given functionality. 

Similarly, <code>structures</code> in <code>C#</code> are always implicitly sealed. Hence one cannot derive one structure/class from another structure. The reasoning for this is that <code>structures</code> are used to model only stand-alone, atomic, user-defined data types, which we don't want to modify. 

Sometimes, when you are building class hierarchies, you might want to cap off a certain branch in the inheritance chain, based on your domain model or business rules. 

For example, a <code>Manager</code> and <code>PartTimeEmployee</code> are both <code>Employee</code>s, but you don't have any role after part-time employees in your organization. In this case, you might want to seal <code>PartTimeEmployee</code> to prevent further branching. On the other hand, if you have hourly or weekly part-time employees, it might make sense to inherit them from <code>PartTimeEmployee</code>.

In C# and C++/CLI the keyword <code>sealed</code> (or <code>NotInheritable</code> in VB) is used to protect a class from any inheritance chance (the class will be non-inheritable). I know that one feature of object-oriented programming is inheritance and I feel that the use of <code>sealed</code> goes against this feature, it stops inheritance. 
Is there an example that shows the benefit of <code>sealed</code> and when it is important to use it?

When and why would you seal a class?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

 在C#和C++/CLI中，关键字 (或 在VB中)用于保护类不受任何继承机会的影响(该类将是不可继承的)。我知道面向对象编程的一个特性是继承，我觉得使用 与此功能背道而驰，它将停止继承。有没有一个例子来说明 那么什么时候使用它是很重要的呢？

问什么时候以及为什么要封存一个类？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候以及为什么要封存一个类？EN