Should I Always Return Ienumerable<T> Instead of Ilist<T>

Should I always return IEnumerableT instead of IListT?

It really depends on why you are using that specific interface.

For example, IList<T> has several methods that aren't present in IEnumerable<T>:

• IndexOf(T item)
• Insert(int index, T item)
• RemoveAt(int index)

and Properties:

• T this[int index] { get; set; }

If you need these methods in any way, then by all means return IList<T>.

Also, if the method that consumes your IEnumerable<T> result is expecting an IList<T>, it will save the CLR from considering any conversions required, thus optimizing the compiled code.

Should I return an IEnumerable or IList?

There is a hierarchy here:

interface IList<T> : ICollection<T> { } 
interface ICollection<T> : IEnumerable<T> { }

You want to aim for the least possible coupling, so return an IEnumerable<T> if that is enough. It probably will be.

Return an IList<T> if the situation requires that the caller gets a List that it can use to Add/Insert/Remove. But even then it might be better if the caller created his own List from the IEnumerable collection.

Why does IEnumerableT.ToListT() return ListT instead of IListT?

Returning List<T> has the advantage that those methods of List<T> that are not part of IList<T> are easily used. There are a lot of things you can do with a List<T> that you cannot do with a IList<T>.

In contrast, Lookup<TKey, TElement> has only one available method that ILookup<TKey, TElement> does not have (ApplyResultSelector), and you probably would not end up using that anyway.

Why should I return IListT over ListT?

The reason is so that your method can be used with anything that implements IList<T>, and not just a List. It gets even worse, though, since the advent of Linq, I've started making a lot of stuff return Enumerable<T> or even just IEnumerable!

I am not sure I understand the difficulty, though. If something is returning an actual list, and its return depends on that, or its use is specific to that, then it should return List<T>. If not, then you should have no need to cast it to a List.

Is the lost of efficiency worth returning IEnumerable instead of List?

If the caller actually needs a list, return a list (if that's what you have). Returning an IEnumerable when you already have a list, and when you know the caller is going to need a list, is just being wasteful, and for no real benefit.

If you feel that there is a chance that you'll be changing the underlying type of the object you are returning in future versions of the method it can, potentially, make it a bit easier on the library implementer to return an interface instead, but it's easier on the caller of the method when a more derived type is returned (they have the ability to do more with it than if they are just given an interface).

It is the reverse with input parameters. When passing parameters in the more derived the type the more "power" the library implementer has to work with the type, especially in future revisions, but using a much less restrictive type makes life easier on the caller of your library, as they don't need to convert what they have to what your method accepts.

This makes these decisions something to think about a fair bit when writing a libraries public API. You need to consider how much "power" you need right now, as well as how much you think you might need in the future. Once you know how restrictive/general the types need to be for you to do your job, you can then work to make your methods more convenient to use for callers. There is no one answers that will apply in every case. Saying that you should always return IEnumerable instead of List isn't proper, just the same as saying that you should always return List is also improper. You need to make a judgement call based on the specific situation you are in.

OK to return an internal ListT as an IEnumerableT or ICollectionT?

Not only there's nothing wrong with it, but it's actually good practice: expose only what is strictly necessary. That way, the caller can't rely on the fact that the method will return a List<T>, so if for some reason you need to change the implementation to return something else, you won't break your contract. However the calling code might break if it (incorrectly) made assumptions about what the method actually returns.

What is the difference between returning IList vs List, or IEnumerable vs ListClass. I want to know which is better to return

There is no such a type that is always better to return. It's a decision you should make based on your design/performance/etc goals.

IEnumerable<T> is nice to use when you want to represent sequence of items, that you can iterate over, but you don't want to allow modifications(Add, Delete etc).

IList<T> gives you everything you could get using IEnumerable<T>, plus operations that give you more control over a collection: Add, Delete, Count, Index access etc.

List<T> is a concrete implementation of IList<T>. I would say that almost always it's better to expose IList<T> interface from your methods rather that List<T> implementation. And it's not just about lists - it's a basic design principle to prefer interfaces over concrete implementations.

Ok, now about non-generic versions IEnumerable, IList, List:
They actually came from very early versions of .NET framework, and life is much better using generic equivalents.

And few words about performance:
IEnumerable<T>(with IEnumerator<T>) is actually an iterator which allows you to defer some computations until later. It means that there is no need to allocate memory right away for storing amounts of data(of course, it's not the case when you have, say, array behind iterator). You can compute data gradually as needed. But it means that these computations might be performed over and over again(say, with every foreach loop). On the other hand, with List you have fixed data in memory, with cheap Index and Count operations. As you see, it's all about compromise.

---

Related Topics