Managed Extensions: Combining IEnumerable and IEnumerator

Welcome to this week's installment of .NET Tips & Techniques! Each week, award-winning Architect and Lead Programmer Tom Archer demonstrates how to perform a practical .NET programming task using either C# or Managed C++ Extensions.

Previous installments of the .NET Tips & Techniques series covered using types defined in the .NET Collection namespace to make classes both enumerable and sortable from Visual C++ and Managed Extensions applications. Each article employed the technique of creating two additional classes to the class being enumerated: a collection class (IEnumerable-derived) and an enumerator class (IEnumerator-derived). This article explains why the .NET BCL (Base Class Library) team chose to define two interfaces that are used together to achieve enumerability and how—in specific scenarios—you can define a single class that implements both interfaces.

Why Two Interfaces?

Why doesn't the IEnumerable interface define the Current, MoveNext, and Reset members, thereby eliminating the need for the IEnumerable::GetEnumerator method and the IEnumerator interface? That way, the collection class could simply provide public accessor methods to the data. Although this technique sounds reasonable at first blush, it has drawbacks.

One such drawback is evident if a single collection object can have multiple clients and its data can be modified (especially if records can be added or deleted) while the data is being enumerated. You could, of course, circumvent this particular problem by creating a "data object" internal to the collection object for each client. Then the problem would be associating each client with its respective data object—typically done through an attach/detach method pair. The client then would need to identify itself using some sort of ID (probably returned from an attach method) to retrieve its data.

As you can see, this solution heads down a slippery slope of diminishing returns, generating more work than it alleviates. This is not even mentioning the fact that you would forfeit the generic solution afforded you via the IEnumerable/IEnumerator interface pair. With these interfaces, the snapshot of the collection data that existed when the client requested the enumerator object is copied to the enumerator object and becomes available via the standard methods: Current, MoveNext, and Reset.

Combining the Two Interfaces

Having two distinct interfaces (IEnumerable and IEnumerator) eases the burden of keeping track of enumerators that represent snapshots of dynamic data. The logical question, then, is "what if the data is static?" In other words, why define an enumerator class that has its own copy of the original collection data if that data never changes? This is one scenario where combining the two interfaces into a single collection class would be advantageous. (You could also keep the collection and enumerator class definitions separate and simply not copy the data—instead having the enumerator object's Current, MoveNext, and Reset members directly access the collections data. However, why even define a separate enumerator class in situations where it has no benefit?)

Therefore, in the following class definitions, I've taken the Article class used in the past few articles and modified it to include a single class (ArticleCollection) that implements both the IEnumerable and IEnumerator interfaces:

#pragma once

#pragma push_macro("new")
#undef new

__gc class Article
{
public:
   Article(String* title, String* author, String* category)
   {
      this->title    = title;
      this->author   = author;
      this->category = category;
   }

protected:
   String* title;
   String* author;
   String* category;

public:
   __property String* get_Title()    { return this->title; }
   __property String* get_Author()   { return this->author; }
   __property String* get_Category() { return this->category; }
};

__gc class ArticleCollection : public IEnumerable,
                               public IEnumerator
{
protected:
   ArrayList* articles;
public:
   ArticleCollection()
   {
      articles = new ArrayList();

      // create some sample data
      articles->Add(new Article(S"Article #1", 
                                S"Tom", 
                                S"Managed Extensions"));
      articles->Add(new Article(S"Article #2", 
                                S"Dick", 
                                S"Visual C++/MFC"));
      articles->Add(new Article(S"Article #3", 
                                S"Harry", 
                                S"C#"));
   }

public:
   IEnumerator* GetEnumerator()
   {
      Reset();
      return this;
   }

protected:
   int position;

public:
   bool MoveNext() { return (++position < articles->Count); }

   __property Object* get_Current()
   {
      if (0 > position
      || position >= articles->Count)
      throw new InvalidOperationException();

      return articles->Item[position];
   }

   void Reset() { position = -1; }
};
#pragma pop_macro("new")

Here's a list of the main changes to the technique for enumerating your classes covered in the article, "Managed Extensions: Adding Enumeration to Your Classes:"

  • Aside from the class you want enumerable, the only class you need to add is a collection class that implements (derives from) both IEnumerable and IEnumerator. In this example, this leaves you with the Article and ArticleCollection classes.
  • Because the collection class implements both interfaces, the GetEnumerator method now can simply return the current object instance instead of instantiating a separate enumerator object, which would involve the unnecessary copying of the collection object's data.
  • The Reset, MoveNext, and get_Current methods are now in the collection class.


About the Author

Tom Archer - MSFT

I am a Program Manager and Content Strategist for the Microsoft MSDN Online team managing the Windows Vista and Visual C++ developer centers. Before being employed at Microsoft, I was awarded MVP status for the Visual C++ product. A 20+ year veteran of programming with various languages - C++, C, Assembler, RPG III/400, PL/I, etc. - I've also written many technical books (Inside C#, Extending MFC Applications with the .NET Framework, Visual C++.NET Bible, etc.) and 100+ online articles.

Comments

  • Breaks independence of enumerators

    Posted by shammah on 10/24/2006 02:53pm

    Doesn't this break the conceptual independence of enumerators. e.g., if I have two enumerators from ArticleCollection::GetEnumerator, then calling Reset() or MoveNext() on one would actually change the other!
    
    ArticleCollection ac;
    foreach(Article a in ac)
    {
      foreach(Article b in ac)
      {
        // Do something with the pair (a, b)
      }
    }

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: October 29, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Are you interested in building a cognitive application using the power of IBM Watson? Need a platform that provides speed and ease for rapidly deploying this application? Join Chris Madison, Watson Solution Architect, as he walks through the process of building a Watson powered application on IBM Bluemix. Chris will talk about the new Watson Services just released on IBM bluemix, but more importantly he will do a step by step cognitive …

  • QA teams don't have time to test everything yet they can't afford to ship buggy code. Learn how Coverity can help organizations shrink their testing cycles and reduce regression risk by focusing their manual and automated testing based on the impact of change.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds