使用IReadOnlyCollection代替IEnumerable获取参数，避免可能的多重枚举IReadOnlyCollection。我也总是使用IEnumerable将集合公开为返回类型和参数，因为它可以是不可变的和延迟执行的。但是，我越来越担心我的代码中必须枚举参数以避免ReSharper可能给出的多重枚举警告的位置激增。我理解为什么ReSharper建议这样做，并且我同意它建议的代码（如下）以确保封装（即，没有关于调用者的假设）。Foo[]arr=colasFoo[]??col.ToArray();但是，我发现这段代码的重复性造成了污染，我同意一些消息来源的观点，即IReadOnlyCollection是更好的选择，尤其是在这篇文章中提出的一个观点，其中指出：最近，我一直在思考的优点和缺点返回IEnumerable。从好的方面来说，它与接口一样小，因此作为方法作者，它比IList或（天堂禁止）等较重的替代方案更灵活。但是，正如我在上一篇文章中概述的那样，IEnumerable返回会诱使调用者违反Liskov替换原则。它们很容易与LINQ扩展方法（如Last()和Count()）一起使用，IEnumerable不保证其语义。我们需要的是一种更好的方法来锁定不会使这种诱惑如此突出的返回集合。（我记得BarneyFife以艰难的方式学习了这一课。）输入IReadOnlyCollection，这是.NET4.5中的新功能。它只向IEnumerable添加一个属性：Count属性。通过承诺计数，您可以向调用者保证您的IEnumerable确实有一个终点。然后他们可以清楚地使用像Last()这样的LINQ扩展方法。但是，观察者可能已经注意到，本文仅讨论如何使用IReadOnlyCollection作为返回类型。我的问题是，相同的论点是否适用于将它用于参数？对此的任何理论思想或评论也将不胜感激。事实上，我考虑使用IReadOnlyCollection的一般经验法则是，如果使用IEnumerable（与ReSharper警告相比），可能会有多个枚举。否则，使用IEnumerable。进一步思考后，我得出结论，根据我在问题中提到的那篇文章，确实可以使用IReadOnlyCollection作为参数，但仅限于明确枚举它的函数。如果枚举是基于其他参数、对象状态或工作流的条件，它仍应作为IEnumerable传递，以在语义上确保延迟计算。以上是C#学习教程：使用IReadOnlyCollection代替IEnumerable获取参数，避免可能的多次枚举共享所有内容。如果对大家有用，需要进一步了解C#学习教程，还望大家多多关注～本文整理自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
