Was ist eine "sealed class" in Kotlin und wie erleichtert sie die Verarbeitung von Zuständen? Wie sind sealed classes mit dem when-Ausdruck verbunden und warum ist das wichtig für die Typensicherheit? Geben Sie ein Beispiel für die Verwendung.

Antwort

Eine sealed class in Kotlin ist eine abstrakte Klasse, die die Vererbungshierarchie einschränkt: Alle Untertypen müssen in derselben Datei deklariert werden. Dies ist nützlich für Hierarchien, in denen die Menge der Optionen festgelegt ist (zum Beispiel zur Beschreibung von Zuständen, Ereignissen oder Fehlern):

sealed class Result {
    object Success : Result()
    data class Error(val message: String) : Result()
    object Loading : Result()
}

fun handle(result: Result) = when (result) {
    is Result.Success -> print("Success!")
    is Result.Error -> println("Error: ${result.message}")
    is Result.Loading -> println("Loading...")
}

Verbindung zu when: Wenn wir alle Untertypen der sealed class im when-Ausdruck verwenden, überprüft der Compiler die Exhaustiveness (Erschöpfung der Varianten). Dies garantiert, dass beim Hinzufügen eines neuen Zustands der Entwickler einen Kompilierfehler erhält, wenn er die neue Option nicht behandelt.

Warum ist das wichtig:

• Erleichtert die Unterstützung der Typensicherheit.
• Unabhängigkeit von Runtime-Prüfungen, die Verarbeitung erfolgt zur Kompilierzeit.
• Zwingt dazu, alle Varianten der Hierarchie explizit zu berücksichtigen.

---

Fangfrage

"Kann man die Nachkommen einer sealed class in verschiedenen Dateien oder Paketen platzieren? Wie beeinflusst das die Typensicherheit?"

Antwort: Nein, alle direkten Nachkommen einer sealed class müssen in derselben Datei definiert sein. Dies ist eine Kontrolle des Compilers zur Gewährleistung der Typensicherheit. Wenn Nachkommen in anderen Dateien eines Pakets platziert werden, erhält der Compiler einen Fehler.

---

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas

---

Geschichte

Bei der Planung der Geschäftslogik für Zahlungen wurden Optionen für die Ergebnisse von Aktionen hinzugefügt, ohne das when-Ausdruck zu aktualisieren. Aber dank der sealed class hat der Compiler nicht berücksichtigte Fälle hervorgehoben. In einem anderen Projekt in Java hätte dieses Szenario dazu geführt, dass ein nicht initialisierter Status in das Produkt gelangt.

---

Geschichte

In einem Projekt, nach der Migration von Teilen der Daten von sealed classes zu normalen open classes, hörten die erschöpfenden when-Prüfungen auf zu funktionieren — neue Status begannen, in der Logik der Verarbeitung "verloren" zu gehen, was zu einem fehlerhaften Verhalten der Benutzeroberfläche führte.

---

Geschichte

In einem E-Commerce-System gab es den Versuch, die Architektur durch das Auslagern der Nachkommen von sealed classes in separate Dateien (jede in ihr eigenes Modul zur Wiederverwendung) zu optimieren. Dies brach die Kompilierung und führte zu einer dringenden Umstrukturierung vor der Veröffentlichung.