Introducing Generic Types

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.

Using a Generic Class

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.

Listing 12.6: Implementing Undo with a Generic Stack Class
using System;
using System.Collections.Generic;
 
public class Program
{
    // ...
 
    public static void Sketch()
    {
        Stack<Cell> path = new();
        Cell currentPosition;
        ConsoleKeyInfo key;
        // ...
 
        do
        {
            // Etch in the direction indicated by the
            // arrow keys that the user enters
            key = Move();
 
            switch(key.Key)
            {
                case ConsoleKey.Z:
                    // Undo the previous Move
                    if(path.Count >= 1)
                    {
                        // No cast required
                        currentPosition = path.Pop();
                        Console.SetCursorPosition(
                            currentPosition.X, currentPosition.Y);
                        FillCell(currentPosition, ConsoleColor.Black);
                        Undo();
                    }
                    break;
                case ConsoleKey.DownArrow:
                    // ...
                case ConsoleKey.UpArrow:
                    // ...
                case ConsoleKey.LeftArrow:
                    // ...
                case ConsoleKey.RightArrow:
                    // SaveState()
                    if(Console.CursorLeft < Console.WindowWidth - 2)
                    {
                        currentPosition = new Cell(
                            Console.CursorLeft + 1, Console.CursorTop);
                    }
                    // Only type Cell allowed in call to Push()
                    path.Push(currentPosition);
                    FillCell(currentPosition);
                    break;
 
                default:
                    Console.Beep();
                    break;
            }
 
        }
        while(key.Key != ConsoleKey.X);  // Use X to quit
    }
    // ...
}
Output 12.2

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.

Defining a Simple Generic Class

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.

Listing 12.7: Declaring a Generic Class, Stack<T>
public class Stack<T>
{
    public Stack(int maxSize)
    {
        InternalItems = new T[maxSize];
    }
 
    private T[] InternalItems { get; }
 
    public void Push(T data)
    {
        //...
    }
 
    public T Pop()
    {
        // ...
    }
}
Benefits of Generics

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):

1.
Generics facilitate increased type safety, preventing data types other than those explicitly intended by the members within the parameterized class. In Listing 12.7, the parameterized stack class restricts you to the Cell data type when using Stack<Cell>. For example, the statement path.Push("garbage") produces a compile-time error indicating that there is no overloaded method for System.Collections.Generic.Stack<T>.Push(T) that can work with the string, because it cannot be converted to a Cell.
2.
Compile-time type checking reduces the likelihood of InvalidCastException type errors at runtime.
3.
Using value types with generic class members no longer causes a boxing conversion to object. For example, path.Pop() and path.Push() do not require an item to be boxed when added or unboxed when removed.
4.
Generics in C# reduce code bloat. Generic types retain the benefits of specific class versions, without the overhead. For example, it is no longer necessary to define a class such as CellStack.
5.
Performance improves because casting from an object is no longer required, thereby eliminating a type check operation. Also, performance improves because boxing is no longer necessary for value types.
6.
Generics reduce memory consumption by avoiding boxing and thus consuming less memory on the heap.
7.
Code becomes more readable because of fewer casting checks and because of the need for fewer type-specific implementations.
8.
Editors that assist coding via some type of IntelliSense work directly with return parameters from generic classes. There is no need to cast the return data for IntelliSense to work.

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.

Type Parameter Naming Guidelines

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.

Guidelines
DO choose meaningful names for type parameters and prefix the name with T.
CONSIDER indicating a constraint in the name of a type parameter.
Generic Interfaces and Structs

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.

Listing 12.8: Declaring a Generic Interface
interface IPair<T>
{
    T First { get; set; }
    T Second { get; set; }
}

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.

Listing 12.9: Implementing a Generic Interface
public struct Pair<T> : IPair<T>
{
    public T First { get; set; }
    public T Second { get; set; }
}

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.

AdVanced Topic
Implementing the Same Interface Multiple Times on a Single Class

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.

Listing 12.10: Duplicating an Interface Implementation on a Single Class
public interface IContainer<T>
{
    ICollection<T> Items { get; set; }
}
 
public class Person : IContainer<Address>,
    IContainer<Phone>, IContainer<Email>
{
    ICollection<Address> IContainer<Address>.Items
    {
        get
        {
            // ...
        }
        set
        {
            //...
        }
    }
    ICollection<Phone> IContainer<Phone>.Items
    {
        get
        {
            // ...
        }
        set
        {
            //...
        }
    }
    ICollection<Email> IContainer<Email>.Items
    {
        get
        {
            // ...
        }
        set
        {
            //...
        }
    }
}

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.

