The interface ensures that you at least get the methods you are expecting; being aware of the definition of the interface ie. all abstract methods that are there to be implemented by any class inheriting the interface. so if some one makes a huge class of his own with several methods besides the ones he inherited from the interface for some addition functionality, and those are of no use to you, its better to use a reference to a subclass (in this case the interface) and assign the concrete class object to it.

额外的好处是，你的代码是安全的，不受任何对具体类的更改，因为你只订阅了具体类的几个方法，而这些方法是那些只要具体类继承了你正在使用的接口就会存在的方法。所以这对你来说是安全的，对编写具体实现的编码器来说是自由的，他可以改变或添加更多的功能到他的具体类中。

根据其他帖子的建议，IList<>几乎总是更可取的，但是请注意，在。net 3.5 sp 1中，当使用WCF DataContractSerializer运行IList<>多个序列化/反序列化周期时，有一个错误。

现在有一个SP来修复这个错误:KB 971030

You can look at this argument from several angles including the one of a purely OO approach which says to program against an Interface not an implementation. With this thought, using IList follows the same principal as passing around and using Interfaces that you define from scratch. I also believe in the scalability and flexibility factors provided by an Interface in general. If a class implmenting IList<T> needs to be extended or changed, the consuming code does not have to change; it knows what the IList Interface contract adheres to. However using a concrete implementation and List<T> on a class that changes, could cause the calling code to need to be changed as well. This is because a class adhering to IList<T> guarantees a certain behavior that is not guaranteed by a concrete type using List<T>.

此外，还可以在类上修改List<T>的默认实现，例如为.Add、.Remove或任何其他IList方法实现IList<T>，为开发人员提供了很大的灵活性和能力，否则由List<T>预定义

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

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

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

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

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

有人说“总是使用IList<T>而不是List<T>”。 他们想让你把你的方法签名从void Foo(List<T> input)改成void Foo(IList<T> input)。

这些人错了。

事实比这更微妙。如果返回一个IList<T>作为库的公共接口的一部分，则为将来创建自定义列表留下了一些有趣的选项。你可能永远不需要这个选项，但它是一个参数。我认为这是返回接口而不是具体类型的全部理由。值得一提的是，在这种情况下，它有一个严重的缺陷。

作为一个小小的反驳，您可能会发现每个调用者都需要一个List<T>，并且调用代码中充斥着.ToList()

但更重要的是，如果你接受一个IList作为参数，你最好小心，因为IList<T>和List<T>的行为不一样。尽管名称相似，尽管共享接口，但它们并不公开相同的契约。

假设你有这样的方法:

public Foo(List<int> a)
{
    a.Add(someNumber);
}

一位乐于助人的同事“重构”该方法以接受IList<int>。

你的代码现在坏了，因为int[]实现了IList<int>，但是是固定的大小。ICollection<T> (IList<T>的基础)的契约要求在尝试从集合中添加或删除项之前使用它检查IsReadOnly标志的代码。List<T>的契约没有。

利斯科夫替换原则(简化)指出派生类型应该能够用来代替基类型，没有额外的先决条件或后置条件。

这似乎打破了利斯科夫替换原则。

 int[] array = new[] {1, 2, 3};
 IList<int> ilist = array;

 ilist.Add(4); // throws System.NotSupportedException
 ilist.Insert(0, 0); // throws System.NotSupportedException
 ilist.Remove(3); // throws System.NotSupportedException
 ilist.RemoveAt(0); // throws System.NotSupportedException

但事实并非如此。答案是这个例子使用了IList<T>/ICollection<T>错误。如果你使用ICollection<T>，你需要检查IsReadOnly标志。

if (!ilist.IsReadOnly)
{
   ilist.Add(4);
   ilist.Insert(0, 0); 
   ilist.Remove(3);
   ilist.RemoveAt(0);
}
else
{
   // what were you planning to do if you were given a read only list anyway?
}

如果有人传递给你一个数组或列表，如果你每次都检查标志并有一个回退，你的代码将正常工作…但真的;谁会这么做?你事先不知道你的方法是否需要一个可以接受额外成员的列表吗?难道你没有在方法签名中指定吗?如果你被传递一个像int[]这样的只读列表，你到底要做什么?

您可以将List<T>替换为正确使用IList<T>/ICollection<T>的代码。您不能保证可以将IList<T>/ICollection<T>替换为使用List<T>的代码。

在使用抽象而不是具体类型的许多参数中，使用单一责任原则/接口隔离原则(依赖于尽可能窄的接口)是有吸引力的。在大多数情况下，如果您正在使用List<T>，并且您认为可以使用更窄的接口，为什么不使用IEnumerable<T>呢?如果你不需要添加项目，这通常是一个更好的选择。如果需要添加到集合，请使用具体类型List<T>。

对我来说，IList<T>(和ICollection<T>)是。net框架中最糟糕的部分。IsReadOnly违反最小意外原则。从不允许添加、插入或删除项的类(如Array)不应该实现具有添加、插入和删除方法的接口。(参见https://softwareengineering.stackexchange.com/questions/306105/implementing-an-interface-when-you-dont-need-one-of-the-properties)

IList<T>是否适合您的组织?如果有同事要求您将方法签名改为使用IList<T>而不是List<T>，请询问他们如何将元素添加到IList<T>中。如果他们不知道IsReadOnly(大多数人都不知道)，那么就不要使用IList<T>。永远。

注意IsReadOnly标志来自ICollection<T>，表示是否可以从集合中添加或删除项;但它并没有指出它们是否可以被替换，这在数组(返回isreadonly == true)的情况下是可以的。

有关IsReadOnly的更多信息，请参见msdn definition of ICollection<T>。IsReadOnly