Type Aliases in Kotlin

Type Aliases sind ein kleines Kotlin-Werkzeug mit großer Wirkung auf die Lesbarkeit. Du gibst einem vorhandenen Typ einen neuen Namen, damit eine lange oder schwer lesbare Signatur verständlicher wird. Gerade in Android-Code mit Compose, Repository-Callbacks, Result-Typen oder Event-Handlern triffst du oft auf Function Types und verschachtelte generische Typen. Ein guter Alias kann dort zeigen, was ein Typ fachlich bedeutet. Ein schlechter Alias versteckt dagegen nur Details und macht den Code unklarer.

Was ist das?

Ein Type Alias ist ein alternativer Name für einen bestehenden Typ. Du definierst ihn mit typealias. Danach kannst du den neuen Namen überall dort verwenden, wo der ursprüngliche Typ erlaubt ist. Wichtig ist das mentale Modell: Ein Type Alias erzeugt keinen neuen Typ. Er ist nur ein anderer Name für denselben Typ.

Das unterscheidet ihn zum Beispiel von einer eigenen Klasse, einer data class oder einem value class-Typ. Wenn du typealias UserId = String schreibst, bleibt UserId technisch ein String. Der Compiler schützt dich also nicht davor, versehentlich irgendeinen anderen String zu übergeben. Der Alias macht nur deine Absicht im Quellcode sichtbarer.

In Android-Projekten geht es bei Type Aliases meist nicht darum, primitive Typen hübscher zu benennen. Der nützlichere Fall sind komplexe Typen: Function Types, generische Rückgabewerte, Listener-Signaturen oder Mapper-Funktionen. Kotlin wird in der Android-Entwicklung breit eingesetzt, weil die Sprache knappe Syntax, Null-Safety, Lambdas, Coroutines und moderne API-Patterns gut unterstützt. Genau dadurch entstehen aber auch Typen, die für Lernende und für Teammitglieder schwer zu scannen sind.

Ein Beispiel ist ein Callback wie (Throwable?) -> Unit. Noch deutlicher wird es bei Signaturen wie (List<Article>, Boolean, Throwable?) -> Unit. Du kannst sie technisch lesen, aber du musst bei jedem Vorkommen neu überlegen: Was ist die Liste? Wofür steht der Boolean? Wann ist der Fehler gesetzt? Ein Alias wie ArticleLoadCallback kann diese Absicht benennen, wenn die Signatur wirklich an mehreren Stellen gebraucht wird.

Die Grundidee lautet also: Du benennst nicht die technische Form, sondern die fachliche Rolle. Der Alias soll dem Leser erklären, warum dieser Typ hier existiert.

Wie funktioniert es?

Ein Type Alias steht auf Top-Level-Ebene oder innerhalb geeigneter Kotlin-Strukturen, je nach Projektstil und Sichtbarkeit. Häufig legst du ihn in die Datei, in der der Typ fachlich hingehört. Für einen Compose-Screen kann das die Screen-Datei sein. Für gemeinsame Architekturtypen kann es eine Datei im jeweiligen Feature- oder Core-Modul sein.

Die Syntax ist kurz:

typealias ArticleClickHandler = (articleId: String) -> Unit

Danach kannst du ArticleClickHandler als Parametertyp verwenden:

fun ArticleList(
    articles: List<Article>,
    onArticleClick: ArticleClickHandler
) {
    // ...
}

Bei Function Types kann Kotlin Parameternamen im Typ notieren. Diese Namen verbessern die Lesbarkeit in der IDE und in Dokumentation, sind aber nicht Teil einer strengen Laufzeitlogik. Der Alias bleibt kompatibel mit jeder Funktion, die dieselbe Form hat. Eine Lambda-Funktion vom Typ (String) -> Unit kann also weiterhin als ArticleClickHandler übergeben werden.

Das ist praktisch, aber auch die zentrale Grenze. Wenn du zwei Aliases hast, die beide auf String oder auf dieselbe Lambda-Signatur zeigen, unterscheidet Kotlin sie nicht als eigene Typen:

