Should I favour IEnumerable<T> or Arrays? [closed]

Question

In many projects I work on, whenever I have to return a read only collection, I use the IEnumerable<T> interface and make it type specific like so:

Public ReadOnly Property GetValues() As IEnumerable(Of Integer)     Get         'code to return the values'     End Get End Property 

Most of the time, I return a List but in some functions and read only properties I return an array which also serves the purpose alright by kind courtesy of Extension Methods.

My question is am I violating any design principles by returning IEnumerable<T>s instead of specific types (e.g.: List<T>, HashSet<T>, Stack<T> or Arrays)?

Answer 1

I generally prefer IEnumerable<T> as well. The main thing is to ask yourself what actual (even minimum) functionality is being returned from the method (or passed to it, in the case of a method argument).

If all you need to do is enumerate over a result set, then IEnumerable<T> does exactly that. No more, no less. This leaves you the flexibility to return more specific types in certain cases if need be without breaking the footprint of the method.

Answer 2

David's answer pretty much covers it; IEnumerable<T> is best practice in general. You can see this by looking at most of the newer framework methods.

I just wanted to add that, since you specified read-only collection in your original question, you can enforce this by calling .ToList().AsReadOnly() on your IEnumerable<T> instance before returning it. This will create a concrete instance of ReadOnlyCollection<T> for you to return. Your return type should still be IEnumerable<T>, since the caller doesn't need to know that you are specifically returning a ReadOnlyCollection<T>, but in this way you prevent the caller from shooting himself in the foot.

(Without this step, the caller could e.g. attempt to cast the IEnumerable<T> it gets from your method to List<T>. If the cast succeeds, which it will if that's what you were originally working with, the caller can then modify the same list you are operating on inside your method, with possibly unanticipated consequences.)