Generic class declaration in Kotlin - Deep Dive

Overview - Generic class declaration

What is it?

A generic class in Kotlin is a blueprint for creating classes that can work with any data type. Instead of specifying a fixed type, you use a placeholder that gets replaced with a real type when you create an object. This makes your code flexible and reusable for different types without rewriting it. It’s like having a mold that can shape different materials depending on what you need.

Why it matters

Without generic classes, programmers would have to write many versions of the same class for different data types, which is time-consuming and error-prone. Generics solve this by allowing one class to handle many types safely and clearly. This reduces bugs, saves time, and makes code easier to maintain and understand.

Where it fits

Before learning generic classes, you should understand basic class declarations and type systems in Kotlin. After mastering generics, you can explore advanced topics like generic functions, variance (in/out), and type constraints to write even more powerful and safe code.

Mental Model

Core Idea

A generic class is a flexible template that works with any type, letting you write one class that adapts to many data types.

Think of it like...

Imagine a cookie cutter that can shape dough into any cookie shape you want by swapping the cutter’s shape. The generic class is the cookie cutter, and the type you choose is the cookie shape.

GenericClass<T>
  ├─ Property: T
  ├─ Method: uses T
  └─ Instance: GenericClass<Int>, GenericClass<String>, etc.

Build-Up - 7 Steps

1

Foundation

Basic class declaration review

Concept: Understanding how to declare a simple class in Kotlin without generics.

class Box { var value: Any? = null } val box = Box() box.value = 123 println(box.value) // prints 123

Result

The Box class holds any value but without type safety, so you can put anything inside.

Knowing simple classes is essential before adding the flexibility of generics.

2

Foundation

Introducing type parameters

Concept: Learn how to declare a class with a type parameter to make it generic.

class Box { var value: T? = null } val intBox = Box() intBox.value = 123 println(intBox.value) // prints 123

Result

Box now holds a value of a specific type, here Int, ensuring type safety.

Type parameters let classes adapt to different data types while keeping safety.

3

Intermediate

Using generic classes with multiple types

Concept: Declaring a generic class with more than one type parameter.

class PairBox(var first: A, var second: B) val pair = PairBox("age", 30) println(pair.first) // prints "age" println(pair.second) // prints 30

Result

The class can now hold two different types, increasing flexibility.

Multiple type parameters allow combining different types in one class cleanly.

4

Intermediate

Type inference with generic classes

Concept: Kotlin can often infer the type parameters, so you don’t always need to specify them explicitly.

val box = Box("Hello") // Kotlin infers Box println(box.value) // prints "Hello"

Result

Code is shorter and easier to read without losing type safety.

Type inference reduces boilerplate and makes generics friendlier to use.

5

Intermediate

Generic class with constructor parameters

Concept: Using generic types in constructor parameters and properties.

class Container(var content: T) val container = Container(3.14) println(container.content) // prints 3.14

Result

Generic types can be used anywhere in the class, including constructors.

This shows how generics integrate naturally with class design.

6

Advanced

Type constraints in generic classes

🤔Before reading on: do you think you can restrict a generic type to only certain types? Commit to your answer.

Concept: You can limit the types a generic class accepts using type constraints to ensure certain capabilities.

class NumberBox(var number: T) val intBox = NumberBox(10) // OK // val stringBox = NumberBox("text") // Error: String is not a Number

Result

The class only accepts types that are subclasses of Number, preventing errors.

Type constraints enforce rules on generics, improving safety and intent clarity.

7

Expert

How generics work at runtime in Kotlin

🤔Quick: Do you think Kotlin keeps generic type information at runtime? Commit to yes or no.

Concept: Kotlin uses type erasure, meaning generic type information is mostly removed at runtime, affecting some operations.

fun printType(value: T) { println(value?.javaClass?.name ?: "null") } printType(123) // prints java.lang.Integer printType(listOf(1, 2, 3)) // prints java.util.Arrays$ArrayList // But you cannot check T directly at runtime due to erasure.

Result

Generic types are erased at runtime, so some type checks or casts need special handling.

Understanding type erasure explains why some generic operations are limited or require workarounds.

Under the Hood

Kotlin generics are implemented using type erasure, which means the compiler removes generic type information during compilation. This allows the generated bytecode to be compatible with Java’s type system. At runtime, the generic types are replaced with their upper bounds or Object if none is specified. This means the JVM does not know the exact generic types, which limits some operations like type checks or casts on generic parameters.

Why designed this way?

