IEnumerable vs T[]

前端 未结 7 1261
天命终不由人
天命终不由人 2021-01-07 20:43

I just realize that maybe I was mistaken all the time in exposing T[] to my views, instead of IEnumerable.

Usually, for this kind

相关标签:
7条回答
  • 2021-01-07 21:02

    Since Array class implements the System.Collections.Generic.IList<T>, System.Collections.Generic.ICollection<T>, and System.Collections.Generic.IEnumerable<T> generic interfaces, I would use IEnumerable, unless you need to use these interfaces.

    http://msdn.microsoft.com/en-us/library/system.array.aspx

    0 讨论(0)
  • 2021-01-07 21:03

    Your gut feeling is correct, if all the view cares about, or should care about, is having an enumerable, that's all it should demand in its interfaces.

    0 讨论(0)
  • 2021-01-07 21:05

    T[] (one sized, zero based) also implements ICollection<T> and IList<T> with IEnumerable<T>.

    Therefore if you want lesser coupling in your application IEnumerable<T> is preferable. Unless you want indexed access inside foreach.

    0 讨论(0)
  • 2021-01-07 21:08

    Given that changing the code from an array to IEnumerable at a later date is easy, but changing it the other way is not, I would go with a IEnumerable until you know you need the small spead benfit of return an array.

    0 讨论(0)
  • 2021-01-07 21:10

    What is it logically (conceptually) from the outside?

    If it's an array, then return the array. If the only point is to enumerate, then return IEnumerable. Otherwise IList or ICollection may be the way to go.

    If you want to offer lots of functionality but not allow it to be modified, then perhaps use a List internally and return the ReadonlyList returned from it's .AsReadOnly() method.

    0 讨论(0)
  • 2021-01-07 21:12

    IEnumerable<T> is generally a better choice here, for the reasons listed elsewhere. However, I want to bring up one point about Count(). Quintin is incorrect when he says that the type itself implements Count(). It's actually implemented in Enumerable.Count() as an extension method, which means other types don't get to override it to provide more efficient implementations.

    By default, Count() has to iterate over the whole sequence to count the items. However, it does know about ICollection<T> and ICollection, and is optimised for those cases. (In .NET 3.5 IIRC it's only optimised for ICollection<T>.) Now the array does implement that, so Enumerable.Count() defers to ICollection<T>.Count and avoids iterating over the whole sequence. It's still going to be slightly slower than calling Length directly, because Count() has to discover that it implements ICollection<T> to start with - but at least it's still O(1).

    The same kind of thing is true for performance in general: the JITted code may well be somewhat tighter when iterating over an array rather than a general sequence. You'd basically be giving the JIT more information to play with, and even the C# compiler itself treats arrays differently for iteration (using the indexer directly).

    However, these performance differences are going to be inconsequential for most applications - I'd definitely go with the more general interface until I had good reason not to.

    0 讨论(0)
提交回复
热议问题