Risposta

Storia della questione

Nelle prime versioni di Kotlin, per limitare la gerarchia dei tipi venivano utilizzate classi sealed, che permettevano agli sviluppatori di controllare esplicitamente i sotto-tipi consentiti limitando la dichiarazione degli eredi a un singolo file. Per alcune esigenze, questo non era sufficiente, specialmente quando era necessario descrivere gerarchie simili utilizzando interfacce. Per risolvere questo problema, a partire da Kotlin 1.5 è stato introdotto il modificatore sealed per le interfacce.

Problema

Le interfacce normali consentono di implementarli ovunque nel progetto, il che spesso impedisce di garantire la totale chiusura della gerarchia dei tipi e di utilizzare controlli di tipo esaustivi (exhaustive when). Ciò può portare a errori di runtime, impossibilità di controllare staticamente tutte le varianti.

Soluzione

Le interfacce sealed consentono di limitare l'elenco delle classi di implementazione all'interno di un singolo file, aumentando la prevedibilità del sistema dei tipi e la sicurezza del pattern matching.

sealed interface NetworkResult
class Success(val data: String): NetworkResult
class Failure(val error: Throwable): NetworkResult

fun handle(result: NetworkResult) = when(result) {
    is Success -> println("Data: ${result.data}")
    is Failure -> println("Error: ${result.error}")
    // Tutte le varianti sono considerate, 'else' non è necessario
}

Caratteristiche chiave:

Le interfacce sealed consentono una singola gerarchia: solo classi/oggetti dello stesso file possono estendere
Le interfacce sealed possono essere implementate sia da classi che da oggetti
Espandono la sicurezza di tipo dell'espressione when senza necessità di prevedere esplicitamente else

Domande insidiose.

È possibile aggiungere un'interfaccia sealed in un file separato o implementarla al di fuori del file originale?

No. Tutti i tipi che implementano direttamente un'interfaccia sealed devono essere dichiarati nello stesso file, altrimenti il compilatore restituirà un errore.

È consentito a un'interfaccia sealed avere sott'interfacce al di fuori del file di dichiarazione?

No. Anche le sott'interfacce devono trovarsi nello stesso file. L'intera gerarchia è chiusa all'interno del file.

Le interfacce sealed influenzano le prestazioni a runtime?

No, direttamente, ma consentono di utilizzare controlli di tipo sicuri in fase di compilazione, riducendo la probabilità di errori a runtime, semplificando il codice e potenzialmente accelerando i test.

Errori tipici e antipattern

Dichiarazione di classi di implementazione dell'interfaccia sealed al di fuori del file in cui è dichiarata l'interfaccia stessa
Aggiunta di troppe varianti, complicando la manutenzione
Utilizzo di interfaccia sealed quando la gerarchia delle varianti può cambiare (non è richiesta la chiusura delle varianti)

Esempio della vita reale

Caso negativo

Uno sviluppatore dichiara l'interfaccia sealed NetworkAction in un file, ma le implementazioni sono sparse in diverse classi e file. Il problema viene scoperto tardi: il compilatore segnala una violazione della regola, ed è difficile correggere la struttura, specialmente in un grande progetto.

Vantaggi:

Consente di dichiarare nuove implementazioni senza modificare un file

Svantaggi:

Viola le garanzie di sicurezza dei tipi
Richiede di effettuare refactoring del codice, che è costoso in termini di tempo

Caso positivo

L'interfaccia sealed OrderResult e le classi Success/Failure sono dichiarate all'interno di un unico file. Il controllo when è sempre esaustivo, nessun ramo viene omesso.