在 .Net 框架中，许多类都被标记为 "sealed"，这意味着您无法使用自己的类继承这些类。这显然违反了面向对象编程的本质，即您可以扩展和重新定义现有对象的行为。
那么，'sealed' 关键字存在的好处是什么呢？
以 Silverlight 中的 NotifyCollectionChangedEventArgs 为例，它是被 sealed 的。我想创建一个支持 AddRange 和 RemoveRange 的 ObservableCollection 版本，但 Silverlight 版本的 NCCEA 不提供支持 NewItems 和 OldItems 属性的多个项的构造函数，这些属性已经定义为 ILists。通常，我会使用自己的变体扩展该类，覆盖 NewItems 和 OldItems 属性，但在这种情况下，我不能这样做，也看不出为什么会这样。
设计可扩展的类（或框架）并不是一件简单的事情，简单地说，继承并不是面向对象编程的唯一原则。
因此，sealed关键字的存在允许开发者/设计者表达和保留这些意图。将一个类标记为sealed可以通过减轻维护负担来使开发人员的生活更加容易。它允许原始开发者控制如何扩展类（或框架），从而可以在不担心破坏其他代码的情况下进行内部更改。
其中一个原则是，开发者应默认将任何叶子类标记为sealed。然后，当开发者有意创建一个未密封的类时，这将强制他们考虑可扩展性。
参考：Eric Lippert - 为什么许多框架类都被密封？
sealed*。你的回答对我来说并不够。现在我可以看出你的观点了。而我错过的都在细节中......让我提一个编辑建议。;-) - cregox这是我今天提出的一个有些相关问题的答案，它可能有助于澄清封装类的目的：
在开始开发自己的可重用库之前，我曾问过自己同样的问题。很多时候，你会遇到某些类，如果没有实现者进行晦涩或深奥的调用序列，就不能扩展该类。
当允许扩展你的类时，你必须考虑：如果开发人员扩展了我的类，并将这个新类传递给我的库，我能够透明地使用这个新类吗？我能正常地与这个新类一起工作吗？这个新类真的会表现得一模一样吗？
我发现，在.NET框架中，大多数密封类都有一些你不知道的底层要求，而且根据当前的实现，不能安全地暴露给子类使用。
现在请点击链接并点赞实际作者。
虽然我同意.NET可能封装了太多，但这通常是为了保护生态系统的完整性。当你的首要任务之一是保持整体框架/API/运行时的稳定性，而类之间存在相对脆弱的依赖关系时，防止人们覆盖该行为并无意中破坏核心功能可能是最安全的。
不过，我还是觉得.NET团队封装了太多的类。有时候封装会是开发人员简单懒惰的表现，因为适当的类设计会涉及到太多的工作。
我认为除了保护无知的人（呃，我是说无辜的人）之外，没有什么好的理由来封装类。你知道那句老话，“给他们足够的绳子，他们就会自己上吊”。让他们自己摇摆吧。也许这是我的C++背景，但我很放心，知道如果我不勤奋的话，我有完全搞砸事情的能力。
我倾向于通过接口进行编程。接口当然是公共的，任何人都可以提供自己的实现，以符合接口所表达的契约。实现这些接口的具体类往往是私人关注，并标记为internal和/或private。我觉得我不需要封装这样的类。
在需要代码重用的地方，我避免使用继承进行重用，而更喜欢组合和其他技术。
封装也可能适用于被认为是普通数据类型的类型，但我对此并不确定。
这要看情况而定，有些类只是用来实例化的（如果存在继承，那么继承只是为了简化实现），而其他类则旨在被继承以提供特定的实现。
密封类有一些优点：
否则，如果您想使用“舒适”方法装饰一个密封类，请使用扩展方法（C# 3.0）。
仅仅因为某个东西是一个对象，并不意味着它总是应该为每个人开放以扩展或重新定义其行为。
一个很好的比喻就是门和锁。门的本质是让人们通过，这就是它的设计目的。然而，大多数门都设计有锁，可以限制人们通过的能力。是否给门加锁以及默认是否上锁的决定留给房间的建筑师，基于房间内的物品和谁应该有权访问它，而不是基于它是一扇门这个事实。
当然，如果特定建筑物中的大多数门默认上锁，尤其是你真的想通过其中的一扇门时，这可能会让人感到沮丧。:-) 我自己也曾经历过这种情况，并提出了同样的问题。简短的答案是，在设计复杂框架时，有时人们倾向于更加谨慎，将类默认封闭，除非有明确的场景需要对其进行扩展。
final类修饰符。 - Austin_Anderson