Section 1.1: A Simple Analogy: The Beverage Vending Machine

Consider a straightforward example: a beverage vending machine that accepts payment and dispenses drinks. While this analogy may be basic, it paves the way for a more profound exploration of variance. Some machines are tailored to dispense soft drinks, while others are specifically designed for coffee. Both soft drinks and coffee fall under the broader category of beverages.

In Kotlin, we can model our beverages as follows:

open class Beverage

class SoftDrink : Beverage()

class Coffee : Beverage()

Section 1.2: Covariance: Coffee Machines as a Type of Beverage Dispenser

Every beverage vending machine is fundamentally built for dispensing drinks. This shared purpose means that a coffee vending machine can logically be regarded as a subtype of a general beverage dispenser. Here’s how this is expressed in Kotlin:

class VendingMachine<T> {

fun dispense(): T? = null

}

val coffeeVendingMachine = VendingMachine<Coffee>()

val softDrinkVendingMachine = VendingMachine<SoftDrink>()

val beverageVendingMachine1: VendingMachine<Beverage> = coffeeVendingMachine

val beverageVendingMachine2: VendingMachine<Beverage> = softDrinkVendingMachine

// This will result in a compilation error due to type mismatch.

val invalid: VendingMachine<Beverage> = VendingMachine<Beverage>()

In this example, the VendingMachine class features a single generic parameter. The out keyword preceding this parameter indicates covariance, allowing instances of this generic class to maintain the same inheritance relationships as their respective parameter types.

Section 1.3: The Significance of the out Keyword

The out keyword plays a crucial role in ensuring the Kotlin compiler uses type T solely as a return type, prohibiting its use as a function parameter. This is important for methods designed to refill our vending machine:

class VendingMachine<T> {

fun dispense(): T? = null

// Compile error!

fun fill(beverages: List<T>): Unit = TODO()

}

This design is unworkable because you cannot stock a coffee vending machine with soft drinks. This limitation indicates that VendingMachine<Coffee> is not genuinely a subtype of VendingMachine<Beverage>. To address this, you would need to remove the out keyword, shifting VendingMachine to invariance—a concept we will examine shortly.

Section 1.4: Contravariance: Accepting All Payment Methods

Before quenching our thirst with a beverage, we must consider the payment process.

open class PaymentMethod

class Cash : PaymentMethod()

class CreditCard : PaymentMethod()

class PaymentProcessor<P> {

fun process(payment: P): Unit = TODO()

}

val coinSlot: PaymentProcessor<Cash> = PaymentProcessor()

val creditCardTerminal: PaymentProcessor<CreditCard> = PaymentProcessor()

// Type mismatch, does not compile.

val coinSlotWithCreditCardTerminal: PaymentProcessor<Cash> = PaymentProcessor()

Here, the PaymentProcessor is contravariant, meaning the inheritance relationship is inverted: a PaymentProcessor<PaymentMethod> can be viewed as a subtype of PaymentProcessor<Cash>.

Section 1.5: Invariance: Specific Machines Require Specific Manuals

Imagine a scenario where a vending machine encounters a malfunction. To resolve the issue, you would refer to its specific repair manual. However, can you fix a coffee vending machine using just a general vending machine manual? Not really. A broad manual may provide guidance on basic maintenance, but it would lack detailed instructions for particular components, such as the coffee grinder.

class RepairManual<T>

val genericManual = RepairManual<Beverage>()

val coffeeMachineManual = RepairManual<Coffee>()

val invalid: RepairManual<PaymentMethod> = genericManual

val invalid2: RepairManual<Coffee> = coffeeMachineManual

In this instance, RepairManual is invariant, meaning it doesn’t adopt any inheritance relationships from its type parameters. Specificity is key, and a manual designed for one machine type cannot be interchanged with another.

A Brief Excursion: The Pitfalls of Variance in Java Arrays

Java arrays are covariant, which may seem advantageous at first glance, but can lead to unexpected runtime exceptions. Here’s a classic example of where this can go wrong:

Object[] objectArray = new String[10];

objectArray[0] = new Integer(42); // Throws ArrayStoreException at runtime

The code above compiles without issue but will throw an ArrayStoreException at runtime. Even though String[] is a subtype of Object[] (due to covariance), you cannot safely insert any object that isn't a string (or a subtype of string) into the objectArray.

In conclusion, while the Java language offers powerful features, be mindful: what compiles doesn't always run smoothly, much like a day without coffee! ☕️