Risposta.

Le interfacce sealed sono una possibilità relativamente nuova in Kotlin (dalla versione 1.5), destinata a limitare il numero di implementazioni di un'interfaccia all'interno di un singolo file. Inizialmente, in Kotlin esistevano le classi sealed, che garantivano un controllo rigoroso sulla gerarchia di ereditarietà, facilitando il trattamento esaustivo (ad esempio, all'interno di espressioni when).

Problema: si presentava il caso in cui l'architettura richiedesse non una classe base, ma un'interfaccia con la stessa limitazione sul numero di implementazioni. Prima dell'introduzione delle interfacce sealed, l'unico modo per rientrare nei vincoli del compilatore era utilizzare una sealed class, che non sempre si adattava bene al modello di dominio, specialmente quando si necessitava di ereditarietà multipla o decomposizione del comportamento in interfacce.

Soluzione: Le interfacce sealed consentono di definire un'interfaccia, tutte le implementazioni della quale devono essere dichiarate all'interno di un unico file. Ciò aumenta la sicurezza del codice e facilita il controllo e la navigazione nella gerarchia di stati o eventi.

Esempio di codice:

sealed interface NetworkState

class Success(val data: String) : NetworkState
class Error(val code: Int) : NetworkState
object Loading : NetworkState

Caratteristiche principali:

Le interfacce sealed possono essere implementate solo all'interno dello stesso file;
Le interfacce sealed non memorizzano stati, ma le loro implementazioni possono essere classi con stati o oggetti;
Trattamento esaustivo delle espressioni when per l'interfaccia sealed.

Domande insidiose.

È possibile implementare un'interfaccia sealed al di fuori del file in cui è dichiarata?

No. Come per le classi sealed, le interfacce sealed possono essere implementate solo nello stesso file in cui sono dichiarate. Tentare di implementare tale interfaccia al di fuori del file porterà a un errore di compilazione.

È possibile ereditare un'interfaccia sealed da una classe?

No, le interfacce possono ereditare solo da altre interfacce. Ma un'interfaccia sealed può ereditare da un'altra interfaccia (sealed).

Le interfacce sealed supportano l'implementazione multipla?

Sì, una classe all'interno di questo stesso file può implementare più interfacce sealed o persino ereditare contemporaneamente un'interfaccia sealed e una sealed class, se ciò è consentito dalle regole del linguaggio.

Errori comuni e anti-pattern

Implementazione di un'interfaccia sealed al di fuori del file con la sua dichiarazione (il compilatore non lo permetterà).
Abuso delle interfacce sealed per una maggiore rigorosità, che può portare a una complessità eccessiva nell'architettura.
Tentativo di creare istanze di un'interfaccia sealed direttamente: impossibile, solo implementazioni/oggetti concreti.

Esempio della vita reale

Caso negativo

Nel sistema di elaborazione degli eventi di rete, uno sviluppatore utilizza interfacce normali e classi sealed mescolate, risultando in una gerarchia "sporca" e nella duplicazione del codice. Le espressioni when sono costrette a contenere un ramo else.

Pro:

Architettura rapidamente implementabile
Flessibilità nell'implementazione

Contro:

Espansione incontrollata della gerarchia
Le espressioni when non vengono controllate dal compilatore per completezza

Caso positivo

Nella stessa applicazione si passa all'interfaccia sealed NetworkEvent, ponendo tutte le implementazioni in un unico file. Ora le espressioni when su NetworkEvent richiedono la gestione di tutti i casi. Il codice diventa più leggibile, manutenibile e sicuro.