VB.net -- How to make your class implement IEnumerable, IEnumerate

Everyone loves to loop through a collection. For instance say you have a winform and you wanted to loop through the controls of that form:

Code:

---

Dim ctl as Control

For each ctl In Me.Controls
  If TypeOf ctl is TextBox then
    'do something
  else
    'don't
Next

---

The reason coders love to do this is:

• Makes code readable
• Follow the general loop for a Collection
• Simplier than having to loop using a counter / index

One of the benefits of VB.net is you can implement this type of loop for your own Abstract Data Types. A ADT is simply an object in the object orientated programming world. So if you had an Employee object which mimiced an employee in say a management system you could do something like so:

VB Code:

Dim anEmployee as Employee
 
For each anEmployee in Employees
  'do something with the employee
next

In order to do something like this one must understand OOP as well as Interfaces. There has been numerous questions about what an interface is, how to create one, how to use an existing one by using the Implements keyword, etc etc. Without going to deep into the subject an Interface allows you to expand on what an object does, rather than what an object is / is like (which is a totally different subject called Inheritance).

Common objects may be interfaced on their various properties. One interface in this example that I am posting is the IEnumerable, IEnumerate interfaces. In order to perform a for each loop using your objects you need to ensure your class implements these two interfaces. When and if your class implements an interface you must abide by some rules:

• Ensure that your class implements the methods / functions that the interface has defined. Even if you implemented nothing inside of the method you are interfacing that will be fine, the issue is you must provide at least the core or shell of that interface method
• Your methods must follow specific signatures

So pretty much an interface is a binding contract that your class must make. Its a lot like the real world, employees must sign contracts to abide by specific conditions in their working environment. It's much the same with interfaces, your classes sign a contract stating "Hey Interface, I'm going to use you till you sweat and cry...but ok ok I'll abide by your rules...since you are the boss".

In my example I simply create an Employee class (class Employee), a class called Employees (which has as a private member a reference to an array of Employees), and some sample code to test the results.

My Employees class must implement the IEnumerate and IEnumerable classes in order to take advantage of the collection loop like structure. The code is pretty clean and choke full of comments, but you are more then welcome to comment.

I seperated the winform (just a button to run the code) from the actual classes themselves, and referenced them (as dll's) in the winform.

Now before you run the code a little about the interfaces we used. One could easily inherit from the System.Collections.CollectionBase class to perform the same thing I have done here, however I prefer and feel implementing Interfaces is a bit better and cleaner in the long run.

IEnumerable
This interface expects you to implement or shell out the GetEnumerator() function (if you don't do so in your class, your code will not even compile). This function returns an IEnumerator allowing you to traverse your objects.

IEnumerator
This interface allows you to MoveNext(), Reset(), and View (Current property) the objects of your class. Once again you need to shell these functions / properties out as well, if you do not do that you will not be able to compile your code.

Ok enough jibberjabbish...enjoy

In accordance with this CodeBank policy concerning compiled files in attachments, your zip file has been edited and all .Dll files and all .Exe files have been removed.

Read everything but that...thanks for the mod!