使用最低基类型总是最好的。这使接口的实现者或方法的使用者有机会在幕后使用他们喜欢的任何东西。

对于集合，应该尽可能使用IEnumerable。这提供了最大的灵活性，但并不总是适合。

If you're working within a single method (or even in a single class or assembly in some cases) and no one outside is going to see what you're doing, use the fullness of a List. But if you're interacting with outside code, like when you're returning a list from a method, then you only want to declare the interface without necessarily tying yourself to a specific implementation, especially if you have no control over who compiles against your code afterward. If you started with a concrete type and you decided to change to another one, even if it uses the same interface, you're going to break someone else's code unless you started off with an interface or abstract base type.

我同意李的建议，接受一些参数，但不要回头。

如果你指定你的方法来返回一个接口，这意味着你以后可以自由地更改确切的实现，而消费方法永远不会知道。我认为我永远不需要从List<T>更改，但后来不得不更改为使用自定义列表库，以获得它提供的额外功能。因为我只返回了一个IList<T>，所以使用这个库的人都不需要改变他们的代码。

当然，这只需要应用于外部可见的方法(即公共方法)。我个人甚至在内部代码中使用接口，但如果你做了破坏性的更改，你可以自己更改所有的代码，这并不是严格必要的。

我不认为这类事情有严格的规则，但我通常会遵循使用尽可能轻松的方式的指导方针，直到绝对必要的时候。

例如，假设您有一个Person类和一个Group类。Group实例有很多人，所以这里使用List是有意义的。当我在Group中声明列表对象时，我将使用IList<Person>并将其实例化为list。

public class Group {
  private IList<Person> people;

  public Group() {
    this.people = new List<Person>();
  }
}

而且，如果你甚至不需要IList中的所有东西，你也可以使用IEnumerable。对于现代的编译器和处理器，我不认为它们真的有任何速度上的差异，所以这只是风格的问题。

我有两条原则:

接受最基本的工作类型 返回用户需要的最丰富的类型

因此，当编写一个接受集合的函数或方法时，不要让它接受List，而是让它接受IList<T>、ICollection<T>或IEnumerable<T>。泛型接口即使对于异构列表也仍然有效，因为System。Object也可以是T。如果您决定在以后使用Stack或其他数据结构，这样做将为您省去麻烦。如果在函数中所需要做的只是逐个遍历它，那么IEnumerable<T>才是真正需要的。

另一方面，当从函数返回一个对象时，您希望为用户提供尽可能丰富的操作集，而不需要他们进行强制转换。在这种情况下，如果内部是List<T>，返回一个List<T>的副本。

你通常最好使用最通用的可用类型，在这种情况下是IList，甚至更好的是IEnumerable接口，这样你可以在以后方便地切换实现。

然而，在。net 2.0中，有一个恼人的事情——IList没有Sort()方法。您可以使用提供的适配器:

ArrayList.Adapter(list).Sort()