为什么.Net中存在'sealed'关键字？

.Net框架中的大量类被标记为"已密封",从而阻止您使用自己的类继承这些类.当然,这违背了面向对象的本质,您可以在其中扩展和重新定义现有对象的行为.

是否有充分的理由存在'sealed'关键字？

例如,Silverlight中的NotifyCollectionChangedEventArgs是密封的.我想创建自己的ObservableCollection版本,它支持AddRange和RemoveRange,但NCCEA的Silverlight版本不提供支持NewItems和OldItems属性的多个项目的构造函数,这些项目已经被定义为IList.通常,我只是用我自己的变体扩展了类,它覆盖了NewItems和OldItems属性,但是在这种情况下我不能,而且我看不出为什么会出现这种情况.

Robert Pauls.. 22

设计可扩展的类(或框架)并非易事,简单地说继承并不是面向对象编程的单一原则.

因此sealed存在允许开发者/设计者表达和保留这些意图.通过减少维护负担,密封课程也可以使他们的生活更轻松.它允许原始开发人员控制类(或框架)的扩展方式,这样他们就可以进行内部更改,而不必担心会破坏对其他代码的更改.

一个原则是开发人员应默认密封任何叶类.然后,当开发人员故意创建一个未密封的类时,它会强制他们考虑可扩展性.

参考:Eric Lippert - 为什么这么多的框架课程被密封？

设计可扩展的类(或框架)并非易事,简单地说继承并不是面向对象编程的单一原则.

因此sealed存在允许开发者/设计者表达和保留这些意图.通过减少维护负担,密封课程也可以使他们的生活更轻松.它允许原始开发人员控制类(或框架)的扩展方式,这样他们就可以进行内部更改,而不必担心会破坏对其他代码的更改.

一个原则是开发人员应默认密封任何叶类.然后,当开发人员故意创建一个未密封的类时,它会强制他们考虑可扩展性.

参考:Eric Lippert - 为什么这么多的框架课程被密封？

我今天提出的一个相关问题的答案可能有助于澄清密封课程的目的:

在我开始研究自己的可重用库之前,我发现自己也在问同样的问题.很多时候,如果不需要来自实现者的模糊或神秘的调用序列,那么您最终无法扩展某些类.

在允许扩展类时,你必须要问:如果开发人员扩展了我的类,并将这个新类传递给我的库,我可以透明地使用这个新类吗？我可以在这个新课上正常工作吗？这个新课真的会表现得一样吗？

我发现大多数情况下.Net Framework中的密封类具有您不知道的某些底层需求,并且鉴于当前实现无法安全地暴露给子类.

Liskov替代和组成

现在请关注该链接并对实际作者进行投票.