typealias UserId = String
typealias ArticleId = String

UserId und ArticleId sind für den Compiler beide String. Wenn du echte Typsicherheit brauchst, ist ein Type Alias nicht das passende Werkzeug. Dann solltest du über eine kleine Wrapper-Klasse oder eine @JvmInline value class nachdenken. Ein Alias verbessert die Lesbarkeit, aber er erzwingt keine fachliche Trennung.

In modernem Android-Code tauchen Aliases oft an drei Stellen auf.

Erstens bei Compose-Callbacks. Compose-Komponenten erhalten viele Event-Parameter: onClick, onDismiss, onQueryChange, onRetry. Kleine Lambdas wie () -> Unit brauchen keinen Alias. Sobald aber mehrere Parameter oder fachliche Bedeutungen ins Spiel kommen, kann ein Alias helfen. Ein Name wie SearchQueryChanged oder ArticleSelected kann schneller verständlich sein als (String) -> Unit, sofern der Kontext nicht ohnehin eindeutig ist.

Zweitens bei Architekturgrenzen. In ViewModels, Use Cases oder Repository-Schichten können Funktionen mit Result, Flow, Map und Domain-Modellen schnell lang werden. Ein Alias kann eine wiederkehrende technische Signatur bündeln, zum Beispiel für Mapper oder Validatoren. Dabei solltest du vorsichtig bleiben: Wenn ein Alias nur eine komplizierte Architektur versteckt, verbessert er den Code nicht. Er verschiebt die Unklarheit nur an eine andere Stelle.

Drittens bei Tests. Test-Code enthält oft Hilfsfunktionen, Fake-Callbacks oder Factory-Signaturen. Ein Alias kann dort die Absicht einer Testhilfe klären. Gleichzeitig ist Test-Code ein guter Ort, um zu prüfen, ob ein Alias wirklich verständlich ist. Wenn du im Test trotz Alias noch ständig nachschauen musst, was der Typ bedeutet, ist der Name wahrscheinlich zu abstrakt.

Eine hilfreiche Regel: Verwende einen Type Alias, wenn eine Typ-Signatur fachlich wichtig, wiederholt und ohne Namen schwer lesbar ist. Verwende ihn nicht, nur um jeden Typ zu verkürzen.

In der Praxis

Stell dir einen Compose-Screen vor, der Artikel anzeigt. Die Liste soll auf Klicks reagieren, ein Lesezeichen umschalten und Ladefehler melden. Ohne Aliases kann die Funktionssignatur schnell technisch aussehen:

@Composable
fun ArticleListScreen(
    articles: List<Article>,
    onArticleClick: (String) -> Unit,
    onBookmarkToggle: (String, Boolean) -> Unit,
    onLoadFailed: (Throwable) -> Unit
) {
    // UI-Inhalt
}

Das ist nicht falsch. Für ein kleines Beispiel ist es sogar akzeptabel. In einem echten Feature wächst der Screen aber weiter: Preview-Parameter, UI-State, Pull-to-refresh, Analytics oder Navigation kommen dazu. Dann helfen klare Namen, die Signatur schneller zu erfassen.

Mit Type Aliases könnte der Code so aussehen:

typealias ArticleSelected = (articleId: String) -> Unit
typealias BookmarkChanged = (articleId: String, isBookmarked: Boolean) -> Unit
typealias ArticleLoadFailed = (error: Throwable) -> Unit

@Composable
fun ArticleListScreen(
    articles: List<Article>,
    onArticleClick: ArticleSelected,
    onBookmarkToggle: BookmarkChanged,
    onLoadFailed: ArticleLoadFailed
) {
    // UI-Inhalt
}

Der Vorteil liegt nicht darin, dass der Code kürzer ist. Der Vorteil liegt darin, dass die Parameter jetzt fachlicher lesbar sind. BookmarkChanged sagt mehr als (String, Boolean) -> Unit, weil der Boolean jetzt eine Bedeutung bekommt: isBookmarked.

Noch klarer wird es, wenn du denselben Typ an mehreren Stellen brauchst:

class ArticleViewModel(
    private val trackSelection: ArticleSelected
) : ViewModel() {

    fun openArticle(articleId: String) {
        trackSelection(articleId)
    }
}

Ob das in einem ViewModel sinnvoll ist, hängt vom echten Architekturkontext ab. Das Beispiel zeigt aber die Mechanik: Der Alias macht eine wiederkehrende Funktion benennbar.

Entscheidungsregel

Nutze einen Alias, wenn du beim Lesen einer Signatur innerlich übersetzen musst: „Was bedeutet dieser Boolean?“, „Was macht diese Lambda-Funktion fachlich?“, „Warum steht hier diese lange generische Struktur?“ Wenn der Alias diese Frage direkt beantwortet, ist er wahrscheinlich nützlich.

Nutze keinen Alias, wenn der ursprüngliche Typ bereits klar ist. typealias Title = String bringt meist wenig. String ist leicht zu lesen, und der Alias kann eine Typsicherheit andeuten, die nicht existiert. Wenn du eine Artikel-ID von einem Benutzer-Namen unterscheiden musst, reicht ein Alias nicht. Dann brauchst du einen echten Modelltyp:

@JvmInline
value class ArticleId(val value: String)

Das ist eine andere Entscheidung als ein Type Alias. Ein ArticleId als Value Class ist ein eigener Typ. Der Compiler kann dich dadurch besser schützen. Ein Alias kann das nicht.

Typische Stolperfalle

Die häufigste Stolperfalle ist zu viel Abstraktion. Ein Team legt Aliases an wie SuccessHandler, ErrorHandler, DataCallback, UiAction, ResultMapper und StateTransformer, ohne dass klar ist, welches Feature oder welche Fachbedeutung dahintersteht. Dann musst du ständig zur Definition springen. Der Alias hat die Signatur nicht erklärt, sondern versteckt.

Achte deshalb auf konkrete Namen. LoginResultHandler ist besser als ResultHandler, wenn der Typ nur im Login-Kontext verwendet wird. ArticleSelected ist besser als ClickCallback, wenn es fachlich um die Auswahl eines Artikels geht. Benenne nach Bedeutung, nicht nach Technik.

Eine zweite Stolperfalle betrifft öffentliche APIs innerhalb eines Projekts. Wenn du in einem Core-Modul einen Alias veröffentlichst, kann er sich über viele Features ausbreiten. Eine spätere Änderung ist dann nicht mehr lokal. Frage dich daher vor einem gemeinsamen Alias: Wird dieser Typ wirklich projektweit stabil gebraucht, oder gehört er in ein einzelnes Feature?

Übung für dein Projekt

Nimm eine Compose-Komponente oder eine ViewModel-Funktion aus deinem aktuellen Übungsprojekt. Suche nach einer Signatur mit mindestens einem Function Type, der zwei oder mehr Parameter hat. Schreibe daneben probeweise einen Type Alias. Lies danach die ursprüngliche und die neue Variante laut oder im Code-Review-Stil: Welche Version erklärt schneller, was passiert?

Prüfe außerdem mit Tests oder Previews, ob du nur die Benennung geändert hast. Da ein Type Alias kein neuer Typ ist, sollte sich das Verhalten nicht ändern. Wenn sich doch etwas ändern muss, war dein Problem wahrscheinlich nicht Lesbarkeit, sondern Modellierung. Dann ist eine eigene Klasse oder Value Class der bessere nächste Schritt.

Fazit

Type Aliases sind sinnvoll, wenn sie komplexe Kotlin-Typen in Android-Code fachlich benennen: besonders bei Function Types, Callbacks und wiederkehrenden generischen Signaturen. Verwende sie sparsam und prüfe immer, ob der Alias mehr erklärt, als er versteckt. Deine praktische Aufgabe: Nimm eine lange Callback-Signatur, benenne sie mit einem konkreten Alias, lies den Code im Review-Kontext und entscheide danach ehrlich, ob der neue Name die Absicht schneller sichtbar macht.