Che cos'è una "sealed class" in Kotlin e come semplificano la gestione degli stati? Come sono collegate le sealed class all'espressione when e perché è importante per la type-safety? Fornisci un esempio di utilizzo.

Risposta

sealed class in Kotlin è una classe astratta che limita l'ereditarietà dei sottotipi: tutti i sottotipi devono essere dichiarati in un unico file. Questo è utile per gerarchie in cui il numero di varianti è fisso (ad esempio, per descrivere stati, eventi o errori):

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...")
}

Collegamento con when: Se utilizziamo tutti i sottotipi della sealed class nell'espressione when, il compilatore verifica l'exhaustiveness (analisi esaustiva delle varianti). Questo garantisce che, se viene aggiunto un nuovo stato, lo sviluppatore riceverà un errore di compilazione se non gestisce la nuova variante.

Perché è importante:

• Semplifica il supporto alla type-safety.
• Indipendenza dai controlli runtime, la gestione avviene in fase di compilazione.
• Costringe a considerare esplicitamente tutte le varianti della gerarchia.

---

Domanda trabocchetto

"È possibile posizionare i sottotipi di una sealed class in file o pacchetti diversi? Come influisce sulla type-safety?"

Risposta: No, tutti i sottotipi diretti della sealed class devono essere definiti in un unico file. Questo è un controllo del compilatore per garantire la type-safety. Se i sottotipi vengono posizionati in altri file del pacchetto, il compilatore genererà un errore.

---

Esempi di errori reali dovuti alla mancanza di conoscenza delle sottigliezze dell'argomento

---

Storia

Durante la progettazione della logica di business dei pagamenti, sono stati aggiunti varianti di risultati dell'operazione, dimenticando di aggiornare l'espressione when. Ma grazie alla sealed class, il compilatore ha evidenziato i casi non considerati. In un altro progetto in Java, questo scenario avrebbe portato all'inserimento di uno stato non inizializzato nel prodotto.

---

Storia

In un progetto, dopo la migrazione di parte dei dati da sealed class a normali open class, le verifiche when esaustive hanno smesso di funzionare: i nuovi stati hanno iniziato a "perdersi" nella logica di gestione, causando comportamenti errati nell'interfaccia.

---

Storia

In un sistema e-commerce, c'è stata un tentativo di ottimizzare l'architettura estraendo i sottotipi delle sealed class in file separati (ognuno in un proprio modulo per il riutilizzo). Questo ha rotto la compilazione ed è stata la causa di una rifattorizzazione urgente prima del rilascio.