OrderedDictionary myOD = new OrderedDictionary();

      myOD.Add(“01”, “First”);

      myOD.Add(“02”, “Second”);

      myOD.Add(“03”, “Third”);

      myOD.Add(“04”, “Fourth”);

      myOD.Add(“05”, “Fifth”);

      // Reference the values array style

      for (int i = 0; i < myOD.Count; i++)

      {

        // Create a strongly typed variable to hold the

        // generic object in myOD[], then do a cast

        string valueString = (string) myOD[i];

        Console.WriteLine(valueString);

      }

      // Reference the values Dictionary style

      foreach(DictionaryEntry myDE in myOD)

      {

        Console.WriteLine(myDE.Value);

      }

Above you can see I used two different methods to iterate over my collection. In the first example, I used a for loop and a numeric index to retrieve each object (in this case a string) stored in the collection. Using a cast I convert it from the generic object type into a more strongly typed variable.

While it’s true I simply could have used Console.WriteLine(myOD[i].ToString()), you will not always be dealing with string data in your value. This example demonstrates how to do a simple conversion.

In the second loop, you can see code similar to what has been shown all week, using a DictionaryEntry object to iterate over the collection.

The other advantage to an OrderedDictionary is speed. When going over a large collection, reading the OrderedDictionary using the first example, the numeric index, is always going to be faster than using the dictionary style method.

When you need both the power of a collection, and the simple access of a numeric index, the OrderedDictionary is the collection of choice.

      HybridDictionary genders = new HybridDictionary();

      genders.Add(“M”, “Male”);

      genders.Add(“F”, “Female”);

The question many will ask “well why not just use a HybridDictionary all the time?” As with most things in life, there is a trade off. There is a some overhead associated with HybridDictionaries, as they have to constantly monitor their own size, then convert back and forth between ListDictionaries and HashTables as needed. In return, you get the best possible performance from your collection as it changes in size.

The moral of the story, when you know you have a small collection, use a ListDictionary. On the other hand, if you know with certainty your collection will be large, use a HashTable. But for all those other times when you just don’t know, the HybridDictionary is your answer.

      Hashtable myHash = new Hashtable();

      myHash.Add(“ArcaneCode”, “arcanecode.wordpress.com”);

To read or update the data stored in the value, you can treat the hashtable as if it were a simple array, using the key where you’d normally put the index.

      Console.WriteLine(myHash[“ArcaneCode”]);

      myHash[“ArcaneCode”] = “Here I’ve changed the value.”;

      Console.WriteLine(myHash[“ArcaneCode”]);

      Console.Read();

Hashtables are great for storing data where you have a good primary key you can quickly reference things by. In our example, I’ve stored strings as the value part of the key / value pair, but you can use any type of object for the value, including classes you create.

The examples so far assume you will always want to retrieve a single item out of your hashtable. However, we all know there are times when you will want to iterate over the entire collection. To do this, it’s necessary to understand how your key / value pair is storied.

In keeping with the spirit of OOP, what is actually stored in the hashtable collection is another object of type DictionaryEntry. The dictionary entry object has two essential properties, the Key and the Value, both of which are the generic object type. Here’s an example of how to loop over the myHash collection.

      // Clear out the previous items

      myHash.Clear();

      // Now add some new items.

      // Note we use an int as the key this time.

      myHash.Add(1, “Item one”);

      myHash.Add(2, “Item two”);

      myHash.Add(3, “Item three”);

      // Loop over the list, writing out the value

      foreach (DictionaryEntry myEntry in myHash)

      {

        Console.WriteLine(myEntry.Value);

      }

      Console.Read(); // Wait for user to press a key

Note we cycle through a list of DictionaryEntry objects, and each time through get the Value property. If we wanted to get the key, it would be a simple matter of replacing the Value property call with a call to Key.

