Typealias — co to jest, składnia i zastosowanie w Kotlin

Co to jest typealias?

Typealias (alias typu) — to deklaracja wprowadzająca alternatywną nazwę dla istniejącego typu. Składnia: typealias NowaNazwa = IstniejącyTyp. Po deklaracji NowaNazwa może być używana wszędzie tam, gdzie oczekiwany jest IstniejącyTyp — kompilator traktuje je jako jeden i ten sam typ. Na poziomie kodu bajtowego typealias nie pozostawia śladów: wszystkie informacje o aliasie są usuwane na etapie kompilacji.

Głównym celem typealias jest poprawa czytelności kodu. Zamiast wielosłownej sygnatury fun process(callback: (Result) -> Unit) można napisać typealias Callback = (Result) -> Unit i używać Callback jako typu parametru. Jest to szczególnie przydatne, gdy ten sam typ funkcyjny powtarza się w wielu miejscach kodu: alias służy jako pojedynczy punkt definicji i dokumentuje przeznaczenie typu.

Typealias nie tworzy nowego typu — to tylko synonim. Zmienne typu Callback i (Result) -> Unit są w pełni wymienne. Kompilator nie zgłosi błędu, jeśli do funkcji oczekującej Callback zostanie przekazana lambda bezpośrednio. To odróżnia typealias od inline class (value class), która tworzy nowy typ-opakowujący z kontrolą na etapie kompilacji. Typealias to zmiana nazwy, a nie opakowanie.

Typealias dla typów funkcyjnych

Najczęstszym scenariuszem użycia typealias w Kotlin są typy funkcyjne. Długie sygnatury takie jak (Int, String) -> Boolean czy (List) -> Result utrudniają czytanie kodu. Typealias zamienia je w krótkie znaczące nazwy, które dokumentują przeznaczenie funkcji: typealias Validator = (String) -> Boolean określa, że jest to walidator ciągu znaków.

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

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

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

// Usage in class
typealias OnClickListener = (View) -> Unit

class Button {
    var onClick: OnClickListener = {}
}

W przykładzie typealias UserFilter ukrywa złożony typ funkcyjny (List) -> List za krótką nazwą. Sygnatura findUsers staje się czytelna: «przyjmuje UserFilter, zwraca List». Typealias OnClickListener sprawia, że kod przypomina deklarację interfejsu, ale bez narzutu na tworzenie osobnego interfejsu lub klasy abstrakcyjnej. Lambdy i funkcje anonimowe działają jak zwykle — typealias nie wymaga zmian w kodzie wywołującym.

Typealias z generykami

Typealias obsługuje parametry uogólnione (generyki), co czyni go jeszcze bardziej elastycznym. Można zdefiniować typealias Mapper = (T) -> R i używać z dowolnymi typami. Kompilator podstawia konkretne typy w miejsce parametrów przy każdym użyciu aliasu, zachowując pełne bezpieczeństwo typów.

// Generic 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 type is (Int) -> String
}

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

W listingu Mapper — to uogólniony alias dla dowolnego przekształcenia z T na R. Provider — dostawca wartości (fabryka bez argumentów). ListTransformer — funkcja przekształcająca listę. Przy wywołaniu processNumbers(mapper: Mapper) kompilator rozwija alias do (Int) -> String. Generyki czynią typealias uniwersalnym narzędziem, odpowiednim dla każdego kontekstu bez powielania deklaracji.

Typealias dla klas zagnieżdżonych i długich nazw

Klasy zagnieżdżone i długie sparametryzowane typy — to kolejny obszar, w którym typealias znacząco upraszcza kod. Jeśli klasa znajduje się głęboko w hierarchii zagnieżdżenia (Outer.Inner.Nested), odwołanie do niej przez pełną nazwę zaśmieca kod. Typealias skraca taki dostęp i czyni go bardziej czytelnym. Jest to szczególnie istotne w przypadku klas z bibliotek zewnętrznych o długich nazwach.

// Alias for nested class
class NetworkResponse {
    class Error(val code: Int, val message: String)
}
typealias NetworkError = NetworkResponse.Error

// Alias for long library type
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
}

W przykładzie NetworkError — to alias dla zagnieżdżonej klasy NetworkResponse.Error. Przy imporcie typealias można używać NetworkError jako zwykłego typu, nie ujawniając hierarchii zagnieżdżenia. JsonMap dokumentuje, że mapa reprezentuje obiekt JSON. UserId wyjaśnia przeznaczenie Long w konkretnym kontekście — czytelnik od razu rozumie, że to identyfikator użytkownika, a nie dowolna liczba. Typealias nie chroni jednak przed przekazaniem zwykłego Long tam, gdzie oczekiwane jest UserId — do tego potrzebny jest value class.

Typealias vs inline class: różnice

Typealias i inline class (value class) rozwiązują różne zadania, choć oba wprowadzają nową nazwę dla typu. Typealias to tylko synonim: zmienna typu UserId = Long przyjmuje dowolny Long bez kontroli. Inline class opakowuje wartość w nowy typ, który jest sprawdzany na etapie kompilacji: przekazanie zwykłego Long tam, gdzie oczekiwany jest inline class UserId, jest niemożliwe bez jawnej konwersji.

Tabela pokazuje różnicę między tymi dwoma mechanizmami. Typealias nadaje się do krótkich nazw i dokumentacji kodu, gdy nie jest wymagana ścisła typizacja. Inline class przez słowo kluczowe value class (wcześniej inline class) jest potrzebny, gdy ważne jest rozróżnianie semantycznie różnych wartości tego samego typu prymitywnego. Na przykład UserId i OrderId oba są Long, ale przekazanie jednego tam, gdzie oczekiwany jest drugi, to błąd logiczny, który value class zapobiega na etapie kompilacji.