List <T>或IList <T> [关闭]

谁能向我解释为什么我要在C＃中使用IList over List？

相关问题：为什么认为暴露不好List<T>

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

如果您仅在内部使用它，则可能不太在意，List<T>可以使用。

不太受欢迎的答案是程序员喜欢假装他们的软件将在全球范围内重复使用，实际上，大多数项目将由少量人员维护，但是无论界面相关的声音如何，您都在欺骗你自己

建筑宇航员。您编写自己的IList将任何内容添加到.NET框架中已添加的内容的机会非常渺茫，以至于理论上的果冻只能用于“最佳实践”。

显然，如果询问您在面试中使用哪一个，您会说出IList，微笑，并且都对自己如此聪明而感到满意。或面向公众的API，即IList。希望你明白我的意思。

接口是一个承诺（或合同）。

与承诺一样，越小越好。

有人说“总是用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>没有。

Liskov替换原理（简化）指出，应该可以使用派生类型代替基本类型，而无需其他前提条件或后置条件。

感觉好像违反了Liskov替代原则。

 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[]什么？

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

在很多使用抽象而不是具体类型的论点中，单一责任原则/接口隔离原则具有吸引力，这取决于最窄的接口。在大多数情况下，如果您使用的是a，List<T>并且您认为可以使用更窄的界面-为什么不IEnumerable<T>呢？如果您不需要添加项目，则通常更合适。如果您需要添加到集合中，请使用具体类型，List<T>。

对我IList<T>（和ICollection<T>）来说，这是.NET框架中最糟糕的部分。 IsReadOnly违反了最少惊讶的原则。Array不允许添加，插入或删除项目的类（例如）不应使用Add，Insert和Remove方法实现接口。（也可以看看 /software/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>，它指示是否可以从集合中添加或删除项目。但这只是使事情真正混乱，它并不能说明是否可以替换它们，对于Arrays（返回IsReadOnlys == true）来说可以。

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

List<T>是的特定实现IList<T>，它是一个容器，可以T[]使用整数索引以与线性数组相同的方式进行寻址。当指定IList<T>方法的参数类型时，仅指定需要容器的某些功能。

例如，接口规范没有强制使用特定的数据结构。在实现List<T>访问，删除和添加线性数组元素时，具有相同的性能。但是，您可以想象有一个由链表支持的实现，在该实现的末尾添加元素更便宜（恒定时间），而随机访问则要昂贵得多。（请注意，.NET LinkedList<T>并没有实现IList<T>。）

本示例还告诉您，在某些情况下，您需要在参数列表中指定实现而不是接口：在本示例中，每当您需要特定的访问性能特征时。通常可以通过特定的容器实现来保证这一点（List<T>文档：“它IList<T>使用其大小根据需要动态增加的数组来实现通用接口。”）。

此外，您可能需要考虑公开所需的最少功能。例如。如果你不需要更改列表的内容做，你应该考虑使用IEnumerable<T>，其IList<T>延伸。

我会稍微解决这个问题，而不是说明为什么要在具体实现上使用接口，而是要说明为什么要使用具体实现而不是接口。如果您无法证明其合理性，请使用该界面。

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

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

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

TDD和OOP的原理通常是编程到接口而不是实现。

在这种特定情况下，由于您本质上是在谈论一种语言构造，而不是自定义的一种，所以通常没关系，例如，说您发现List不支持您所需要的东西。如果您在应用程序的其余部分中使用了IList，则可以使用自己的自定义类扩展List，并且仍然可以在不进行重构的情况下将其传递出去。

这样做的成本很小，为什么以后不为自己省去头痛呢？这就是接口原理的全部内容。

public void Foo(IList<Bar> list)
{
     // Do Something with the list here.
}

在这种情况下，您可以传入任何实现IList <Bar>接口的类。如果改用List <Bar>，则只能传入List <Bar>实例。

IList <Bar>方式比List <Bar>方式宽松得多。

假设这些List vs IList问题（或答案）均未提及签名差异。（这就是为什么我在SO上搜索此问题的原因！）

