Subtyping in Kotlin: The Three Golden Rules for Safer, Flexible Code

 Master the logic behind inheritance and generics using variance and the Liskov Substitution Principle.

Subtyping in Kotlin

Understanding subtyping is the “secret sauce” for writing flexible, professional Kotlin code. It’s the logic that determines when one type can safely stand in for another. While it sounds academic, these rules are the foundation of everything from basic inheritance to complex generics.

Let’s break down subtyping through the three rules that govern how Kotlin decides if your code is safe.

The Three Golden Rules of Subtyping

For a type Sub to be a valid subtype of Super (meaning you can substitute Sub wherever Super is expected), it must follow these three laws for every public function.

Rule 1: Same Operations (The Contract)

A subtype must offer at least all the public operations that its supertype provides. If you expect a Machine to start(), any subtype of Machine must also be able to start().

interface Beverage {
    fun pour()
}

class Coffee : Beverage {
    override fun pour() { println("Pouring dark roast...") }
    fun brew() { println("Brewing...") } // Subtypes can add more!
}

Kotlin’s Take: The compiler enforces this automatically. You cannot implement an interface or extend a class without satisfying its method requirements.

Rule 2: Contravariant Parameters (The Inputs)

Theoretically, for a method to be “safer” in a subtype, it should be able to handle more general inputs. If a Baker can handle Flour, a MasterBaker should be able to handle AnyIngredient.

The Logic: Contravariance is a property of types, not method overrides. While the theory says it’s safe to accept broader types, Kotlin prioritizes consistency in its overrides.

⚠️ The Kotlin Catch: Kotlin does not allow you to change parameter types when overriding methods.

open class Oven {
    open fun bake(item: Flour) { ... }
}

class ProOven : Oven() {
    // ❌ This is NOT allowed in Kotlin overrides! 
    // Parameters must remain invariant (the exact same type).
    override fun bake(item: Ingredient) { ... } 
}

Instead, Kotlin exposes contravariance through generics using the in keyword.

Rule 3: Covariant Return Types (The Outputs)

This is the most intuitive rule: A subtype’s method must return a type that is the same as or more specific than the supertype’s return type. If a Factory produces a Vehicle, a TeslaFactory can specifically produce a ModelS.

open class Result
class Success : Result()

interface Task {
    fun run(): Result
}

class CriticalTask : Task {
    // ✅ Valid: Success is a subtype of Result. 
    // This is a "Covariant Return Type."
    override fun run(): Success = Success()
}

Variance: Rules in Action

Kotlin uses in and out to apply these rules to generic classes.

1. out (Producer - Covariance)

When you use out, you promise the compiler that the class will only output (return) the type T. This satisfies Rule 3.

interface Source<out T> {
    fun produce(): T 
}

val petStore: Source<Dog> = DogStore()
val animalStore: Source<Animal> = petStore // ✅ Safe: Every Dog is an Animal

2. in (Consumer - Contravariance)

When you use in, you promise the class will only consume (input) the type T. This satisfies Rule 2.

interface Consumer<in T> {
    fun consume(item: T)
}

val generalProcessor: Consumer<Animal> = AnimalProcessor()
val dogProcessor: Consumer<Dog> = generalProcessor // ✅ Safe: Consumers are contravariant

Use-Site Variance: Type Projections

Sometimes you use a class you didn’t write, which isn’t marked with in or out. You can project variance at the moment you use it.

The out Projection

MutableList<out Animal> tells Kotlin: "I only want to read from this list."

  • Crucial Note: This restriction applies even to MutableList, which is otherwise invariant. By adding out, you gain the ability to treat a MutableList<Cat> as a MutableList<out Animal>, but you lose the ability to .add() anything to it.

The in Projection

MutableList<in Dog> tells Kotlin: "I only want to put Dogs into this list."

  • Handling Returns: Kotlin restricts reading values of type T and widens the return type (typically to Any?) to prevent unsafe assumptions. Because the list could actually be a MutableList<Animal>, Kotlin cannot guarantee that get() will return a Dog.

Star Projections (*)

