Sealed interfaces zijn een relatief nieuwe mogelijkheid in Kotlin (sinds versie 1.5), bedoeld om het aantal implementaties van een interface binnen één bestand te beperken. Aanvankelijk bestonden er in Kotlin sealed classes, die strikte controle over de erfelijkheidshierarchie bieden, waardoor uitputtende verwerking eenvoudiger wordt (bijvoorbeeld in when-expressies).
Probleem was dat soms een architectuur geen basisklasse nodig had, maar een interface met dezelfde beperking op het aantal implementaties. Voordat sealed interfaces beschikbaar kwamen, was de enige manier om binnen de beperkingen van de compiler te passen, het gebruik van een sealed class, wat niet altijd goed aansloot bij het domeinmodel, vooral wanneer meervoudige erfelijkheid of decompostitie van gedrag naar interfaces nodig was.
Oplossing: Sealed interfaces stellen het mogelijk om een interface te definiëren waarvan alle implementaties binnen hetzelfde bestand moeten worden gedeclareerd. Dit verhoogt de veiligheid van de code en vergemakkelijkt controle en navigatie door de hiërarchie van toestanden of gebeurtenissen.
Voorbeeldcode:
sealed interface NetworkState class Success(val data: String) : NetworkState class Error(val code: Int) : NetworkState object Loading : NetworkState
Belangrijkste kenmerken:
Kan een sealed interface buiten het bestand worden geïmplementeerd waarin het is gedeclareerd?
Nee. Net als sealed classes kunnen sealed interfaces alleen worden geïmplementeerd in hetzelfde bestand als hun eerste verklaring. Proberen een dergelijke interface buiten het bestand te implementeren, resulteert in een compilatiefout.
Kan een sealed interface van een klasse erven?
Nee, interfaces kunnen alleen van andere interfaces erven. Maar een sealed interface kan van een andere (sealed) interface erven.
Ondersteunt een sealed interface meerdere implementaties?
Ja, een klasse binnen hetzelfde bestand kan meerdere sealed interfaces implementeren of zelfs tegelijkertijd zowel een sealed interface als een sealed class erven, mits dit toegestaan is volgens de taalregels.
In een systeem voor het verwerken van netwerkevenementen gebruikt de ontwikkelaar gewone interfaces en sealed classes door elkaar, resulterend in een "rommelige" hiërarchie en duplicatie van code. when-expressies zijn gedwongen om een else-tak te bevatten.
Voordelen:
Nadelen:
In dezelfde applicatie wordt er overgeschakeld naar sealed interface NetworkEvent, waarbij alle implementaties in één bestand worden geplaatst. Nu vereisen when-expressies op NetworkEvent dat alle gevallen worden verwerkt. De code wordt leesbaarder, beter onderhoudbaar en veiliger.
Voordelen:
Nadelen: