Generics provide a facility for creating data structures that can be specialized to handle specific types. Programmers define these parameterized types so that each variable of a particular generic type has the same internal algorithm, but the types of data and method signatures can vary on the basis of the type arguments provided for the type parameters.
To minimize the learning curve for developers, the C# designers chose syntax that superficially resembles C++ templates. In C#, the syntax for generic classes and structures uses angle brackets to both declare the generic type parameters in the type declaration and specify the generic type arguments when the type is used.
Listing 12.6 shows how you can specify the actual type argument used by the generic class. You instruct the path variable to be the “Stack of Cell” type by specifying Cell within angle bracket notation in both the object creation expression and the declaration statement. In other words, when declaring a variable (path in this case) using a generic data type, C# requires the developer to identify the actual type arguments used by the generic type. Listing 12.6 with Output 12.2 illustrates this process with the new generic Stack class.
In the path declaration shown in Listing 12.6, you declare a variable and initialize it with a new instance of the System.Collections.Generic.Stack<Cell> class. You specify in angle brackets that the data type of the stack’s elements is Cell. As a result, every object added to and retrieved from path is of type Cell. In turn, you no longer need to cast the return of path.Pop() or ensure that only Cell type objects are added to path in the Push() method.
Generics allow you to author algorithms and patterns and to reuse the code for different data types. Listing 12.7 creates a generic Stack<T> class similar to the System.Collections.Generic.Stack<T> class used in the code in Listing 12.6. You specify a type parameter (in this case, T) within angle brackets after the class name. The generic Stack<T> can then be supplied with a single type argument that is substituted everywhere T appears in the class. Thus, the stack can store items of any stated type, without duplicating code or converting the item to type object. The type parameter T is a placeholder that must be supplied with a type argument. In Listing 12.7, you can see that the type parameter will be used for the InternalItems array, the type for the parameter to the Push() method, and the return type for the Pop() method.
There are several advantages of using a generic class rather than a nongeneric version (such as the System.Collections.Generic.Stack<T> class used earlier instead of the original System.Collections.Stack type):
At their core, generics offer the ability to code pattern implementations and then reuse those implementations wherever the patterns appear. Patterns describe problems that occur repeatedly within code, and templates provide a single implementation for these repeating patterns.
Just as when naming a method’s formal parameter, so you should be as descriptive as possible when naming a type parameter. Furthermore, to distinguish the parameter as being a type parameter, its name should include a T prefix. For example, in defining a class such as EntityCollection<TEntity>, you would use the type parameter name TEntity.
The only time you would not use a descriptive type parameter name is when such a description would not add any value. For example, using T in the Stack<T> class is appropriate, since the indication that T is a type parameter is sufficiently descriptive; the stack works for any type.
In the next section, you will learn about constraints. It is a good practice to use constraint-descriptive type names. For example, if a type parameter must implement IComponent, consider using a type name of TComponent.
C# supports the use of generics throughout the language, including interfaces and structs. The syntax is identical to that used by classes. To declare an interface with a type parameter, place the type parameter in angle brackets immediately after the interface name, as shown in the example of IPair<T> in Listing 12.8.
This interface represents pairs of like objects, such as the coordinates of a point, a person’s genetic parents, or nodes of a binary tree. The type contained in the pair is the same for both items.
To implement the interface, you use the same syntax as you would for a nongeneric class. Note that it is legal—indeed, common—for the type argument for one generic type to be a type parameter of another generic type, as shown in Listing 12.9. The type argument of the interface is the type parameter declared by the class. In addition, this example uses a struct rather than a class, demonstrating that C# supports custom generic value types.
Support for generic interfaces is especially important for collection classes, where generics are most prevalent. Before generics were available in C#, developers relied on a series of interfaces within the System.Collections namespace. Like their implementing classes, these interfaces worked only with type object, and as a result, the interface forced all access to and from these collection classes to require a cast. By using type-safe generic interfaces, you can avoid cast operations.
Two different constructions of the same generic interface are considered different types. Consequently, “the same” generic interface can be implemented multiple times by a class or struct. Consider the example in Listing 12.10.
In this example, the Items property appears multiple times using an explicit interface implementation with a varying type parameter. Without generics, this would not be possible; instead, the compiler would allow only one explicit IContainer.Items property.
However, this technique of implementing multiple versions of the same interface is considered by many developers to be a “bad code smell” because it is potentially confusing (particularly if the interface permits covariant or contravariant conversions). Moreover, the Person class here seems potentially badly designed; one does not normally think of a person as being “a thing that can provide a set of email addresses.” When you feel tempted to make a class implement three versions of the same interface, consider whether it might be better to make it instead implement three properties—for example, EmailAddresses, PhoneNumbers, and MailingAddresses—each of which returns the appropriate construction of the generic interface.
Perhaps surprisingly, the constructors (and finalizer) of a generic class or struct do not require type parameters; in other words, they do not require Pair<T>(){...}. In the pair example in Listing 12.11, the constructor is declared using public Pair(T first, T second).
Listing 12.11 included a constructor that takes the initial values for both first and second and assigns them to First and Second. Since Pair<T> is a struct, any constructor you provide must initialize all fields and automatically implemented properties. This presents a problem, however.
Consider a constructor for Pair<T> that initializes only half of the pair at instantiation time. Defining such a constructor, as shown in Listing 12.12, causes a compile-time error because the field Second is still uninitialized at the end of the constructor. Providing initialization for Second presents a problem because you don’t know the data type of T. If it is a nullable type, null would work, but this approach would not work if T were a non-nullable type.
To deal with this scenario, C# provides the default operator. The default value of int, for example,2 could be specified with default. In the case of T, which Second requires, you can use default, as shown in Listing 12.13.
The default operator can provide the default value for any type, including type parameters.
It’s possible to use default without specifying a parameter if it is possible to infer the data type.3 For example, with variable initialization or assignment, you can use Pair<T> pair = default in place of Pair<T> pair = default(Pair<T>). Furthermore, if a method returns an int, it is possible to simply use return default and have the compiler infer a default(int) from the return of the method. Other scenarios where such inference is possible are default parameter (optional) values and method call arguments.
Note that all nullable types have null as their default value, as do nullable generic types such as default(T?). Furthermore, the default value for all reference types is null. As a result, if nullable reference types are enabled with C# 8.0, assigning default to a non-nullable reference type will result in a warning. Prior to C# 8.0 (and obviously after it), you should avoid assigning default or null to reference types unless null is expected to be a valid value.4 Where possible, favor leaving the variable uninitialized until a valid value is available for assignment. In cases like Listing 12.13, where an appropriate value for Second is unknown in the constructor, Second will inevitably be null for a reference type or a nullable value type; thus, a warning appears when assigning default (which is potentially null) to a property of generic type T. To appropriately handle the warning, you will need to declare the Second property to be of type T? and identify whether T is a reference type or a value type with a class/struct constraint as described in the “struct/class Constraints” section. (In fact, this leads to the more general guideline not to assign default on a generic type unless the type assigned is constrained to a class or a struct.)
Generic types may declare any number of type parameters. The initial Pair<T> example contained only one type parameter. To enable support for storing a dichotomous pair of objects, such as a name/value pair, you could create a new version of the type that declares two type parameters, as shown in Listing 12.14.
When you use the Pair<TFirst, TSecond> class, you supply multiple type parameters within the angle brackets of the declaration and instantiation statements; you then supply matching types to the parameters of the methods when you call them. Listing 12.15 illustrates this approach.
The number of type parameters—that is, the arity—uniquely distinguishes the class from others of the same name. Because of this arity variation, it is possible to define both Pair<T> and Pair<TFirst, TSecond> within the same namespace. Furthermore, because of their close semantic relationship, generics that differ only by arity should be placed into the same C# file.
Internally, the underlying type that implements the tuple syntax is, in fact, a generic—specifically a System.ValueTuple. As with Pair<...>, it is possible to reuse the same name because of the variation in arity (each class has a different number of type parameters), as shown in Listing 12.16.
The ValueTuple<...> set of classes was designed for the same purpose as the Pair<T> and Pair<TFirst, TSecond> classes, except that together they can handle eight type arguments. In fact, using the last ValueTuple shown in Listing 12.16, TRest can be used to store another ValueTuple, making the number of elements of the tuple practically unlimited.
Another interesting member of the tuple family of classes is the nongeneric ValueTuple class. This class has eight static factory methods for instantiating the various generic tuple types. Although each generic type could be instantiated directly using its constructor, the ValueTuple type’s factory methods allow for inference of the type arguments via the Create() method. Listing 12.17 demonstrates using the Create() method in combination with type inference.5
Obviously, when the ValueTuple gets large, the number of type parameters to specify could be cumbersome without the Create() factory methods.6
As you might have deduced from the fact that the framework libraries declare eight different generic System.ValueTuple types,7 there is no support in the CLR type system for variadic generic types. Methods can take an arbitrary number of arguments by using parameter arrays, but there is no corresponding technique for generic types; every generic type must be of a specific arity. (See “Beginner Topic: Tuples: An Abundance of Arity” for an example where you might imagine such a feature.)
Type parameters on a containing generic type will “cascade” down to any nested types automatically. If the containing type declares a type parameter T, for example, all nested types will also be generic, and type parameter T will be available on the nested type as well. If the nested type includes its own type parameter named T, this will hide the type parameter within the containing type, and any reference to T in the nested type will refer to the nested T type parameter. Fortunately, reuse of the same type parameter name within the nested type will cause a compiler warning to prevent accidental overlap (see Listing 12.18).
The containing type’s type parameters are accessible in the nested type in the same way that members of the containing type are also accessible from the nested type. The rule is simply that a type parameter is available anywhere within the body of the type that declares it.
________________________________________