If you are in a situation where you are not sure of the data types being used in the keys or the values, you should append a .ToString() after a reference to the Key or Value so as not to generate run time errors when displaying. In the above example, we’d have needed to use Console.WriteLine(myEntry.Key.ToString()); since our keys were integers (1, 2, and 3).

As you can see, the hashtable makes it easy to look up values when you have a specific key, yet at the same time is still flexible enough to allow you to iterate over your entire collection when you need to.

      Stack myStack = new Stack();

      myStack.Push(“1. Carl Franklin”);

      myStack.Push(“2. Richard Campbell”);

      myStack.Push(“3. Mark Miller”);

      myStack.Push(“4. Kimberly Tripp”);

      myStack.Push(“5. Billy Hollis”);

      while (myStack.Count > 0)

      {

        Console.WriteLine(myStack.Pop());

      }

      Console.ReadLine();

As you can see, the pop operation removed the items from the collection in the reverse order from which they were loaded. In other words, the last item on is the first one you’ll be pulling off.

The peek method works just like it does with the queue. Modifying the while loop above thusly:  

      while (myStack.Count > 0)

      {

        Console.WriteLine(“Peek: “ + myStack.Peek());

        Console.WriteLine(“Pop : “ + myStack.Pop());

      }

Produces this output:

Stacks are handy when you want to keep track of objects that need to be handled in the reverse order, say for creating and disposing. Like queues, stacks enforce reading your data in a specific order. Whenever you have a requirement to read in a LIFO order, the stack class will add the extra safety you need to make your applications work as you designed.

      Queue myQueue = new Queue();

      myQueue.Enqueue(“1. Carl Franklin”);

      myQueue.Enqueue(“2. Richard Campbell”);

      myQueue.Enqueue(“3. Mark Miller”);

      myQueue.Enqueue(“4. Kimberly Tripp”);

      myQueue.Enqueue(“5. Billy Hollis”);

      Console.WriteLine(“Count = “ + myQueue.Count.ToString());

      while (myQueue.Count > 0)

      {

        Console.WriteLine(myQueue.Dequeue());

      }

      Console.WriteLine(“Count = “ + myQueue.Count.ToString());

      Console.ReadLine();

This routine prints the following output to the command window:

As you can see, the Dequeue method returned the items in the same order they were loaded in. There’s really not much to explain, you load objects into the queue using Enqueue (in this case strings), and remove objects using Dequeue.

I also mentioned a Peek method. This allows you to look at the next item without removing it. Here I’ve modified the while loop to first show the next item on the queue using peek, then actually remove it.

      while (myQueue.Count > 0)

      {

        Console.WriteLine(“The next DNR person is:” + myQueue.Peek());

        Console.WriteLine(“Dequeuing them……..:” + myQueue.Dequeue());

      }

There are several instances where you may want to use a queue over an array list. Perhaps you are processing messages, or are reading through a list where it’s important you read them in order, say a list of transactions from a database. Data that needs to be processed chronologically could be placed on a queue.

Any time you have data that must be processed in the order in which it was loaded, use a queue. The rigidity of the queue will add an extra layer of safety to your application, ensuring data is read in the order in which you intended.

  public class Employee : IPersonM, IPersonP

Now that’s done, let’s create a class that will hold multiple employees. We’ll call it Employees (plural) and have a method to add employees to it. Internally we’ll store the individual Employee objects in a generic List<T> collection.

using System;

using System.Collections.Generic;

using System.Text;

namespace OOPDemo

{

  public class Employees

  {

    private List<Employee> _employees = new List<Employee>();

    public void AddEmployee(Employee emp)

    {

      _employees.Add(emp);

    }

    public IEnumerator<Employee> GetEnumerator()

    {

      foreach (Employee emp in _employees)

      {

        yield return emp;

      }

    }

  }

}

