C# System.Collections.Immutable容器，为什么要密封？

为什么System.Collections.Immutable（即ImmutableList）中的容器类是密封的

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

---

只是想了解一下原因？

所有类型都应该密封，除非它们是专门为扩展而精心设计的。为扩展进行设计既困难又昂贵，而且容易出错

此外：当您使用允许扩展的类型时，会涉及到安全性和正确性。通过密封该类型，该类型的作者会告诉该类型的使用者，如果您收到该类型的实例，您可以依赖这样一个事实，即您实际上获得的类型是由Microsoft编写、由Microsoft测试并由Microsoft发布的源代码。您可以编写测试并确信运行时行为将与测试时行为相匹配，因为没有其他人能够创建自己的具有bug的疯狂扩展

---

问题倒过来了。你不应该要求一个类型被密封的原因；sealed应该是该语言中的默认值。相反，我们需要一个拆封类型的理由：因为它是为扩展而设计的，因为它是由专业人员实现的，他们仔细理解了扩展的所有含义，并且因为类型的消费者愿意承担不知道他们调用的代码实际做什么的风险。

谢谢Eric，我个人不同意，继承是一种扩展现有代码的机制，如果我选择在代码中误用它，我将在项目中承担后果，默认情况下不允许它就是在玩游戏nanny@kofifus例如你没有明白我的意思。不用于扩展的密封类型的功能不是为了保护您不受自己做出错误决策的影响，比如保姆；这是为了保护该类型的消费者免受恶意参与者的攻击。您是从一个角度来看待这个问题的，即类型的存在是为了扩展它们以满足您的需要，但大多数人并不这样看待类型。类型的存在是为了安全有效地实现其功能。当您编写使用密封类型的方法时，您知道该方法的功能；对于未密封的类型，情况并非如此。我完全理解你的观点，并完全拒绝。使用这种逻辑，整个.Net framework类都应该被密封起来，这将是一场灾难，并增加0安全性。”恶意的“程序员”仍然会使用你密封的http类编写工具包，向他们的秘密云帐户发送密码，这是微软的错吗？幸运的是，99%的框架代码不符合您的要求。我想我们永远不会在这个问题上达成一致，但谢谢你的回答@科菲弗斯：是的，绝对正确：所有的框架类型从一开始就应该被密封。只有在有记录的客户需求的情况下，才应该有选择地打开它们，并且该过程应该包括在设计、测试和实施阶段进行审查。幸运的是，许多框架设计师已经意识到他们早期的傲慢态度是个坏主意，并开始密封新类型。Eric I正在进一步思考这个问题，假设C有一个新的关键字ie nonvirtual，与sealed不同，它意味着您可以从类中派生，但您不能将派生实例向上转换到编译器强制执行的标记为nonvirtual的类中，这会满足您的安全顾虑并使我们两全其美吗？对于typedef也很有用。微软没有成本的概念是很奇怪的。微软有巨大的成本，因为他们开发的代码在每个人使用时都必须是防弹的。微软的努力是巨大的，但不是无限的，它已经在解决比使类型安全可扩展更重要的问题，而这些类型在设计上没有扩展它们的目的。微软应该把有限的精力花在解决真正的问题上。我在微软工作了16年，相信我，我们在语言、编译器和运行时设计方面有很多难题需要解决，我们正在尽可能快地雇佣最优秀的人，而且，我们几乎没有足够的努力去做我们想做的事情的十分之一。微软花在制作一个不必要的、危险的功能上的每一刻，因为将来有人可能需要它，而不是花在解决真正的用户问题上的每一刻。当然，让我们假设这个类型是未密封的。这是一个特点。这是一个未指定、未经测试且未经安全审查的功能。这是一个无法撤消的特性，因为密封是一个破坏性的变化，所以它必须永远存在，即使它被破坏了。这是一个我们不知道是否有客户需要的功能，这是一个我们不知道是否可以滥用的功能。这是一个坏特性。这份名单被拆封是一个错误，这个错误在未来不会重演 不可变类型。看，没有理由@EricLippert已经解释了原因，我同意他的观点，但这与问题无关。这些理由对你来说可能不太有说服力，但将其描述为“没有理由”是不公平的。你最初的问题只是想理解这里的原因？而这种推理是由一个非常有学问的人提供的！微软员工。你应该把它作为答案，继续你的生活。