Extension Functions in Kotlin – bestehende Klassen erweitern, ohne sie zu ändern
Mit Extension Functions hängst du eigene Methoden an fremde Klassen wie String oder View – ganz ohne Vererbung. Ich zeige dir, wie das geht, wo es glänzt und welche Grenze du kennen solltest.
Manchmal fehlt einer Klasse genau die eine Methode, die du dauernd brauchst. Vererben geht nicht (die Klasse gehört dir nicht), also landet die Logik in irgendeiner Utils-Datei. Kotlin macht es eleganter: Extension Functions.
Eine eigene Methode an String hängen
fun String.toSlug(): String =
trim().lowercase()
.replace(Regex("[^a-z0-9]+"), "-")
.trim('-')
// Aufruf wie eine echte Methode:
val slug = "Mein Erster Beitrag!".toSlug() // "mein-erster-beitrag"Der Teil vor dem Punkt (String) ist der Empfängertyp. Im Rumpf ist this die Instanz – bei Strings kannst du this sogar weglassen und direkt trim() schreiben.
Besonders praktisch in Android
fun View.visibleIf(condition: Boolean) {
visibility = if (condition) View.VISIBLE else View.GONE
}
fun Context.toast(msg: String) =
Toast.makeText(this, msg, Toast.LENGTH_SHORT).show()
// später:
errorText.visibleIf(state.hasError)
toast("Gespeichert")So liest sich der Aufruf-Code wie natürliche Sprache – und die Wiederholung verschwindet an eine Stelle.
Die eine Grenze, die du kennen musst
Extensions werden statisch aufgelöst, nicht polymorph. Sie können außerdem nicht auf private-Felder der Klasse zugreifen – nur auf das, was von außen sichtbar ist. Sie sind also syntaktischer Zucker, kein echter Eingriff in die Klasse. Für kleine Helfer ist das genau richtig; echte Zustandslogik gehört weiter in die Klasse selbst.
Kleine, gut benannte Extensions halten meinen App-Code aufgeräumt. Weitere Kotlin-Snippets gibt's auf code.bymw.de.
Quellen
Du brauchst mehr als ein Snippet?
Ich entwickle Android-Apps in Kotlin und moderne Websites für Selbstständige und kleine Unternehmen — von der ersten Idee bis zum Release.
Projekt anfragen →Verwandte Snippets
Room-Migrationen – das Schema ändern, ohne Nutzerdaten zu verlieren
Eine neue Spalte in der Entity, und beim nächsten Start ist der Spielstand weg – weil fallbackToDestructiveMigration die Datenbank einfach löscht. So machst du es richtig, inklusive Test.
stateIn und shareIn – aus einem kalten Flow wird geteilter Zustand
Jeder Sammler eines kalten Flows startet die Arbeit neu – zwei Beobachter, zwei Datenbankabfragen. stateIn und shareIn machen daraus einen Strom, den sich alle teilen, samt aktuellem Wert und Abschalten bei Inaktivität.
viewModelScope – Coroutinen, die mit dem Bildschirm verschwinden
Eine Coroutine, die nach dem Schließen des Bildschirms weiterläuft, schreibt in ein ViewModel, das niemand mehr sieht – und hält im schlimmsten Fall die ganze Activity im Speicher. viewModelScope beendet sie automatisch.