Guidelines
AVOID implementing multiple constructions of the same generic interface in one type.

Defining a Constructor and a Finalizer

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: Declaring a Generic Type’s Constructor
public struct Pair<T> : IPair<T>
{
    public Pair(T first, T second)
    {
        First = first;
        Second = second;
    }
 
    public T First { get; set; }
    public T Second { get; set; }
}
Specifying a Default Value with the default operator

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.

Listing 12.12: Not Initializing All Fields, Causing a Compile-Time Error
public struct Pair<T> : IPair<T>
{
    // ERROR:  Field 'Pair<T>.Second' must be fully assigned
    //         before control leaves the constructor
    // public Pair(T first)
    // {  
    //     First = first;
    // }
 
    // ...
}

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.

Listing 12.13: Initializing a Field with the default Operator
public struct Pair<T> : IPair<T>
{
    public Pair(T first)
    {
        First = first;
        // ...
        Second = default;
        // ...
    }
    // ...
}

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.)

Multiple Type Parameters

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.

Listing 12.14: Declaring a Generic with Multiple Type Parameters
interface IPair<TFirst, TSecond>
{
    TFirst First { get; set; }
    TSecond Second { get; set; }
}
 
public struct Pair<TFirst, TSecond> : IPair<TFirst, TSecond>
{
    public Pair(TFirst first, TSecond second)
    {
        First = first;
        Second = second;
    }
 
    public TFirst First { get; set; }
    public TSecond Second { get; set; }
}

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.

Listing 12.15: Using a Type with Multiple Type Parameters
Pair<int, string> historicalEvent =
    new(1914,
        "Shackleton leaves for South Pole on ship Endurance");
 
Console.WriteLine("{0}: {1}",
    historicalEvent.First, historicalEvent.Second);

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.

Guidelines
DO place multiple generic semantically equivalent classes into a single file if they differ only by the number of generic parameters.
Beginner Topic
Tuples: An Abundance of Arity

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.

Listing 12.16: Using Arity to Overload a Type Definition
public class Tuple
{
    // ...
}
public class Tuple<T1> // : IStructuralEquatable,
                       // IStructuralComparable, IComparable
{
    // ...
}
public class Tuple<T1, T2> // : IStructuralEquatable,
                           // IStructuralComparable, IComparable
{
    // ...
}
public class Tuple<T1, T2, T3> // : IStructuralEquatable,
                               // IStructuralComparable, IComparable
{
    // ...
}
public class Tuple<T1, T2, T3, T4> // : IStructuralEquatable,
                                   // IStructuralComparable, IComparable
{
    // ...
}
public class Tuple<T1, T2, T3, T4, T5> // : IStructuralEquatable,
                                       // IStructuralComparable,
                                       // IComparable
{
    // ...
}
public class Tuple<T1, T2, T3, T4, T5, T6> 
    // : IStructuralEquatable, IStructuralComparable, IComparable
{
    // ...
}
public class Tuple<T1, T2, T3, T4, T5, T6, T7> 
    // : IStructuralEquatable, IStructuralComparable, IComparable
{
    // ...
}
public class Tuple<T1, T2, T3, T4, T5, T6, T7, TRest> 
    // : IStructuralEquatable, IStructuralComparable, IComparable
{
    // ...
}

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

Listing 12.17: Comparing System.ValueTuple Instantiation Approaches
#if !PRECSHARP7
(string, Contact) keyValuePair;
keyValuePair =
    ("555-55-5555", new Contact("Inigo Montoya"));
#else // Use System.ValueTupe<string,Contact> prior to C# 7.0
ValueTuple<string, Contact> keyValuePair;
keyValuePair =
    ValueTuple.Create(
        "555-55-5555", new Contact("Inigo Montoya"));
keyValuePair =
    new ValueTuple<string, Contact>(
        "555-55-5555", new Contact("Inigo Montoya"));
#endif // !PRECSHARP7

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.)

Nested Generic Types

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).

Listing 12.18: Nested Generic Types
public class Container<T, U>
{
    // Nested classes inherit type parameter
    // Reusing a type parameter name will cause
    // a warning
    public class Nested<U>
    {
        static void Method(T param0, U param1)
        {
        }
    }
}

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.

Guidelines
AVOID shadowing a type parameter of an outer type with an identically named type parameter of a nested type.

________________________________________

2. Assuming C# 7.1.
3. Introduced in C# 7.1.
4. Assigning default to a reference type in C# 7.0 or earlier produces a warning.
5. Simpler for C# 6.0.
6. Similar tuple class added in C# 4.0: System.Tuple.
7. Created due to C# 7.0’s abundant tuple syntax.
{{ snackbarMessage }}
;