It's been a few months since Visual Studio 2005 was released. In that time you've probably seen and read quite a bit about generics. Unfortunately all those articles and presentations can leave you with the impression that generics are useful only in the context of collections (List<T>, Dictionary<K,V>, Queue<T>, and so on).

It's true that many of the most common uses of generics involve collections. But limiting your use to collections will cause you to miss many of the opportunities for creating components that you can reuse in even more ways. In fact, many idioms where developers commonly copy, paste, and modify source code can be solved with generics. You should look for these opportunities, because you'll have more functionality in a smaller code base.

Enhance a generic class, and all users of it are one recompile away from the new features. That's much better than using code snippets. It's a manual task to track down and edit all the copies of a code snippet inserted into your project.

In this article, I'll show you how to find algorithms that can be replaced with generics and how to migrate specific code to its generic counterpart. As examples, I'll show you a quick example by serializing types as XML data, and I'll build a more complicated version, implementing the Proxy class from Design Patterns (Addison-Wesley, 1995).

The Sample Application
To illustrate these topics, I built a simple application that enables you build a collage from a list of images. (See Figure 1.) This is a small sample to illustrate the concepts, so keep your copy of Photoshop for now. The sample application lets you choose a source directory for your images, copy the images onto a background, and move and scale the images. Once you have something you like, you can save the composite image.

We'll examine this application and extract two generic algorithms that you can reuse in your own applications.

Making Generics
Generics are the .NET way of creating algorithms that are loosely coupled to the types on which they operate. That's a large part of the reason why so many of the examples use collections. Collection algorithms don't normally have any dependencies on the types contained in the collections. List<int>, List<string>, List<Employee>, or anything else would work just fine.

The implementation of the collection classes isn't dependent on any properties, or behavior, defined in the type contained. In fact, different generic collections only differ in the capabilities of the collection itself; rarely do they differ in the constraints mandated on the contained type.

In my example, I've used a List<Image> for the list of images in the current collage. The list of files is a BindingList<string> because the BindingList<T> class contains extra functionality that facilitates data binding in Windows forms applications. You've probably already used both of these classes.

Another area where you can see generics used in the .NET Framework is in interfaces that are often used in collections: IEquatable<T>, IEqualityComparer<T>, and ICompar-able<T>. Once again the key to using generics is that signature of the interface is very common: The implementation will depend on the specific type and the parameters depend on the specific type, but the semantic contract is independent of the type.

So the .NET Framework has a rich set of generic classes that are great for various common uses. These classes are designed for very horizontal applications. But they probably aren't all the reusable bits of functionality you'll use in your applications or across multiple applications in your organization. As you develop more code, you'll discover that you've written bits of functionality that you want to reuse in many different ways. With a little work, you can modify these bits of code so that you can reuse them, unmodified, in many different ways.

The first example will provide a mechanism to store and retrieve the current application state. Most desktop applications will store some form of user preferences, or last actions, or similar data. I find that persisting that information using the .NET XML serialization framework is an easy way to implement that. You write a simple class that contains public properties for all the user-controlled options. Then you write two methods to load and save the options. My sample application used the specific UserPreferences class shown in Listing 1.

You'll notice that the LoadFromFile and SaveToFile methods are almost completely independent of the type used (UserSettings). You should be able to reuse these methods anywhere, right? You can. Simply factor out those two methods and put them in a generic class. The wrapper class contains a single member of the target type and provides the load and save code. It also provides a read-only property to access the embedded target object. Limiting the target object to a class type enables you to add a read-only property to modify the embedded storage and still provide appropriate access to the embedded object for the rest of the program. The generic wrapper is shown in Listing 2.

Reusing this is a simple matter of creating a new instantiation with different type information. As an example, let's add the ability of saving your current work to the sample application. Doing so will leverage the AutoSave generic class. Inside the Main form, you've got a list of images:

private List<CollageImage> listOf-Images = new List<CollageImage>();

Essentially, that's the entire storage for the current collage. So let's make a couple of modifications to the CollageImage class that will make it easier to save that via XML serialization. The images need the XMLIgnore attribute:

[XmlIgnore()]
public Image Thumbnail
{
      get
      {
         generateThumbnail();
         return thumbNail;
      }
}

      And the image path must be a read/write property:

public string ImagePath
{
      get { return path; }
      set { path = value; }
}

Next, let's build a simple class that contains the list of images. (See Listing 3.) There is one interesting problem in the generic collections with respect to XML Serialization. For some reason, the XML Serializer can't save or restore a generic IList<T>, but it can serialize and IList interface, provided the appropriate attributes are added to the property. Therefore, I've added two different IList properties to this class, one IList<CollageImage>, one IList. The second is correctly serialized.

Finally, you can use the AutoSave template to create a version of this class that can be serialized. That's it. The point is that you can reuse the AutoSave generic class with only minimal extra work.

Pondering Patterns
Load and save was fairly simple, so let's move on to the more complicated Proxy pattern. Stripped of all the glamour normally associated with a new buzzword, a design pattern is simply a standard proven solution to a common programming problem. Nothing more; nothing less. As such it's a way to reuse common solutions to common problems. Design Patterns by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley, 1995) is still the definitive catalog of patterns.