因此，这里是List包含的方法，至少在.NET 4.5（大约2015年）中，这些方法在IList中找不到。

• 添加范围
• 只读
• 二进制搜索
• 容量
• 全部转换
• 存在
• 找
• 找到所有
• 查找索引
• 最后查找
• FindLastIndex
• 每次
• 获取范围
• 插入范围
• LastIndexOf
• 移除所有
• 移除范围
• 逆转
• 分类
• 数组
• 修剪过量
• TrueForAll

在实现上使用接口的最重要情况是API的参数。如果您的API使用List参数，那么使用它的任何人都必须使用List。如果参数类型为IList，则调用者具有更大的自由度，并且可以使用您从未听说过的类，这些类甚至在编写代码时都不存在。

如果.NET 5.0替换System.Collections.Generic.List<T>为System.Collection.Generics.LinearList<T>。.NET始终拥有该名称，List<T>但他们保证这IList<T>是合同。因此，恕我直言，我们（至少是我）不应该使用某人的名字（尽管在本例中为.NET），但以后会遇到麻烦。

在使用的情况下IList<T>，调用者总是要保证工作正常，实现者可以自由地将基础集合更改为的任何替代具体实现。IList

上面的大多数答案中基本上都说明了所有概念，有关为什么要在具体实现中使用接口。

IList<T> defines those methods (not including extension methods)

IList<T> MSDN链接

1. 加
2. 明确
3. 包含
4. 复制到
5. GetEnumerator
6. 指数
7. 插
8. 去掉
9. RemoveAt

List<T> 实现了这九种方法（不包括扩展方法），此外，它还具有约41种公共方法，这权衡了您在应用程序中使用哪种方法。

List<T> MSDN链接

您可能会因为定义IList或ICollection将为接口的其他实现打开。

您可能需要一个IOrderRepository来定义IList或ICollection中的订单集合。然后，您可以使用不同类型的实现来提供订单列表，只要它们符合IList或ICollection定义的“规则”即可。

根据其他发布者的建议，IList <>几乎总是首选，但是请注意，通过WCF DataContractSerializer进行一个以上的序列化/反序列化周期来运行IList <>时，.NET 3.5 sp 1中存在一个错误。

现在有一个SP可以解决此错误：KB 971030

该接口确保您至少得到了您期望的方法 ; 了解接口的定义，即。所有继承该接口的类都可以实现的所有抽象方法。因此，如果某人用他从接口继承的一些附加功能之外的方法，用几种方法创建自己的巨大类，而这些方法对您没有用，那么最好使用对子类的引用（在这种情况下，接口）并为其分配具体的类对象。

另一个优点是您的代码不会对具体类进行任何更改，因为您只订阅具体类的方法中的几种，只要具体类从您所继承的接口继承，这些代码就将存在。使用。因此它对您来说是安全的，并为编写具体实现以更改其具体类或添加更多功能的编码人员提供了自由。

您可以从多个角度看待这个论点，包括一种纯粹的面向对象的方法，该方法表示针对接口而不是实现进行编程。考虑到这一点，使用IList遵循与传递和使用您从头定义的接口相同的原理。我也相信接口通常提供的可伸缩性和灵活性因素。如果需要扩展或更改实现IList <T>的类，则无需更改使用方代码；否则，无需更改。它知道IList Interface合同遵守什么。但是，在更改的类上使用具体实现和List <T>可能会导致调用代码也需要更改。这是因为遵守IList <T>的类可以保证某些行为，而使用List <T>的具体类型不能保证这种行为。

还具有在类上修改List <T>的默认实现的能力，例如，实现IList <T>的.Add，.Remove或任何其他IList方法为开发人员提供了很多灵活性和强大功能，否则将进行预定义按列表<T>

通常，一种好的方法是在面向公众的API中使用IList（在适当的情况下，并且需要列表语义），然后在内部使用List来实现API。这使您可以更改为IList的其他实现，而不会破坏使用您的类的代码。

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

请注意，如果您的API仅用于foreach循环等中，那么您可能需要考虑仅公开IEnumerable。