List<*> behaves like List<out Any?> in most cases. You can safely read values as Any? (the top of the type hierarchy), but you cannot write into it. It is the ultimate "read-only" safety net.

Frequently Asked Questions (FAQs)

Why doesn’t Kotlin allow contravariant overrides if the rule says they are safe?

It’s a design choice to avoid complexity and ambiguity. Kotlin prefers to handle parameter variance through generics (in), keeping method signatures predictable.

What is the “Liskov Substitution Principle” I keep hearing about?

It’s the academic name for these rules! It states that if S is a subtype of T, then objects of type T may be replaced with objects of type S without breaking the program.

When should I use star projection over out Any??

Use star projection (*) when you genuinely don't know or care about the type argument. It’s cleaner and tells other developers, "I'm just looking at the structure, not the specific data."

Let’s Discuss!

  • Which of the three rules was most surprising to you?
  • Do you prefer defining variance at the interface level (declaration-site) or when calling functions (use-site)?
  • What’s the most confusing “Type Mismatch” error you’ve ever encountered?

📘 Master Your Next Technical Interview

Since Java is the foundation of Android development, mastering DSA is essential. I highly recommend “Mastering Data Structures & Algorithms in Java”. It’s a focused roadmap covering 100+ coding challenges to help you ace your technical rounds.

Comments

Post a Comment

Popular posts from this blog

Stop Writing Massive when Statements: Master the State Pattern in Kotlin

Image
 Tame Your Codebase with Elegant, Scalable, and Type-Safe State Machines Do you manage complex objects that change their behavior dramatically based on their internal status? If so, you’ve likely battled a common foe: the sprawling  when  statement that haunts every method in your class. It looks something like this: fun handleAction () { when (state) { State.A -> { /* logic for A */ } State.B -> { /* logic for B */ } State.C -> { /* logic for C */ } // ... and the list keeps growing! } } Every time you add a new state (e.g.,  State.D ), you have to hunt down and update  every single function  with a new case. This is a maintenance nightmare, a direct violation of the  Open/Closed Principle  (OCP), and a major code smell. Your logic is scattered by  action  when it should be grouped by  state . The solution? The  State Pattern . And with modern Kotlin, we can implement it w...
Read more

Coroutines & Flows: 5 Critical Anti-Patterns That Are Secretly Slowing Down Your Android App

Image
 Stop sneaky performance killers. Spot and fix Kotlin issues that cause crashes, memory leaks, and laggy UIs. Coroutines and Kotlin Flows are the bedrock of modern asynchronous programming on Android. They allow us to write clean, sequential-looking code that manages complex background operations, network calls, and database transactions. But power comes with responsibility. Many developers, despite using Coroutines daily, unknowingly introduce subtle mistakes —  anti-patterns  — that lead to memory leaks, silent crashes, data loss, and UI jank. Based on insights from top-tier Android development, here are five critical Coroutine and Flow anti-patterns you must identify and fix today, plus one bonus pitfall I often see in code reviews. 1. The Main Thread Trap: Heavy Work in  viewModelScope When you launch a coroutine inside a  ViewModel  using  viewModelScope.launch { ... } , where do you think that work runs by default? The  Main Thread ! If your...
Read more

Code Generation vs. Reflection: A Build-Time Reliability Analysis

Image
 Choose compile-time safety over runtime simplicity to ensure better R8 optimization, avoid reflection issues, and cut production crashes. The world of Android development offers numerous ways to achieve the same goal, but not all paths are created equal. When it comes to tasks like dependency injection, JSON parsing, or database interaction, two prominent approaches stand out: Code Generation and Reflection. While reflection might seem appealing for its initial simplicity, a deeper dive reveals that   Code Generation offers superior build-time reliability and R8 compatibility , making it the more robust choice for production-ready applications. The Allure of Reflection: Simplicity at a Cost Reflection, at its core, allows a program to inspect and modify its own structure and behavior at runtime. This dynamic nature can be incredibly powerful, enabling libraries to work with classes and their members without needing to know them at compile time. Example: A (simplified) Reflect...
Read more