A generic class is an ordinary class with one extra decision deferred to whoever uses it: which type(s) it actually works with.

In the previous lesson you saw why generics exist by looking at a tiny Box<T>. Now it's time to build a real one yourself — a class with multiple type parameters, generic fields, generic properties, and generic methods, the same building blocks that List<T> and Dictionary<TKey, TValue> are made of.

In this lesson, you'll write a generic class from scratch, learn how to declare and use more than one type parameter at once, and see how ordinary class members — fields, properties, constructors, methods — work once their containing class is generic.

What Is It?

The Simple Explanation

A generic class is a class declared with one or more type parameters in angle brackets right after its name — class Repository<T>, class Pair<T1, T2>. Inside the class body, those type parameters behave exactly like real types: you can use them for fields, properties, method parameters, method return types, and local variables. The actual, concrete type only gets decided when someone creates an instance.

The Technical Definition

A generic class definition is an open generic type — it isn't a complete, usable type by itself, only a template. Supplying type arguments (Repository<Product>) produces a closed generic type (also called a constructed type) — a fully concrete type the compiler can check against and the runtime can instantiate. Everything inside the class — its fields, properties, and methods — can reference the class's own type parameters freely, as if they were ordinary types.

Why Does It Exist?

The Problem

Consider a very common real-world need: a data-access layer that fetches, adds, and removes entities by ID. Without generics, you'd write this once per entity type:

These two classes are identical in every way except the type they store. Any bug fix, or any new feature (like a Count property), must be applied to both — and to every future repository you add for every future entity type.

The Solution

Making the class itself generic collapses this into one definition that works for any entity type, with full compile-time type safety preserved for every usage:

One class. Every entity type gets its own fully type-checked, independent repository instance, and a bug fix to Repository<T> automatically benefits every entity type that uses it.

Big Picture

public class Repository<T>    ← open generic type (the template)

How It Works

public class Pair<T1, T2>
{
    // two independent placeholders
}

public class Pair<T1, T2>
{
    public T1 First { get; }
    public T2 Second { get; }

    public Pair(T1 first, T2 second)
    {
        First = first;
        Second = second;
    }
}

Pair<string, int> nameAndAge = new("Ana", 29);
Console.WriteLine($"{nameAndAge.First} is {nameAndAge.Second}");

Simple Example

Code → Meaning → Result:

• Pair<T1, T2> stores two independently-typed values with full type safety for both.
• Swap() returns a different closed generic type — Pair<T2, T1> — built entirely from the class's own type parameters, with the order reversed.
• Nothing here needed object or a cast anywhere — First is always genuinely a string, Second always genuinely an int, for this particular instance.

Real-World Example

A generic Repository<T> is one of the most common generic classes you'll build in real applications — a reusable data-access layer that works for any entity, as long as it can identify entities by an Id.

Notice that products and customers are completely independent instances — each one is its own closed generic type (Repository<Product> and Repository<Customer>), with its own private _items dictionary. There's no risk of accidentally storing a Customer where a Product was expected — the compiler simply won't allow it.

Analogy

Under the Hood

Common Confusion

1. "Multiple type parameters" doesn't mean they must be related

Pair<T1, T2>'s two type parameters are completely independent — you could construct Pair<string, string>, Pair<int, Product>, or anything else. Compare that to Dictionary<TKey, TValue>, which also has two independent type parameters — a key type and a value type that don't need to match either.

2. A generic class's own type parameters are visible everywhere inside it

You don't need to redeclare T for each method inside a generic class — once the class itself is declared class Repository<T>, every instance member (fields, properties, non-static methods) can use T freely without repeating the declaration. The next lesson covers the different case — a method that needs a type parameter of its own

3. Primary constructors work on generic classes too