Typealias — vad är det, syntax och tillämpning i Kotlin

Vad är typealias?

Typealias (typalias) — en deklaration som introducerar ett alternativt namn för en befintlig typ. Syntax: typealias NyttNamn = BefintligTyp. Efter deklarationen kan NyttNamn användas överallt där BefintligTyp förväntas — kompilatorn behandlar dem som samma typ. På bytekodnivå lämnar typealias inga spår: all information om aliaset raderas i kompileringsfasen.

Huvudmålet med typealias är att förbättra kodläsbarheten. Istället för en lång signatur fun process(callback: (Result) -> Unit) kan man skriva typealias Callback = (Result) -> Unit och använda Callback som parametertyp. Detta är särskilt användbart när samma funktionella typ upprepas på flera ställen i koden: aliaset fungerar som en enda definitionspunkt och dokumenterar typens syfte.

Typealias skapar inte en ny typ — det är bara en synonym. Variabler av typen Callback och (Result) -> Unit är helt utbytbara. Kompilatorn ger inget fel om en lambda skickas direkt till en funktion som förväntar Callback. Detta skiljer typealias från inline class (value class), som skapar en ny omslagstyp med kontroll vid kompilering. Typealias är en omdöpning, inte en omslagning.

Typealias för funktionella typer

Det vanligaste användningsscenariot för typealias i Kotlin är funktionella typer. Långa signaturer som (Int, String) -> Boolean eller (List) -> Result gör koden svårläst. Typealias omvandlar dem till korta meningsfulla namn som dokumenterar funktionens syfte: typealias Validator = (String) -> Boolean specificerar att detta är en strängvaliderare.

// Utan typealias
fun findUsers(
    filter: (List<User>) -> List<User>
): List<User>

// Med typealias
typealias UserFilter = (List<User>) -> List<User>

fun findUsers(filter: UserFilter): List<User>

// Användning i klass
typealias OnClickListener = (View) -> Unit

class Button {
    var onClick: OnClickListener = {}
}

I exemplet döljer typealias UserFilter den komplexa funktionella typen (List) -> List bakom ett kort namn. Signaturen findUsers blir läsbar: «tar emot UserFilter, returnerar List». Typealias OnClickListener gör koden lik en gränssnittsdeklaration, men utan overhead för att skapa ett separat gränssnitt eller abstrakt klass. Lambdas och anonyma funktioner fortsätter att fungera som vanligt — typealias kräver inga ändringar i anropande kod.

Typealias med generics

Typealias stöder generiska parametrar, vilket gör det ännu mer flexibelt. Man kan definiera typealias Mapper = (T) -> R och använda med vilka typer som helst. Kompilatorn ersätter konkreta typer på parametrarnas plats vid varje användning av aliaset, med bibehållen full typsäkerhet.

// Generiskt typealias
typealias Mapper<T, R> = (T) -> R
typealias Provider<T> = () -> T
typealias ListTransformer<T> = (List<T>) -> List<T>

fun processNumbers(mapper: Mapper<Int, String>) {
    // mapper-typ är (Int) -> String
}

fun main() {
    val config: Provider<String> = { "default config" }
    val reverse: ListTransformer<Int> = { it.reversed() }
}

I listningen är Mapper — ett generiskt alias för valfri transformation från T till R. Provider — värdeleverantör (fabrik utan argument). ListTransformer — funktion för att transformera en lista. Vid anropet processNumbers(mapper: Mapper) vecklar kompilatorn ut aliaset till (Int) -> String. Generics gör typealias till ett universellt verktyg som passar för alla sammanhang utan dubblerade deklarationer.

Typealias för nästlade klasser och långa namn

Nästlade klasser och långa parameteriserade typer — ett annat område där typealias avsevärt förenklar koden. Om en klass ligger djupt i nästlingshierarkin (Outer.Inner.Nested), skräpar referens till den med fullständigt namn ner koden. Typealias förkortar denna åtkomst och gör den mer läsbar. Detta är särskilt viktigt för klasser från tredjepartsbibliotek med långa namn.

// Alias för nästlad klass
class NetworkResponse {
    class Error(val code: Int, val message: String)
}
typealias NetworkError = NetworkResponse.Error

// Alias för lång bibliotekstyp
typealias UserId = Long
typealias JsonMap = Map<String, Any?>

fun process(error: NetworkError) {
    println("${error.code}: ${error.message}")
}

fun parseJson(data: JsonMap): UserId {
    return data["id"] as? Long ?: 0L
}

I exemplet är NetworkError — ett alias för den nästlade klassen NetworkResponse.Error. Vid import av typealias kan NetworkError användas som en vanlig typ, utan att avslöja nästlingshierarkin. JsonMap dokumenterar att kartan representerar ett JSON-objekt. UserId förklarar syftet med Long i det specifika sammanhanget — läsaren förstår omedelbart att detta är en användaridentifierare, inte ett godtyckligt tal. Typealias skyddar dock inte mot att skicka en vanlig Long dit UserId förväntas — för det krävs value class.

Typealias vs inline class: skillnader

Typealias och inline class (value class) löser olika uppgifter, även om båda introducerar ett nytt namn för en typ. Typealias är bara en synonym: en variabel av typen UserId = Long accepterar vilken Long som helst utan kontroll. Inline class omsluter värdet i en ny typ som kontrolleras vid kompilering: att skicka en vanlig Long dit inline class UserId förväntas är omöjligt utan explicit konvertering.

Tabellen visar skillnaden mellan de två mekanismerna. Typealias är lämpligt för korta namn och kod dokumentation när strikt typning inte krävs. Inline class via nyckelordet value class (tidigare inline class) behövs när det är viktigt att särskilja semantiskt olika värden av samma primitiva typ. Till exempel, UserId och OrderId är båda Long, men att skicka den ena dit den andra förväntas är ett logiskt fel som value class förhindrar vid kompilering.