Czym jest "sealed class" w Kotlinie i jak ułatwiają one obsługę stanów? Jak sealed class są powiązane z wyrażeniem when i dlaczego to jest ważne dla type-safety? Podaj przykład zastosowania.

Odpowiedź

sealed class w Kotlinie to klasa abstrakcyjna, która ogranicza hierarchię dziedziczenia: wszystkie podtypy muszą być zadeklarowane w tym samym pliku. To jest wygodne dla hierarchii, w których zestaw opcji jest stały (na przykład do opisu stanów, zdarzeń lub błędów):

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("Sukces!")
    is Result.Error -> println("Błąd: ${result.message}")
    is Result.Loading -> println("Ładowanie...")
}

Związek z when: Jeśli używamy wszystkich podtypów sealed class w wyrażeniu when, kompilator sprawdza exhaustiveness (wyczerpujące rozpatrzenie opcji). Gwarantuje to, że przy dodawaniu nowego stanu deweloper otrzyma błąd kompilacji, jeśli nie obsłuży nowej opcji.

Po co to potrzebne:

• Ułatwia utrzymanie type-safety.
• Niezależność od kontroli czasu działania, przetwarzanie odbywa się na etapie kompilacji.
• Zmusi do rozważenia wszystkich opcji hierarchii.

---

Pytanie z podstępem

"Czy można umieszczać dziedziczących po sealed class w różnych plikach lub pakietach? Jak to wpływa na type-safety?"

Odpowiedź: Nie, wszyscy bezpośredni dziedziczący po sealed class muszą być zdefiniowani w tym samym pliku. To kontrola kompilatora dla zapewnienia type-safety. Jeśli dziedziczących umieści się w innych plikach pakietu, kompilator zgłosi błąd.

---

Przykłady rzeczywistych błędów z powodu nieznajomości niuansów tematu

---

Historia

Podczas projektowania logiki biznesowej płatności dodano opcje wyników operacji, zapominając zaktualizować wyrażenie when. Ale dzięki sealed class, kompilator podświetlił nieuwzględnione przypadki. W innym projekcie w Javie ten scenariusz doprowadziłby do wystąpienia niezinicjowanego statusu w produkcie.

---

Historia

W projekcie po migracji części danych z sealed class na zwykłe open class przestały działać exhaustywne kontrole when — nowe statusy zaczęły "ginąć" w logice przetwarzania, co powodowało nieprawidłowe zachowanie interfejsu.

---

Historia

W systemie e-commerce podjęto próbę optymalizacji architektury przez przeniesienie dziedziczących po sealed class do oddzielnych plików (każdy — w swoim module do ponownego wykorzystania). To uszkodziło kompilację i stało się przyczyną pilnego refaktoryzowania przed wydaniem.