sealed class e interface in Kotlin — cosa sono, sintassi e applicazione

Cosa sono sealed class e sealed interface?

sealed class è una classe astratta con una restrizione: tutte le sue sottoclassi dirette devono essere dichiarate nello stesso file della classe sealed stessa. Questa restrizione rende la gerarchia chiusa (sealed) — nessun codice al di fuori del file può aggiungere una nuova sottoclasse.

sealed interface, aggiunta in Kotlin 1.5, fornisce la stessa garanzia ma con la flessibilità di un'interfaccia: una sealed interface può essere implementata da più classi, oggetti o altre interfacce in un file. A differenza di sealed class, sealed interface non ha restrizione di ereditarietà singola — una classe può implementare più interfacce sealed contemporaneamente.

Secondo Kotlin Evolution and Roadmap (2026), sealed interface è stata aggiunta su richiesta della comunità per una modellazione più flessibile. La motivazione principale è la capacità di combinare gerarchie di tipi indipendenti senza ereditarietà multipla di classi.

Sintassi di sealed class

La dichiarazione di una sealed class inizia con il modificatore sealed prima di class. Le sottoclassi vengono dichiarate nello stesso file.

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

Ogni sottoclasse di una sealed class può avere le proprie proprietà e metodi. Loading è un singleton (object), Success e Error sono data class con parametri. Il compilatore conosce tutte e tre le varianti e verifica la loro completezza quando utilizzate in when.

Sealed class annidate

Le classi sealed possono essere annidate, creando gerarchie multilivello per modelli di dati complessi senza perdere la type safety.

sealed class UiState {
    object Idle : UiState()
    object Loading : UiState()
    data class Content(val items: List<Item>) : UiState()
    data class Error(val exception: Throwable) : UiState()
}

Sintassi di sealed interface (Kotlin 1.5+)

sealed interface viene dichiarata in modo simile a sealed class, ma permette di implementare più interfacce sealed in una singola classe.

sealed interface Action
sealed interface Loggable

data class Navigate(val route: String) : Action, Loggable
data class ShowToast(val text: String) : Action
object GoBack : Action, Loggable

La classe Navigate implementa due interfacce sealed contemporaneamente — Action e Loggable. Ciò è impossibile con sealed class a causa della restrizione di ereditarietà singola. sealed interface fornisce la flessibilità di combinare gerarchie indipendenti.

Quando scegliere sealed interface invece di sealed class

sealed interface è preferibile quando la gerarchia non richiede stato condiviso o costruttore. Secondo le JetBrains Kotlin Guidelines (2026), sealed interface dovrebbe essere usata per impostazione predefinita per tutte le nuove gerarchie dove non è necessario un costruttore comune, rendendo il codice più flessibile per estensioni future.

Gestione esaustiva in when

Il principale vantaggio dei tipi sealed è la gestione esaustiva nell'espressione when. Il compilatore verifica che tutte le possibili sottoclassi siano coperte.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else non è richiesto — il compilatore sa che tutte le varianti sono coperte
}

Se uno sviluppatore aggiunge una nuova sottoclasse a una gerarchia sealed ma dimentica di gestirla in when — il compilatore genererà un errore. Questa è sicurezza a livello di tipi, non disponibile con gerarchie aperte che usano il ramo else.

Secondo Google Android Developers (2026), le classi sealed sono il modo raccomandato per modellare lo stato dell'UI in Jetpack Compose. La verifica esaustiva di when previene stati in cui lo sviluppatore non ha gestito tutte le possibili varianti di visualizzazione di una schermata.

Confronto sealed class con enum class

enum class e sealed class sono spesso confuse, ma hanno scopi e capacità diversi.

La scelta tra sealed class e enum class dipende dal compito. Se le varianti non portano dati aggiuntivi — usa enum. Se ogni variante contiene campi unici — usa sealed class o sealed interface.

Scenari pratici di utilizzo

I tipi sealed vengono utilizzati nei progetti Kotlin per una serie di scenari standard in cui è necessaria una modellazione type-safe.

Stato dell'UI in Jetpack Compose

Ogni schermata Compose può avere una sealed class UiState che descrive tutti gli stati possibili: Idle, Loading, Content(data), Error(exception). L'espressione when garantisce che tutti gli stati siano gestiti.

Risultati di richieste di rete

NetworkResult con le varianti Success, Error, Loading è un pattern standard nei progetti Kotlin con Retrofit e Ktor. sealed class garantisce una gestione sicura di ogni risultato di richiesta.

Navigazione in progetti multi-modulo

sealed interface per le rotte di navigazione permette ai moduli di dichiarare le proprie rotte rimanendo all'interno di una gerarchia unificata. Ciò elimina errori con rotte sconosciute in fase di compilazione.

Secondo KotlinConf (2025), sealed class e sealed interface sono il fondamento del design type-safe nelle applicazioni Kotlin moderne. Si combinano con data class per modellare strutture di dominio complesse senza perdere la sicurezza in fase di compilazione.