Before I explain the details, let’s look at how to use the new collection.

      Employees myEmployees = new Employees();

      Employee emp1 = new Employee();

      emp1.FirstName = “Carl”;

      emp1.Lastname = “Franklin”;

      myEmployees.AddEmployee(emp1);

      Employee emp2 = new Employee();

      emp2.FirstName = “Richard”;

      emp2.Lastname = “Campbell”;

      myEmployees.AddEmployee(emp2);

      Employee emp3 = new Employee();

      emp3.FirstName = “Mark”;

      emp3.Lastname = “Miller”;

      myEmployees.AddEmployee(emp3);

      string everyone = “”;

      foreach (Employee emp in myEmployees)

      {

        everyone += (emp.FullName() + Environment.NewLine);

      }

      MessageBox.Show(everyone, “Everyone”);

As you can see this is pretty straight forward, it created 3 employee objects and called the AddEmployee method to add them to our collection. The code then enters a foreach loop retrieving each individual Employee object from the collection of Employees.

What makes this work is the IEnumerator interface. By having the Employees class have a GetEnumerator method that returns an IEnumerator, we enable it to be used anywhere that an IEnumerator can be used, such as a foreach loop.

The only other thing to explain would be the new keyword yield. Each time through the loop the yield will exit the loop and return to the calling routine. The next time through the foreach loop, the GetEnumerator picks right back up at the yield statement, and loops to the next item in our internal List.

To your method, he yield keyword is sort of like sleep mode is to the computer. It pauses, then returns control to the calling routine. When you return, you re-enter the routine right where you left off, with all the routines and variables just as you left them. Not unlike powering up your computer again from sleep mode.

What makes this a little different is that the method GetEnumerator is what implements the IEnumerator interface. Normally, interfaces are implemented by the entire class, not just a single method.

While not the best example of a standard interface, it does demonstrate the power of extending an existing .Net interface. In this example it suddenly allowed your class to be used by a foreach loop. Take advantage of the built in .Net interfaces to make your own classes even more powerful and fit into the .Net environment.

using System;

using System.Collections.Generic;

using System.Text;

namespace OOPDemo

{

  public interface IPersonP

  {

    string FirstName { get; set;}

    string Lastname { get; set;}

  }

  public interface IPersonM

  {

    string FullName();

  }

}

Now we need to modify our Employee class to implement both methods.

  class Employee : IPersonP, IPersonM

Notice all it took was separating the interface names with commas. If we were also inheriting from a base class, we would list it first. Yes, you can both inherit from a single base and implement one or more interfaces for a class.

Finally, we need to make a quick update to our ShowName, since the old IPerson has been replaced with an M and P version:  

    private void ShowName(IPersonM per)

    {

      MessageBox.Show(per.FullName(), “ShowName Method”);

    }

You need to be careful when designing your interfaces, not to get too focused. In the above example, what if in the ShowName method you need to also access the FirstName property? Can’t do it with the code as it is now since IPersonM knows nothing about those properties. Instead you’d have to pass in an Employee, in which case we’ve limited our functionality. The ShowName would no longer be able to accept a Contractor or Vendor (assuming we ever created them).

So, we know that a good time to use an interface is when you have a base set of properties and methods, but not code, that you wish to share among classes so that you can treat them as the same generic type. What other times might you wish to use interfaces?

In his book Programming .Net Components (http://shrinkster.com/ly6) Juval Lowy has an entire chapter devoted to interface based programming. When writing a class library (i.e. a dll) Mr. Lowy suggests only exposing interfaces. Why? This leaves you totally free to redesign even your base classes.

Even further, Juval advocates placing all of your interfaces into their own class library. Because it’s fairly quick to create interfaces, it allows both the user interface team and the class library team to get to work, both referencing the same interface dll.

A final reason for using interfaces is to extend your class so that it is compatible with items in the .Net Framework. .Net exposes a slew of interface types, and you can implement any of them in your classes.

A common example is the IEnumerator interface. If you were to implement the IEnumerator interface in your class, you could then use your class anywhere you would use an enumerator in .Net, such as in a foreach construct.

Hopefully by now you’ve seen the power of an interface, and will begin using them in your own applications.