MyClass[] array;
List<MyClass> list;
当一个比另一个更可取的情况是什么?,为什么?
MyClass[] array;
List<MyClass> list;
当一个比另一个更可取的情况是什么?,为什么?
当前回答
当集合本身的不可变性是客户端和提供者代码之间契约的一部分时(不一定是集合中项目的不可变性)以及当IEnumerable不合适时,应该优先使用数组而不是List。
例如,
var str = "This is a string";
var strChars = str.ToCharArray(); // returns array
很明显,对"strChars"的修改不会改变原始的"str"对象,无论实现级是否了解"str"的底层类型。
但是假设
var str = "This is a string";
var strChars = str.ToCharList(); // returns List<char>
strChars.Insert(0, 'X');
在这种情况下,仅仅从代码片段中还不清楚insert方法是否会改变原始的“str”对象。它需要String的实现级知识来做出判断,这打破了契约式设计方法。在String的情况下,这不是一个大问题,但在几乎所有其他情况下,这可能是一个大问题。将List设置为只读确实有帮助,但会导致运行时错误,而不是编译时错误。
其他回答
实际上,我只是想添加一个链接,我很惊讶还没有提到:Eric的Lippert的博客条目“数组被认为有点有害”。
您可以从标题中判断,它建议在任何可行的地方使用集合——但正如Marc正确地指出的那样,在很多地方,数组确实是唯一可行的解决方案。
请记住,使用List是不可能做到这一点的:
List<string> arr = new List<string>();
arr.Add("string a");
arr.Add("string b");
arr.Add("string c");
arr.Add("string d");
arr[10] = "new string";
它生成一个异常。
相反,使用数组:
string[] strArr = new string[20];
strArr[0] = "string a";
strArr[1] = "string b";
strArr[2] = "string c";
strArr[3] = "string d";
strArr[10] = "new string";
但是对于数组,不会自动调整数据结构的大小。您必须手动或使用Array管理它。调整方法。
一个技巧是用一个空数组初始化List。
List<string> arr = new List<string>(new string[100]);
arr[10] = "new string";
但在这种情况下,如果你使用Add方法添加一个新元素,它将被注入到列表的末尾。
List<string> arr = new List<string>(new string[100]);
arr[10] = "new string";
arr.Add("bla bla bla"); // this will be in the end of List
尽管其他答案推荐List<T>,但在处理以下问题时,您将希望使用数组:
图像位图数据 其他底层数据结构(如网络协议)
数组Vs.列表是典型的可维护性Vs.性能问题。几乎所有开发人员都遵循的经验法则是,您应该兼顾两者,但当两者发生冲突时,请选择可维护性而不是性能。该规则的例外情况是当性能已经被证明是一个问题时。如果你把这个原则应用到数组Vs.列表中,你会得到这样的结果:
使用强类型列表,直到遇到性能问题。如果遇到性能问题,请决定是否使用数组对解决方案的性能更有利,而不是在维护方面对解决方案造成损害。
Lists in .NET are wrappers over arrays, and use an array internally. The time complexity of operations on lists is the same as would be with arrays, however there is a little more overhead with all the added functionality / ease of use of lists (such as automatic resizing and the methods that come with the list class). Pretty much, I would recommend using lists in all cases unless there is a compelling reason not to do so, such as if you need to write extremely optimized code, or are working with other code that is built around arrays.