Generics & Templates

The problem: untyped containers force casts and crash late

Before generics, a reusable container held anything — Object in Java, any in TypeScript, void* in C. That sounds flexible, but it has two ugly costs. First, everything you take out has lost its type, so you must cast it back and hope you guessed right. Second, nothing stops you putting the wrong thing in — the mistake only surfaces later, as a runtime crash, often far from where the bug was written:

// Pre-generics: a box of Object holds anything — and lies to you.
List box = new ArrayList();   // raw, untyped
box.add("hello");             // a String slips in by mistake
box.add(42);                  // ...so does an int

Integer n = (Integer) box.get(0); // cast — compiles fine
// ClassCastException at RUNTIME: "hello" is not an Integer.

The other escape hatch is just as bad: writing the same class twice — an IntStack, then a StringStack, then a UserStack — each a copy-paste with one type swapped. Now a bug fixed in one is still alive in the other two.

The fix: a type parameter `T`

A generic introduces a type parameter — a placeholder, conventionally named T — that you fill in when you use the type. You write Box<T> once; callers create Box<number>, Box<string>, or Box<User>. Inside the class, T stands for whichever type the caller chose, so push accepts a T and pop returns a T — no casting on the way out.

class Box<T> {           // T is a type parameter
  private items: T[] = [];
  push(item: T): void { this.items.push(item); }
  pop(): T | undefined { return this.items.pop(); }
  peek(): T | undefined { return this.items[this.items.length - 1]; }
}

const nums = new Box<number>();
nums.push(42);     // ok
const n = nums.pop();   // n is number — no cast needed

Compile-time safety: the wrong type is rejected before it runs

This is the payoff. Once a box is Box<number>, the compiler knows push only takes a number. Hand it a string and the program never even runs — you get an error at your desk, not a 2am page:

const nums = new Box<number>();
nums.push("oops");
// ✗ Compile error: Argument of type 'string'
//   is not assignable to parameter of type 'number'.

Bounded type parameters: "any T, but it must be able to…"

Sometimes "any type" is too loose — you need a T that supports a particular operation. A bounded type parameter constrains it. T extends Comparable means "any type, as long as it can be compared" — so inside the generic you can safely call a.compareTo(b). You keep the reuse, but the compiler guarantees the capability you depend on.

// T must be Comparable, so a.compareTo(b) is guaranteed to exist.
static <T extends Comparable<T>> T max(T a, T b) {
    return a.compareTo(b) >= 0 ? a : b;
}
max(3, 7);            // ok — Integer is Comparable
max("ant", "bee");    // ok — String is Comparable
// max(new Thread(), new Thread()); // ✗ Thread isn't Comparable

Reach for generics when…

• You're writing a container or collection — a stack, queue, cache, list, tree — that should work for any element type without you rewriting it per type.
• You catch yourself copy-pasting a class and swapping one type (IntStack → StringStack). That duplication is the signal: parameterize it with T instead.
• An algorithm is shape-agnostic — max, swap, map, filter — and only needs the element to support a small capability. Use a bounded parameter (T extends Comparable) to require exactly that capability and no more.