Welcome to this installment of the .NET Nuts & Bolts column. To fulfill some requests I've received, this article expands on the use of lists and collections in Microsoft .NET. Its focal point is generics, which is a new addition in the version 2.0 release of the Microsoft .NET Framework. The article explains why generics are valuable and what they can add to your applications, exploring the classes in the System.Collections.Generic namespace.
The first release of the Microsoft .NET Framework introduced a System.Collections namespace. The namespace contains a number of different interfaces and classes that define various types of helpful container lists, dictionaries, and hashtables. Each has a different implementation and serves a distinct and specific purpose. A collection is an example of a commonly used class within the namespace. It is a container to which objects of any type can be added. This offers powerful flexibility and adaptability.
Collections also have a number of drawbacks, however. All items are stored as objects; this results in an overhead as items are added or removed from the collection because they have to be unboxed and boxed to specific types. The overhead creates a performance penalty each time an item in the collection or list is accessed. Given that items in collections and lists are often traversed in a loop structure, the performance penalty compounds and can really affect the overall performance of your application. Additionally, no type checking enforces consistent use of the same type within the collection at compile time, which can lead to unforeseen runtime errors.
The 1.0 and 1.1 versions of the Microsoft .NET Framework did not have a solution for the performance hit for boxing and unboxing types. The types always had to be cast when accessed from the list. They did offer a workaround to enforce consistent type use, though. The workaround involves writing wrappers around ArrayList and other collection and list types to limit the specific types that can be assigned. This is less than ideal because you end up creating a wrapper class for each specific type use. The result is a lot of code that doesn't vary a whole lot between the contained types. Even if you employ a code generator—a number will assist you with this—it still amounts to a fair amount of additional code to maintain.
The following sample demonstrates the maintenance problem. It defines a list that has the sample TestItem as the specific type it contains. The example includes sample methods for add and remove functionality that limit the collection to the specified type:
/*
* Sample class to add to lists.
*/
private class TestItem
{
private int _ItemValue = 0;
public int ItemValue
{
get { return this._ItemValue; }
set { this._ItemValue = value; }
}
public TestItem(int itemValue)
{
this.ItemValue = itemValue;
}
}
/*
* Sample collection that is specific to TestItem type.
*/
private class TestItemCollection : CollectionBase
{
public TestItem this[ int index ]
{
get { return( (TestItem) List[index] ); }
set { List[index] = value; }
}
public int Add( TestItem itemValue )
{
return( List.Add( itemValue ) );
}
public void Remove( TestItem itemValue )
{
List.Remove( itemValue );
}
}
/*
* Code to demonstrate using our TestItemCollection type.
*/
TestItemCollection testCollection = new TestItemCollection();
// Add some numbers to the list
for( int i = 0; i < 20; i++ )
{
testCollection.Add(new TestItem(i));
}
IEnumerator listEnumerator = testCollection.GetEnumerator();
while( listEnumerator.MoveNext() )
{
Console.WriteLine("{0}", ((TestItem)
(listEnumerator.Current)).ItemValue);
}
// Wait so you can read the output
System.Console.ReadLine();
As you can see, the item also must be cast when accessed from the collection. This obligatory cast means that an error would result if another type of object were put into this collection. The code serves its purpose to create a type safe collection for dealing with the TestItem class, but it is not reusable for other types. If you have a number of such type-specific classes, maintaining them becomes so unwieldy that it almost isn't worth it for the type safety provided.
Generics were introduced to offer a combination of type safety, performance, and generality in the defined type, which is an all-around win. A generic is a type-safe class that is declared without a specific type applied to it in the definition. Rather, the type is specified at the time the object is used. In the previous example, that would be equivalent to specifying TestItem as the type at the time you declare your collection variables. This would limit that particular item from holding any type other than a TestItem. The code will not compile if you attempt to assign something such as a DataSet. The System.Collections.Generic namespace contains a number of pre-built classes that represent common types, including the following:
The language syntax for generics takes a bit of adjustment (at least it did for me), but in the end the functionality provided far outweighs any learning curve necessary to get used to the syntax. In C#, the generic type can be identified by the less than (<) and greater than (>) symbols after the generic type name. The specific type you want applied to the generic type is specified within the symbols. In this example, you simply use the predefined list type rather than creating your own generic code:
/*
* Sample use of Generic List type.
*/
List<TestItem> testCollection = new List<TestItem>();
// Add some numbers to the list
for (int i = 0; i < 20; i++)
{
testCollection.Add(new TestItem(i));
}
foreach( TestItem test in testCollection )
{
Console.WriteLine("{0}", test.ItemValue);
}
// Wait so you can read the output
System.Console.ReadLine();
If you try to assign an object of any type other than TestItem to the testCollection instance above, you receive a compile time error
No comments:
Post a Comment