Antwoord.

Achtergrond: Kotlin is oorspronkelijk ontworpen als een taal met een beknopte, maar strikt getypeerde syntax. Om de leesbaarheid te bevorderen en duplicatie van code te verminderen, is een krachtige type inference geïmplementeerd.

Probleem: Soms wordt het declareren van een type overbodig, wat de code ingewikkeld maakt. Maar overmatige afkorting van types leidt tot problemen bij het lezen en verspreiding van fouten als de compiler het type niet kan afleiden.

Oplossing: Type inference maakt het mogelijk voor de compiler om de meeste types automatisch te bepalen op basis van initialisatie of context. Maar strikte typisatie blijft de correctheid van de code controleren.

Codevoorbeeld:

val name = "Kotlin" // String, type automatisch afgeleid
var count = 5         // Int, type automatisch afgeleid
val items = listOf(1, 2, 3) // List<Int>

// Expliciete type-aanduiding is vereist als afleiden niet mogelijk is
val callback: (Int) -> Unit = { println(it) }

Belangrijkste kenmerken:

Het type van een variabele of expressie kan worden afgeleid uit initialisatie of de context van een functieaanroep
Het is niet altijd mogelijk om een type af te leiden: de compiler vereist een expliciete verklaring als de expressie dubbelzinnig is
Type inference is niet van toepassing op de retourtypes van openbare functies en eigenschappen: de compiler vereist expliciete aanduiding voor stabiliteit van de ABI

Trick vragen.

Is het mogelijk om het retourtype van een openbare functie niet aan te geven?

Nee, als de functie openbaar is, vereist de compiler een expliciete verklaring van het retourtype voor de stabiliteit van de interfaces en de ondersteuning van Java-interoperabiliteit.

Voorbeeld:

// Fout!
public fun compute(x: Int) = x * 2 // Vereist expliciet: public fun compute(x: Int): Int = x * 2

Welk type heeft val x = null?

De compiler kan het type niet afleiden, omdat null geen type heeft zonder context. Het type moet expliciet worden gedeclareerd:

val x: String? = null

Kan type inference werken voor complexe generieke types bij chain-verwerking van collecties?

Ja, maar als het type niet eenduidig kan worden afgeleid (bijvoorbeeld, map verandert types), kan het soms nodig zijn om het type van de variabele expliciet op te geven:

val values = listOf("1", "2").map { it.toInt() } // List<Int>, type wordt afgeleid

Typische fouten en anti-patronen

Ontbreken van een expliciet type in openbare API-functies
Overbelasting van code met impliciete types, wat lezen bemoeilijkt
Fout bij het proberen een type af te leiden bij initialisatie met null

Voorbeeld uit het leven

Negatieve geval

In het project worden alle variabelen zonder type-aanduiding gedeclareerd, wat het navigeren en begrijpen van de code voor andere ontwikkelaars of nieuwe medewerkers bemoeilijkt.

Voordelen:

Minder code
Sneller schrijven en refactoren

Nadelen:

Moeilijk te lezen en onderhouden
Gemakkelijk een fout te maken bij het wijzigen van de initialisatie

Positieve geval

Binnen functies worden de types van variabelen automatisch afgeleid, maar in alle openbare API’s wordt altijd het retourtype en de types van parameters expliciet aangegeven.