列出<T>或IList <T>

Question

任何人都可以向我解释为什么我想在C#中使用IList而不是List？

相关问题:为什么暴露它被认为是不好的List<T>

Answer 1

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

如果你只是在内部使用它,你可能不在乎,使用List<T>可能没问题.

Answer 2

不那么受欢迎的答案是程序员喜欢假装他们的软件将在全世界重复使用,当事实上大多数项目将由少量人保持,然而与界面相关的声音很好,你就是在欺骗你自己.

建筑宇航员.您将编写自己的IList的可能性为.NET框架中已有的内容添加任何东西都是如此遥远,以至于它为"最佳实践"保留了理论上的果冻小点.

显然,如果你被问到你在面试中使用了什么,你会说IList,微笑,并且两个人都很高兴自己这么聪明.或者面向公众的API,IList.希望你明白我的意思.

Answer 3

接口是承诺(或合同).

因为它始终伴随着承诺 - 越小越好.

Answer 4

有人说"总是用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方法实现接口).(另请参阅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>,并指示是否可以从集合中添加或删除项目; 但只是为了真正混淆事物,它并不表示它们是否可以被替换,在Arrays的情况下(返回IsReadOnlys == true)可以.

有关IsReadOnly的更多信息,请参阅ICollection <T> .IsReadOnly的msdn定义

Answer 5

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

例如,接口规范不强制使用特定的数据结构.List<T>对于访问,删除和添加元素作为线性数组,实现具有相同的性能.但是,您可以想象一个由链接列表支持的实现,对于该实现,向末尾添加元素更便宜(恒定时间)但随机访问更加昂贵.(注意,.NET LinkedList<T>并没有实现IList<T>.)

此示例还告诉您,可能存在需要在参数列表中指定实现而非接口的情况:在此示例中,每当您需要特定的访问性能特征时.这通常可以保证容器的特定实现(List<T>文档:"它IList<T>使用一个数组来实现通用接口,该数组的大小根据需要动态增加.").

此外,您可能希望考虑公开所需的最少功能.例如.如果您不需要更改列表的内容,您应该考虑使用IEnumerable<T>,IList<T>扩展.

Answer 6

我会稍微改变一下这个问题,而不是证明为什么你应该在具体实现上使用接口,试图证明你为什么要使用具体的实现而不是接口.如果你无法证明这一点,请使用界面.

Answer 7

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

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

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

Answer 8

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

在这个特定的情况下,因为你基本上是在谈论一个语言结构,而不是一个自定义语言结构,它通常无关紧要,但比如说你发现List不支持你需要的东西.如果您在应用程序的其余部分中使用了IList,则可以使用自己的自定义类扩展List,并且仍然可以在不进行重构的情况下传递它.

这样做的成本微乎其微,为什么不在以后省去头痛呢？这就是接口原理的全部意义所在.

Answer 9

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

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

IList <Bar>方式比List <Bar>方式更松散耦合.

Answer 10

假设这些列表与IList问题(或答案)都没有提到签名差异.(这就是我在SO上搜索这个问题的原因!)

所以这里是List包含的方法,在IList中找不到,至少从.NET 4.5开始(大约2015年)

• 的AddRange
• AsReadOnly
• 二分查找
• 容量
• ConvertAll
• 存在
• 找
• 找到所有
• FindIndex
• FindLast中
• FindLastIndex
• 的ForEach
• GetRange
• InsertRange
• LastIndexOf
• 移除所有
• RemoveRange
• 相反
• 分类
• ToArray的
• TrimExcess
• TrueForAll

Answer 11

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

Answer 12

如果.NET 5.0替换System.Collections.Generic.List<T>为System.Collection.Generics.LinearList<T>..NET始终拥有该名称,List<T>但他们保证这IList<T>是一份合同.所以恕我直言,我们(至少我)不应该使用别人的名字(虽然在这种情况下它是.NET)并且以后会遇到麻烦.

在使用的情况下IList<T>,调用者总是保证工作,并且实现者可以自由地将底层集合更改为任何替代的具体实现IList

Answer 13

所有概念基本上都在上面的大多数答案中陈述,为什么使用接口而不是具体实现.

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链接