Antwort.

Historie der Frage:

Interfaces mit dem Modifier sealed wurden in Kotlin als Weiterentwicklung des Konzepts der sealed class eingeführt. Bis Kotlin 1.5 erlaubten nur sealed-Klassen die Begrenzung der möglichen Nachfahren, was besonders wichtig für die sichere Arbeit mit Zustandshierarchien (state machines, DSL usw.) ist. Mit der Einführung von sealed Interfaces haben die Entwickler die Möglichkeit geschaffen, auch die Implementierungen von Interfaces ähnlich zu begrenzen, ohne sich an Klassen zu binden.

Problem:

Ein einfaches offenes Interface kann überall im Programm implementiert werden, was zu einem unkontrollierbaren Wachstum der Anzahl der Implementierungen und zu einer Erschwerung der Wartung des Codes führen kann. Bei der Verarbeitung durch einen when-Ausdruck kann der Compiler nicht auf nicht behandelte Zweige hinweisen.

Lösung:

Das sealed interface beschränkt die Implementierungen nur auf diejenigen, die in einem Modul definiert sind (oder in derselben Datei, wenn das Interface nicht top-level ist). Diese Kontrollmethode wird für sichere enum-ähnliche Strukturen, das ADT-Muster und Zustandsbehandler angewendet. Der Compiler kennt alle Implementierungen und hilft bei der Codeanalyse.

Beispielcode:

sealed interface NetworkResult

class Success(val data: String): NetworkResult
class Error(val cause: Throwable): NetworkResult
object Loading: NetworkResult

fun handleResult(result: NetworkResult): String = when (result) {
    is Success -> "Erfolg mit ${result.data}"
    is Error -> "Fehler: ${result.cause.message}"
    Loading -> "Wird geladen..."
}

Schlüsselmerkmale:

Sealed Interfaces bieten eine Begrenzung der Anzahl der Implementierungen zur Verbesserung der Typensicherheit.
Funktionieren mit dem when-Ausdruck: der Compiler prüft die Vollständigkeit.
Implementierungen können sowohl Klassen als auch Objekt-Objekte und andere sealed-Typen sein, jedoch nur innerhalb eines Moduls.

Fangfragen.

Kann ein sealed interface außerhalb der aktuellen Datei implementiert werden?

Antwort: Im Gegensatz zu sealed classes können sealed Interfaces in anderen Dateien implementiert werden, jedoch nur innerhalb des aktuellen Moduls (oder des Kompilierungseinheit, wenn das Interface nicht top-level ist).

Können sealed interfaces offene Methoden mit Standardimplementierungen haben?

Ja, wie gewöhnliche Interfaces kann ein sealed Interface Standardimplementierungen von Funktionen enthalten.

sealed interface Mode {
    fun description(): String = "Unbekannter Modus"
}

Ist es möglich, ein sealed interface mit Hilfe von Standardserialisierern (z.B. kotlinx.serialization) zu serialisieren?

Ja, es ist möglich, erfordert jedoch die explizite Angabe aller Implementierungen. Die Unterstützung von sealed Interfaces in Kotlinx.serialization kam nicht sofort, es ist wichtig, die zu serialisierenden Typen ausdrücklich anzugeben.

Typische Fehler und Anti-Muster

Definition von Implementierungen außerhalb des Moduls
Übermäßiger Einsatz von sealed Interfaces anstelle von enums, wenn die Optionen weniger und die Struktur einfacher ist
Keine Durchführung der Vollständigkeitsprüfung bei Aktualisierung des sealed interfaces

Lebensbeispiel

Negativer Fall

Im Projekt wurde ein sealed interface für alle UI-Zustandsarten beschrieben, und die Implementierungen begannen in verschiedenen Teilen der Anwendung zu erscheinen. Dann wurde ein neuer Zustandstyp hinzugefügt, aber der Verarbeitungsblock wurde vergessen zu aktualisieren, was dazu führte, dass der neue Zustand in den Logs ignoriert wurde.

Vorteile:

Schnelles Hinzufügen neuer Zustände

Nachteile:

Typensicherheit sinkt, es entstehen nicht berücksichtigte Logikzweige

Positiver Fall

Ein sealed interface wurde für alle Netzwerkantworten verwendet. Dadurch hat die IDE beim Hinzufügen eines neuen Antworttyps sofort alle Stellen hervorgehoben, an denen die Verarbeitung über when kommuniziert wird. Der Fehler wird sofort behoben, es gibt keine unerwarteten Lücken in der Logik.