You’ll want to become really handy with generics for two reasons:
1.
The framework makes heavy use of generics, so you’ll need to understand them in order to put the .NET Framework to good use.
2.
Generics can really supercharge and streamline your code. Doing more with less code is a great thing—after all, writing less code means writing fewer bugs!
Using generic collections, you can make your code more powerful and simpler at the same time. You don’t even need to rewrite your container code to benefit! The .NET 2.0 Array object implements some interfaces—including IList, ICollection, and IEnumerable—in System.Collections.Generic, giving a lot of new power to old Array-based code without any additional effort on your part.
Prior to .NET 2.0, the .NET Framework offered two kinds of collection objects: we could store objects in untyped collections (like the ArrayList), or typed containers (like a StringCollection or an integer array). Both options had their problems.
Untyped containers provided flexibility and features, but at a heavy price: developers who used them had to give up type safety. We always needed to cast objects to retrieve the containers, and each addition or retrieval incurred a performance hit. Typed containers were safer and offered better performance, but they required code to be repeated for each object that the container held. Developers had to write a CustomerCollection, an OrderCollection, a ProductCollection, and a SupplierCollection, even though they all did the same things! Additionally, since each container had to re-implement each feature, typed containers generally weren’t as rich in features as their untyped counterparts.
Generic containers give us the best of both worlds—we can store groups of objects using the flexibility of untyped containers, and gain the type safety and performance benefits of typed containers. The generic class is implemented only once, but can be declared and used with any type.
The best way to illustrate these benefits is with an example that compares the ways in which ASP.NET 2.0’s generic collections are better than those of ASP.NET 1.1. Suppose we were building an application to display our comic book collection to the world. We’d probably start with a ComicBook class:
public class ComicBook
{
public ComicBook(string title)
{
this.title = title;
}
public string Title
{
get
{
return this.title;
}
}
string title;
}
With .NET 1.1, we might create our comic book collection using an ArrayList:
ArrayList comics = new ArrayList();
comics.Add(new ComicBook(“The Amazing Spiderman #1″));
comics.Add(new ComicBook(“X-Men #3″));
This might seem fine on the surface, but imagine someone came along and added the following code:
comics.Add(new BaseBallCard(“Mickey Mantle Rookie”));
Hey! That’s not a comic book!
No, it’s not. But as far as the ArrayList is concerned, it’s perfectly valid—the ArrayList is a collection of Object instances. Since every class is derived from Object, the ArrayList isn’t very discriminating. Ideally we’d like our classes to be more strongly typed.
It was possible to create strongly typed classes back in the days of .NET 1.1, but it typically required a lot of code. Not only that, but you had to write a lot of repetitive code if you planned on using strongly typed collections for every type that you wanted to aggregate. Amit Goel’s article from 2003 gives an insight into just how much code was required to implement generics in .NET 1.1.
With .NET 2.0, we can avoid all this repetitive code and gain type safety using a generic collection—a container that can be used to store objects of any class. We can specify a generic version of the ArrayList above using the syntax List
We only specify the type of object to be held by the list at the time we create an instance of List
List
comics.Add(new ComicBook(“Sandman”));
comics.Add(new ComicBook(“Arkham Asylum”));
// The following line does not compile.
comics.Add(new BaseBallCard(“Kirby Pucket Rookie”));
With this additional level of detail in place, we can no longer slip a BaseBallCard instance into our List
Generic collections have other advantages over untyped collections; for instance, they offer improved performance when storing value types in the collection. Here’s an example:
ArrayList randomNumbers = new ArrayList();
randomNumbers.Add(8); //boxing occurs
randomNumbers.Add(8);
randomNumbers.Add(8);
int firstNumber = (int)randomNumbers[0];
In the above code listing, the Add method for the ArrayList accepts a parameter of type Object. This means that every time you add a value type (like an integer, as we’ve done here), the value type has to be cast to an instance of type Object—a process known as boxing.
When we retrieve a value, unboxing occurs. Because boxing and unboxing are expensive operations, doing them too often can hurt your application’s performance.
Note: Boxing and Unboxing your Objects
The terms boxing and unboxing refer to the way that C# handles the conversion between value types (primitive types such as integers) and reference types (such as classes and more complex data structures). Converting from a value type to a reference type is referred to as boxing, because the value is copied to a container in memory (a “box”) where it is stored. Converting from a reference type back to a value type is called unboxing, as the value is copied out of the container and into the appropriate location.
While the handling of types in this manner is convenient, both the boxing and unboxing operations take a small amount of time. For large numbers of objects, this can cause a performance bottleneck.
We can avoid the performance penalty incurred in the above code by using a generic collection. Here’s the same example rewritten as a generic collection:
List
randomNumbers.Add(8); // no boxing occurs
randomNumbers.Add(8);
randomNumbers.Add(8);
int firstNumber = randomNumbers[0]; // no casting necessary
Not only does the above code perform better than our previous attempt, which used an ArrayList, but it’s also cleaner: when retrieving a value from the generic list, as we’ve done in the last line of code above, there’s no need to manually cast the object.
Note: Generics: Under the Hood
How do generic containers work? The type conversion magic is performed by the JIT, or Just In Time, compiler at runtime. For example, if your application uses a generic List object to store integers, then the first time your application references that class, the JIT compiler will create a List that’s strongly typed to hold only int objects. From then on, every time you reference a List of ints, the JIT compiler will simply reuse the integer-typed List, rather than create a new class from scratch. Collections of custom classes (such as, for example, Customer objects) are even simpler—the JIT compiler only needs to create a single List for storing objects of the generic class object. The List can then be reused to store any reference object that we choose.
Note: What’s a Predicate?
Some of the most powerful utility methods provided by generic collections make use of predicates. But what is a predicate?
A predicate is a function that takes an element from a generic list and returns a Boolean result. When used as a hook for accessing a collection of generic objects, a predicate makes it easy for us to perform bulk operations on the objects without needing to know their types.
One example of a predicate in use is the Find method. To use Find on a generic collection, you must write code for the body of the method to return true if a matching element in the collection is found. The .NET runtime takes over the grunt work of looping through the collection—all we have to do is fill in the business logic.
Other functions in the System.Delegate library—actions, converters, and comparers—have been defined for use in generic collection methods, but in this chapter we’ll focus most heavily on predicates.