Type erasure was chosen to maintain compatibility with Java and avoid increasing runtime overhead. It allows Kotlin to interoperate smoothly with Java libraries and the JVM ecosystem. Alternatives like reified types exist but require inline functions and have their own tradeoffs. This design balances flexibility, performance, and compatibility.

┌─────────────────────────────┐
│ Kotlin Generic Class<T>      │
│                             │
│  Compile-time:              │
│  - T is a placeholder       │
│  - Checks type safety       │
│                             │
│  Runtime (JVM):             │
│  - T replaced by upper bound│
│  - No T type info available │
└─────────────┬───────────────┘
              │
              ▼
    Bytecode with erased types

Myth Busters - 4 Common Misconceptions

Quick: Can you check the exact generic type of a class at runtime in Kotlin? Commit yes or no.

Common Belief: You can always check the generic type of an object at runtime using reflection.

Reality: Due to type erasure, generic type information is not available at runtime, so you cannot reliably check it.

Why it matters: Assuming you can check generic types at runtime leads to bugs when your code tries to cast or check types and fails unexpectedly.

Quick: Do generic classes create multiple copies of the class for each type? Commit yes or no.

Common Belief: Each generic type creates a new class in memory, increasing size and load time.

Reality: Generics use type erasure, so only one class exists regardless of how many types are used.

Why it matters: Thinking generics duplicate classes can cause unnecessary worry about performance and memory.

Quick: Can you use primitive types like Int directly as generic parameters without boxing? Commit yes or no.

Common Belief: Generic classes work with primitive types without any overhead or boxing.

Reality: Primitive types are boxed into their wrapper classes when used as generic parameters, which can affect performance.

Why it matters: Ignoring boxing can lead to performance issues in tight loops or memory-critical code.

Quick: Does declaring a generic class mean you must always specify the type parameter explicitly? Commit yes or no.

Common Belief: You always have to write the type parameter when creating an instance of a generic class.

Reality: Kotlin often infers the type parameter from constructor arguments, so explicit specification is not always needed.

Why it matters: Not knowing about type inference can make code more verbose and harder to read than necessary.

Expert Zone

1

Generic type parameters can have multiple constraints using where clauses, allowing very precise type requirements.

2

Reified type parameters in inline functions let you access type information at runtime, bypassing type erasure but only in limited contexts.

3

Variance annotations (in/out) on generic classes affect how subtyping works and are crucial for safe API design but are often misunderstood.

When NOT to use

Avoid generic classes when the type is always fixed or when runtime type information is critical and cannot be worked around. In such cases, use sealed classes, inheritance, or specific classes instead.

Production Patterns

In production, generic classes are used for collections, wrappers, and utility classes to maximize code reuse. Patterns include using type constraints to enforce domain rules, combining generics with delegation, and leveraging inline reified functions for type-safe operations.

Connections

Polymorphism

Generics build on polymorphism by allowing code to work with any type, not just subclasses.

Understanding generics deepens your grasp of polymorphism by showing how type flexibility can be achieved without inheritance.

Templates in C++

Generics in Kotlin are similar to C++ templates but differ in implementation and runtime behavior.

Comparing Kotlin generics with C++ templates highlights tradeoffs between compile-time code generation and runtime type erasure.

Mathematical functions

Generic classes are like mathematical functions with variables that can take any value from a set.

Seeing generics as functions with variable inputs helps understand their flexibility and constraints.

Common Pitfalls

#1 Trying to check generic type at runtime directly.

Wrong approach:

if (obj is Box) { println("It's a Box of String") }

Correct approach:

Use inline reified functions to check type:
inline fun isBoxOfType(obj: Any) = obj is Box

Root cause:

Misunderstanding that type erasure removes generic type info at runtime.

#2 Using Any instead of generics for flexibility.

Wrong approach:

class Box {
var value: Any? = null
}

Correct approach:

class Box {
var value: T? = null
}

Root cause:

Not realizing generics provide type safety and flexibility together, unlike Any which loses type safety.

#3 Forgetting to specify type constraints when needed.

Wrong approach:

class NumberBox(var number: T) // allows any type

Correct approach:

class NumberBox(var number: T) // restricts to Number types

Root cause:

Not understanding how to limit generic types to ensure correct usage.

Key Takeaways

Generic classes let you write flexible, reusable code that works with any data type safely.

Kotlin uses type erasure, so generic type information is mostly lost at runtime, affecting some operations.

Type constraints let you restrict generic types to ensure your class only works with suitable types.

Kotlin’s type inference often removes the need to explicitly specify generic types, making code cleaner.

Understanding generics deeply improves your ability to design safe, efficient, and reusable software components.