返回接口或类

假设我有一个方法

public List<User> GetBatchOfUsers(IEnumerable<int> userIDs)
{
    List<User> users = new List<User>();

    // some database stuff

    return users;
}

我已经读过，返回一个接口（IList或者IEnumerable）比返回a 更好List。我听到的一些说法是，它隐藏了数据，并使API开发人员可以灵活地在以后更改数据的内部表示形式。

我只返回an的担心IEnumerable是您失去了功能，例如随机访问和Count属性。

我知道接受a IEnumerable作为参数是有意义的，因为它为用户提供了将数据发送到我的方法的最佳灵活性，这是方法操作的最低要求。

返回类型的最佳实践是什么？

通常，您可以从接口开始，只有在发现您比预期更频繁地使用额外方法时，才开始将具体类型作为返回类型。

好吧，如果您返回一个接口，则可以保留更大的灵活性。您可以稍后更改实现以返回其他具体类型。另一方面，它显然为呼叫者提供了较少的信息，因此他们可能无法执行某些操作。（例如：如果返回List<T>，则调用方可以使用ConvertAll等...，如果仅声明返回就不能使用IList<T>。）在某些情况下，值得指定具体类型。

关于Count或Sort方法，没有标准的收集接口。但是，您可以编写扩展方法来对任何IList进行排序或计数。

如果您需要集合中有个Count，可以使用ICollection<T>，这足够通用了。

您返回正在定义的方法的谨慎选择。您正在执行的是返回一系列项目（重点在项目上）还是在返回项目集合（重点在整个集合上）？在收集的实现中允许差异是否值得？如果使用生成器永远都没有意义，HashSet那就使用List。

特定于示例方法：您是对的，正确的是，返回IEnmuerable<T>将意味着您将失去Count和索引的功能（尽管您可以使用LINQ方法Count()和ElementAt()，如果实际使用它们的类型可以有效地实现IList<T>）。

如果返回IList<T>，则可能会丢失一些功能，但是一般而言，获得该功能是值得的。

但更好的是介于IEnumerable<T>和之间IList<T>，因为消费者很可能对返回的集合进行变异是没有意义的，但使用Count或建立索引对消费者来说却是有意义的。

在.NET 4.5，存在这样的接口：IReadOnlyList<T>。