You see this term dropped into technical articles more all the time. But most of the time, there's no explaination about it. For example, I recently read this sentence thrown into an explanation intended for beginning students.
"... because the return type of this method is IEnumerable, you must use the CType function to explicitly cast the returned object to a DataView object ..."
That explanation is as confusing as some of the stuff you find on Microsoft's page!
Here's the deal with IEnumerable:
If you're an old VB6 programmer (or even Fortran programmer), you're familiar with the technique ...
For i = 1 to endOfCollection
' Do something with Collection(i)
Next i
Visual Basic, however, has another syntax that is more convenient:
For Each element in Group
' Do something with element
Next element
One reason that For Each is better is that you don't have to know where the collection starts and ends. The VB compiler figures it out for you.
To use For-Each in VB.NET, the Group has to "implement the IEnumerable interface of the System.Collections namespace or the IEnumerable interface of the System.Collections.Generic namespace." (From MSDN)
IEnumerable offers some additional advantages that we'll see In a few paragraphs. But for now, we're back to the question we started with: "What does IEnumerable mean?"
Let's start at a slightly earlier place and explain what an "interface" is first. Then we'll consider what an "IEnumerable interface" is.
MSDN states that, "An interface defines a set of members, such as properties and procedures, that classes and structures can implement. The interface defines only the signatures of the members and not their internal workings."
This means that an interface is a definition of what an object does, but it doesn't say how the object does it. Here's an example to illustrate that "what versus how" difference. Suppose you defined an interface called IRun.
Public Interface IRun
Sub Run()
End Interface
Notice that there is no code that implements the subroutine. There isn't even an End Sub. Then you could write code to implement IRun in several different ways. For example:
Public Class RunForOffice
Implements IRun
Private Sub Run() Implements IRun.Run
' Code to Run a political campaign
End Sub
End Class
... or ...
Public Class RunOffAtTheMouth
Implements IRun
Private Sub Run() Implements IDemo.Run
' Code to act rude, crude,
' and socially unfit
End Sub
End Class
(Hmmmm ... Those two classes might be more alike than I originally intended. Anyway ...)
You would then use the new class RunForOffice the way objects are normally used:
Dim myCampaign As RunForOffice = New RunForOffice()
... or ...
Dim myWildParty as RunOffAtTheMouth = New RunOffAtTheMouth()
One of the first questions students usually ask is, "Why would that be any better? Why not just define the whole object, including the content of the members?"
The answer is that defining an interface offers a new dimension of flexibility (Anyone implementing the interface can change the way the members are coded.) while keeping things standard so code will still be uniform. This, in turn, provides a guarantee that the code won't break when new methods are coded against the same interface.
An example to illustrate this benefit might be a IGetEmployee interface. (By convention, interfaces all begin with the letter "I". It's not a rule, it's just something everybody does.) Different programmers could write code to use employee information returned through this interface without knowing anything about how it was created. The actual employee information could be retrieved in lots of different ways, from entering it into a web page to querying a database. And all of the code would run together with no errors because everybody used the same interface definition.
On the next page, we rturn to the main topic: IEnumberable.
