IList<T>是一个接口，所以你可以继承另一个类，仍然实现IList<T>，而继承List<T>阻止你这样做。

例如，如果有一个类a，你的类B继承了它，那么你不能使用List<T>

class A : B, IList<T> { ... }

TDD和OOP的一个原则通常是针对接口编程，而不是实现。

在这个特定的情况下，因为你实际上是在谈论一个语言结构，而不是一个自定义的，这通常并不重要，但比如说，你发现List不支持你需要的东西。如果你在应用的其余部分使用了IList，你可以用你自己的自定义类扩展List，并且仍然能够在不重构的情况下传递它。

这样做的成本是最小的，为什么不省去以后的麻烦呢?这就是界面原则。

接口是一种承诺(或契约)。

承诺总是这样，越小越好。

不太流行的答案是，程序员喜欢假装他们的软件在世界各地都可以重用，而事实上，大多数项目将由少数人维护，无论界面相关的声音有多好，你都在欺骗自己。

架构宇航员。你编写自己的IList，为。net框架中已经存在的IList添加任何东西的机会是如此渺茫，以至于它只是理论上的“最佳实践”。

很明显，如果你被问到在面试中使用什么，你会说IList，微笑，两个人看起来都为自己的聪明感到高兴。或者对于一个面向公众的API, IList。希望你明白我的意思。

如果您通过其他人将使用的库来公开类，则通常希望通过接口而不是具体实现来公开类。如果您决定稍后更改类的实现以使用不同的具体类，这将有所帮助。在这种情况下，库的用户不需要更新他们的代码，因为接口没有改变。

如果您只是在内部使用它，您可能不会太在意，使用List<T>可能就可以了。

通常，一个好的方法是在面向公共的API中使用IList(在适当的情况下，并且需要列表语义)，然后在内部使用list来实现API。这允许您在不破坏使用您的类的代码的情况下更改到不同的IList实现。

类名List可能在下一个。net框架中改变，但接口永远不会改变，因为接口是契约。

注意，如果你的API只会在foreach循环中使用，那么你可能会考虑只暴露IEnumerable。