.net - .NET 设计指南是否建议在 IEnumerable<T> 上返回 List<T>？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

6年前关闭。




Improve this question




背景:我给我的同事发了一封电子邮件，告诉他们Enumerable.Empty<T>()。作为一种返回空集合而不执行 return new List<T>(); 之类的方法我收到回复说缺点是它没有公开特定类型:

That does present a tiny issue. It’s always good to be as specific as possible about your return type* (so if you’re returning a List<>, make that your return type); that’s because things like Lists and Arrays have extra methods that are useful. Plus it also can be useful in making performance considerations when using the collection from the calling method.

The trick below unfortunately forces you to return an IEnumerable, which is about as non-specific as possible, right? :(

* This is actually from the .NET Design Guidelines. Stated reasons in the guidelines are the same as I’m mentioning here, I believe.

这似乎与我所学到的完全相反，并且尽我所能尝试，我在设计指南中找不到这个确切的建议。我确实找到了这样的一小块:

DO return a subclass of Collection<T> or ReadOnlyConnection<T> from very commonly used methods and properties.

后面有一个代码片段，但根本没有更多理由。

话虽如此，这是一个真实且被接受的指导方针(第一个 block 引用中描述的方式)吗？还是被误解了？我能找到的所有其他 SO 问题的答案都倾向于 IEnumerable<T>作为返回类型。也许最初的 .NET 指南已经过时了？

或者，也许它不是那么清楚？是否有一些权衡需要考虑？什么时候返回更具体的类型是个好主意？是否曾建议返回一个具体的泛型类型，或者只返回一个更具体的接口(interface)，如 IList<T>和 ReadOnlyCollection<T> ?

Answer 1

两种风格都有原因:

具体 :您向调用者保证您将始终返回此类型。即使您的实现发生变化。你能信守 promise 吗？如果是，请具体说明让来电者受益。更多派生类型具有更多特性。

通用 : 如果您可能会更改相关方法或属性的底层实现，您不能 promise List<T> .也许你可以 promise IList<T>或自定义集合类(您可以稍后更改)。

.NET 框架 BCL 与数组或自定义集合类一起使用。他们需要提供 100% 稳定的 API，所以他们需要小心。

在普通的软件项目中，您可以更改调用者(.NET 框架的人不能)，因此您可以更加宽容。如果你 promise 太多，并且需要在一年后改变它，你可以做到(付出一些努力)。

只有一件事总是错误的:说一个人应该总是做(1)或(2)。总是总是错的。

下面是一个例子，说明特异性显然是正确的选择:

    public static T[] Slice<T>(this T[] list, int start, int count)
    {
        var result = new T[count];
        Array.Copy(list, start, result, 0, count);
        return result;
    }

只有一种合理的实现可能，所以我们可以明确地保证返回类型是一个数组。我们永远不需要返回列表。

另一方面，从某个持久存储中返回所有用户的方法可能会在内部发生很大变化。数据甚至可能比可用内存大，这需要流式传输。我们应该选择IEnumerable<User> .