System.Collections.Immutable容器,为什么密封?

kof*_*fus 0 .net c# .net-core asp.net-core

为什么容器类在System.Collections.Immutable中,即ImmutableList<T>密封?

我想继承它们,并且必须经历一个丑陋且容易出错的组合+代理..

试着理解这里的原因?

Eri*_*ert 11

所有类型都应密封,除非它们是专门为扩展而精心设计的. 设计扩展是困难和昂贵的,容易做错.

此外:当您使用允许扩展的类型时,存在安全性和正确性含义.通过使类型密封,该类型的作者告诉消费者该类型"如果您收到此类型的实例,您可以依赖于您实际上获得由Microsoft编写的类型,由Microsoft测试,并有微软发布的源代码".您可以编写测试并确信运行时行为将与测试时间行为相匹配,因为没有其他人能够制作具有错误的疯狂扩展.

问题是倒退.你永远不应该要求一种类型的密封原因; 密封应该是该语言的默认值.相反,我们需要一个理由来开启一种类型:因为它是专为扩展而设计的,因为它是由专业人员实施的,他们仔细了解扩展的所有含义,并且因为该类型的消费者愿意承担不知道什么的风险他们调用的代码实际上是这样做的.

  • @kofifus:是的,绝对:*所有框架类型都应该从头开始密封*.如果有*记录的客户需求*,那么它们应该有选择性地开启*仅*,并且该过程应该在设计,测试和实施阶段进行审查.幸运的是,许多框架设计师已经意识到他们早期的骑士态度是一个坏主意,并开始密封新类型. (3认同)
  • 谢谢Eric,我个人不同意这里,继承是一种扩展现有代码的机制,如果我选择在我的代码中滥用它我会在我的项目中遭受后果,默认情况下禁止它是玩保姆 (2认同)
  • 埃里克 我在进一步思考这个问题,假设 C# 有一个新关键字(即非虚拟),与密封不同,这意味着你 _can_ 从类派生,但你 _cannot_ 将派生实例向上转换为标记为非虚拟的类(由编译器强制执行) ,这会满足您的安全顾虑并为我们提供两全其美的好处吗?(对于 typedef 也很有用 ..) (2认同)