Does IEnumerable always imply a collection?

Just a quick question regarding IEnumerable:

Does IEnumerable always imply a collection? Or is it legitimate/viable/okay/whatever to use on a single obj开发者_运维知识库ect?

The IEnumerable and IEnumerable<T> interfaces suggest a sequence of some kind, but that sequence doesn't need to be a concrete collection.

For example, where's the underlying concrete collection in this case?

foreach (int i in new EndlessRandomSequence().Take(5))
{
    Console.WriteLine(i);
}

// ...

public class EndlessRandomSequence : IEnumerable<int>
{
    public IEnumerator<int> GetEnumerator()
    {
        var rng = new Random();
        while (true) yield return rng.Next();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

It is always and mandatory that IEnumerable is used on a single object - the single object is always the holder or producer of zero or more other objects that do not necessarily have any relation to IEnumerable.

It's usual, but not mandatory, that IEnumerable represents a collection.

Enumerables can be collections, as well as generators, queries, and even computations.

Generator:

IEnumerable<int> Generate(
    int initial,
    Func<int, bool> condition,
    Func<int, int> iterator)
{
    var i = initial;
    while (true)
    {
        yield return i;
        i = iterator(i);
        if (!condition(i))
        {
            yield break;
        }
    }
}

Query:

IEnumerable<Process> GetProcessesWhereNameContains(string text)
{
    // Could be web-service or database call too
    var processes = System.Diagnostics.Process.GetProcesses();
    foreach (var process in processes)
    {
        if (process.ProcessName.Contains(text))
        {
            yield return process;
        }
    }
}

Computation:

IEnumerable<double> Average(IEnumerable<double> values)
{
    var sum = 0.0;
    var count = 0;
    foreach (var value in values)
    {
        sum += value;
        yield return sum/++count;
    }
}

LINQ is itself a series of operators that produce objects that implement IEnumerable<T> that don't have any underlying collections.

Good question, BTW!

NB: Any reference to IEnumerable also applies to IEnumerable<T> as the latter inherits the former.

Yes, IEnumerable implies a collection, or possible collection, of items.

The name is derived from enumerate, which means to:

1. Mention (a number of things) one by one.
2. Establish the number of.

According to the docs, it exposes the enumerator over a collection.

You can certainly use it on a single object, but this object will then just be exposed as an enumeration containing a single object, i.e. you could have an IEnumerable<int> with a single integer:

IEnumerable<int> items = new[] { 42 };

IEnumerable represents a collection that can be enumerated, not a single item. Look at MSDN; the interface exposes GetEnumerator(), which

...[r]eturns an enumerator that iterates through a collection.

Yes, IEnumerable always implies a collection, that is what enumerate means.

What is your use case for a single object?

I don't see a problem with using it on a single object, but why do want to do this?

I'm not sure whether you mean a "collection" or a .NET "ICollection" but since other people have only mentioned the former I will mention the latter.

http://msdn.microsoft.com/en-us/library/92t2ye13.aspx

By that definition, All ICollections are IEnumerable. But not the other way around. But most data structure (Array even) just implement both interfaces.

Going on this train of thought: you could have a car depot (a single object) that does not expose an internal data structure, and put IEnumerable on it. I suppose.