Antwort

Hintergrund

Kotlin zielt auf Typsicherheit ab und vermeidet Null-Zeiger, häufig besteht jedoch die Notwendigkeit, Variablen verzögert (late) zu initialisieren, zum Beispiel bei der Verwendung von Dependency Injection oder in einer Android Activity. Dafür wurde der Modifikator lateinit hinzugefügt.

Problem

Übliche Eigenschaften erfordern eine obligatorische Initialisierung oder müssen nullable sein, was unbequem ist, wenn eine verzögerte, aber obligatorische Initialisierung garantiert wird. Die Verwendung eines nullable-Typs kompliziert den Code und erfordert zusätzliche Null-Prüfungen.

Lösung

lateinit ermöglicht es, eine bis zu einem gewissen Zeitpunkt nicht initialisierte Eigenschaft zu erstellen, verspricht jedoch dem Compiler, dass sie vor der ersten Verwendung initialisiert wird. Die Initialisierung kann nicht im Konstruktor, sondern später erfolgen.

class UserViewModel {
    lateinit var repository: UserRepository

    fun onCreate() {
        repository = UserRepository()
    }

    fun getData() = repository.load()
}

Wichtige Merkmale:

Ermöglicht die Vermeidung von null und gleichzeitig die Verzögerung der Initialisierung
throw UninitializedPropertyAccessException beim Zugriff auf eine nicht initialisierte lateinit-Eigenschaft
Nur für var und nicht für primitive Typen (Int, Double usw.)

Fallen

Kann man lateinit für val-Eigenschaften verwenden?

Nein. lateinit funktioniert nur mit var, da val einmal sofort initialisiert werden muss, entweder direkt oder über einen Getter.

Funktioniert lateinit mit den Typen Int, Boolean, Double und anderen Primitiven?

Nein. Nur mit Objektverweisen. Für primitive Typen verwenden Sie nullable-Typen.

Was passiert, wenn man auf eine lateinit-Eigenschaft vor der Initialisierung zugreift?

Kotlin wirft UninitializedPropertyAccessException:

lateinit var foo: String
println(foo) // Ausnahme

Typische Fehler und Anti-Patterns

Vergessen, die lateinit-Eigenschaft zu initialisieren – die Anwendung wird abstürzen
Verwendung dort, wo nullable Semantik mit isInitialized Prüfung erforderlich ist
Anwendung für primitive Typen und val

Beispiel aus dem Leben

Negativer Fall

Der Entwickler hat lateinit var item: String deklariert, aber nicht bis zum ersten Aufruf der Methode getItem initialisiert. Ergebnis: Anwendung stürzt ab.

Vorteile:

Befreit von nullable, wenn alles korrekt initialisiert ist

Nachteile:

Risiko, den Lebenszyklus zu verwechseln und eine Laufzeit-Ausnahme zu erhalten

Positiver Fall

Android Activity: lateinit var presenter, Initialisierung in onCreate. Die Verwendung von presenter in allen Lebenszyklusmethoden ist sicher: Nullability ist nicht erforderlich.