C# in Depth

64 CHAPTER 3 Parameterized typing with genericsFor most people, generics will be the most important new feature of C# 2. Theyenhance performance, make your code more expressive, and move a lot of safetyfrom execution time to compile time. Essentially they allow you to parameterize typesand methods—just as normal method calls often have parameters to tell them whatvalues to use, generic types and methods have type parameters to tell them what typesto use. It all sounds very confusing to start with—and if you’re completely new togenerics you can expect a certain amount of head scratching—but once you’ve gotthe basic idea, you’ll come to love them.In this chapter we’ll be looking at how to use generic types and methods that othershave provided (whether in the framework or as third-party libraries), and how to writeyour own. We’ll see the most important generic types within the framework, and take alook just under the surface to understand some of the performance implications ofgenerics. To conclude the chapter, I’ll present some of the most frequently encounteredlimitations of generics, along with possible workarounds, and compare genericsin C# with similar features in other languages.First, though, we need to understand the problems that caused generics to bedevised in the first place.3.1 Why generics are necessaryHave you ever counted how many casts you have in your C# 1 code? If you use any ofthe built-in collections, or if you’ve written your own types that are designed to workwith many different types of data, you’ve probably got plenty of casts lurking in yoursource, quietly telling the compiler not to worry, that everything’s fine, just treat theexpression over there as if it had this particular type. Using almost any API that hasobject as either a parameter type or a return type will probably involve casts at somepoint. Having a single-class hierarchy with object as the root makes things morestraightforward, but the object type in itself is extremely dull, and in order to do anythinggenuinely useful with an object you almost always need to cast it.Casts are bad, m’kay? Not bad in an “almost never do this” kind of way (like mutablestructs and nonprivate fields) but bad in a “necessary evil” kind of way. They’re anindication that you ought to give the compiler more information somehow, and thatthe way you’re choosing is to get the compiler to trust you at compile time and generatea check to run at execution time, to keep you honest.Now, if you need to tell the compiler the information somewhere, chances are thatanyone reading your code is also going to need that same information. They can see itwhere you’re casting, of course, but that’s not terribly useful. The ideal place to keepsuch information is usually at the point of declaring a variable or method. This is evenmore important if you’re providing a type or method which other people will call withoutaccess to your code. Generics allow library providers to prevent their users from compilingcode that calls the library with bad arguments. Previously we’ve had to rely on manuallywritten documentation—which is often incomplete or inaccurate, and is rarely read anyway.Armed with the extra information, everyone can work more productively: the compileris able to do more checking; the IDE is able to present IntelliSense options basedLicensed to Rhona Hadida