Unmasking the Magic: Demystifying Double Dispatch and the Visitor Pattern in Kotlin

 Master single dispatch limitations and learn idiomatic Kotlin techniques to handle complex object interactions with ease.

Double Dispatch and the Visitor Pattern in Kotlin

Ever felt like your code was playing hide-and-seek with types at runtime? You want a specific interaction between two objects, but the language only seems to look at one of them. Welcome to the world of Single Dispatch, and the fascinating techniques we use to break free: Double Dispatch and its powerful cousin, the Visitor Pattern.

The Single Dispatch Conundrum

Most object-oriented languages, including Kotlin and Java, use Single Dispatch. This means when you call objectA.doSomething(objectB), the version of the method that runs is chosen based only on the runtime type of objectA (the receiver). The runtime type of objectB (the argument) is ignored; only its declared compile-time type matters.

Imagine a Vehicle hierarchy and a Road hierarchy:

interface Road
data object DirtRoad : Road
data object Highway : Road

interface Vehicle {
    fun driveOn(road: Road) {
        println("A generic vehicle drives on a generic road.")
    }
}

class Car : Vehicle {
    override fun driveOn(road: Road) {
        // Even if 'road' is a DirtRoad, the compiler only sees it as 'Road'
        println("A car drives on a generic road.") 
    }
}

Classic Double Dispatch: The Two-Step Dance

To solve this, we use a “flip-flop” mechanism. Instead of one object trying to guess the other’s type, they work together:

  1. The Vehicle calls a method on the Road.
  2. The Road calls a method back on the Vehicle, passing itself as this.
interface Road {
    fun accept(car: Car)
    fun accept(truck: Truck)
}

data object DirtRoad : Road {
    override fun accept(car: Car) = println("Car kicks up dust on Dirt Road!")
    override fun accept(truck: Truck) = println("Truck rumbles on Dirt Road.")
}

class Car : Vehicle {
    override fun driveOn(road: Road) = road.accept(this) // The Flip!
}

The Kotlin Way: Sealed Types and when

While the classic approach works, it’s boilerplate-heavy. Note: Kotlin does not have native “Multiple Dispatch,” but we can simulate it elegantly using sealed hierarchies.

This is a language-assisted workaround. It’s not true dispatch (it’s type checking), but in practice, it achieves the same result with more safety.

sealed interface Road {
    data object DirtRoad : Road
    data object Highway : Road
}

class Car : Vehicle {
    override fun driveOn(road: Road) {
        when (road) {
            is Road.DirtRoad -> println("Car vs Dirt")
            is Road.Highway -> println("Car vs Highway")
        }
    }
}

The Trade-off: This approach is asymmetric. It works best when the Road hierarchy is stable (closed). If you add a new road type, you must update every when expression across all vehicles.

The Visitor Pattern: Double Dispatch for Operations

The Visitor Pattern is essentially “Double Dispatch as a Service.” It allows you to add new operations to an existing object structure without modifying the objects themselves.

For the following example, imagine we want to generate an Inspection Report. By using Generics (<R>), our Visitor can now return values!

// 1. The Visitor (The "Operation")
interface VehicleVisitor<R> {
    fun visit(car: Car): R
    fun visit(truck: Truck): R
}

// 2. The Elements (The "Data")
interface Vehicle {
    fun <R> accept(visitor: VehicleVisitor<R>): R
}

class Car : Vehicle {
    override fun <R> accept(visitor: VehicleVisitor<R>): R = visitor.visit(this)
}

// 3. Concrete Operation: Generating a Report
class SafetyReport : VehicleVisitor<String> {
    override fun visit(car: Car) = "Car: Airbags Checked."
    override fun visit(truck: Truck) = "Truck: Air Brakes Checked."
}

Frequently Asked Questions (FAQs)

Is Kotlin’s when better than the Visitor Pattern?

If you own the code and one hierarchy is stable, when is more idiomatic. If you are building a library where users need to add their own "inspections" without changing your Vehicle classes, use the Visitor Pattern.

Why do we say when is not "true" dispatch?

Dispatch is a polymorphic selection handled by the language runtime. when is a conditional check. While the result is similar, dispatch is generally more extensible in open systems.

Can a Visitor return a value?

Yes! By using generics like VehicleVisitor<R>, you can make your visitors return strings, integers, or even other objects, making the pattern much more useful for data processing.

Questions for You:

  • In your current project, do you have a hierarchy that is “stable” enough to benefit from sealed interfaces?
  • Have you ever struggled with instanceof checks in Java? How does Kotlin's when change your perspective on that?

📘 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