Why create an IEnumerable?

Question

I don't understand why I'd create an IEnumerable. Or why it's important.

I'm looking at the example for IEnumerable: http://msdn.microsoft.com/en-us/library/system.collections.ienumerable.aspx

But I can basically do the same thing if I just went:

 List<Person> people = new List<Person>();

so what's IEnumerable good for? Can you give me a situation where I'd need to create a class that implements IEnumerable?

Answer 1

IEnumerable is an interface, it exposes certain things to the outside. While you are completely right, you could just use a List<T>, but List<T> is very deep in the inheritance tree. What exactly does a List<T>? It stores items, it offers certain methods to Add and Remove. Now, what if you only need the "item-keeping" feature of a List<T>? That's what an IEnumerable<T> is - an abstract way of saying "I want to get a list of items I can iterate over". A list is "I want to get a collection which I can modify, can access by index and iterate". List<T> offers a lot more functionality than IEnumerable<T> does, but it takes up more memory. So if a method is taking an IEnumerable<T>, it doesn't care what exactly it gets, as long as the object offers the possibilites of IEnumerable<T>.

Also, you don't have to create your own IEnumerable<T>, a List<T> IS an IEnumerable<T>!

Answer 2

It's rare that nowdays you need to create your own container classes, as you are right there alreay exists many good implementations.

However if you do create your own container class for some specific reason, you may like to implement IEnumerable or IEnumerable<T> because they are a standard "contract" for itteration and by providing an implementation you can take advantage of methods/apis that want an IEnumerable or IEnumerable<T> Linq for example will give you a bunch of useful extension methods for free.

Answer 3

Here is one situation that I think I have to implement IEnumerable but not using List<>

I want to get all items from a remote server. Let say I have one million items going to return. If you use List<> approach, you need to cache all one million items in the memory first. In some cases, you don't really want to do that because you don't want to use up too much memory. Using IEnumerable allows you to display the data on the screen and then dispose it right away. Therefore, using IEnumerable approach, the memory footprint of the program is much smaller.

Answer 4

Today, you generally wouldn't use IEnumerable anymore unless you were supporting software on an older version of the framework. Today, you'd normally use IEnumerable<T>. Amongst other benefits, IEnumerable fully implements all of the LINQ operations/extensions so that you can easily query any List type that implements IEnumerable<T> using LINQ.

Additionally, it doesn't tie the consumer of your code to a particular collection implementation.

Answer 5

IEnumerable is useful if you have a collection or method which can return a bunch of things, but isn't a Dictionary, List, array, or other such predefined collection. It is especially useful in cases where the set of things to be returned might not be available when one starts outputting it. For example, an object to access records in a database might implement iEnumerable. While it might be possible for such an object to read all appropriate records into an array and return that, that may be impractical if there are a lot of records. Instead, the object could return an enumerator which could read the records in small groups and return them individually.

Answer 6

IEnumerable provides means for your API users (including yourself) to use your collection by the means of a foreach. For example, i implemented IENumerable in my Binary Tree class so i could just foreach over all of the items in the tree without having to Ctrl+C Ctrl+V all the logic required to traverse the tree InOrder.

Hope it helps :)

Answer 7

When a built in container fits your needs you should definitely use that, and than IEnumerable comes for free. When for whatever reason you have to implement your own container, for example if it must be backed by a DB, than you should make sure to implement both IEnumerable and IEnumerable<T> for two reasons:

1. It makes foreach work, which is awesome
2. It enables almost all LINQ goodness. For example you will be able to filter your container down to objects that match a condition with an elegant one liner.

Answer 8

What if you want to enumerate over a collection that is potentially of infinite size, such as the Fibonacci numbers? You couldn't do that easily with a list, but if you had a class that implemented IEnumerable or IEnumerable<T>, it becomes easy.

Answer 9

An IList can be thought of as a particular implementation of IEnumerable. (One that can be added to and removed from easily.) There are others, such as IDictionary, which performs an entirely different function but can still be enumerated over. Generally, I would use IEnumerable as a more generic type reference when I only need an enumeration to satisfy a requirement and don't particularly care what kind it is. I can pass it an IList and more often than not I do just that, but the flexibility exists to pass it other enumerations as well.

Answer 10

Lists are, of course IEnumerable - As a general rule, you want to be specific on what you output but broad on what you accept as input eg:

You have a sub which loops through a list of objects and writes something to the console...

You could declare the parameter is as either IEnumerable<T> or IList<T> (or even List<T>). Since you don't need to add to the input list, all you actually need to do is enumerate - so use IEnumerable - then your method will also accept other types which implement IEnumerable including IQueryable, Linked Lists, etc...

You're making your methods more generic for no cost.

Answer 11

It's my understanding that IEnumerable is provided to you as an interface for creating your own enumerable class types.

I believe a simple example of this would be recreating the List type, if you wanted to have your own set of features (or lack thereof) for it.