53

With Kotlin 1.5 was introduce the sealed interface. Even that I know the difference between classes and interfaces, I'm not clear what are the best practices and beneficies of using sealed interface over sealed class

Should I always use interface now even when is a simple case? Or will be a case by case?

Thanks

Obs: Didn't found similar questions, only about sealed classes

Sergio
  • 27,326
  • 8
  • 128
  • 149
Canato
  • 3,598
  • 5
  • 33
  • 57

2 Answers2

47

A major reason to choose to use a sealed class instead of interface would be if there is common property/function that you don't want to be public. All members of an interface are always public.

The restriction that members must be public can be worked around on an interface using extension functions/properties, but only if it doesn't involve storing state non-publicly.

Otherwise, sealed interfaces are more flexible because they allow a subtype to be a subclass of something else, an enum class, or a subtype of multiple sealed interface/class hierarchies.

Tenfour04
  • 83,111
  • 11
  • 94
  • 154
  • 7
    This answer is great, but if you want to read more about sealed interfaces with some code I suggest this article --> https://jorgecastillo.dev/sealed-interfaces-kotlin – João Dias Sep 08 '21 at 13:55
  • No, answer is not great. Sorry, what means all members of an interface are always public and open? You can mark them as private. – Sever Oct 25 '21 at 21:45
  • @Sever it is forbidden by the compiler to mark an interface function or property as `private`, `internal`, or `protected`, and they cannot be marked `final` at the declaration site. I realize the part about being open is misleading, so I'll remove that. – Tenfour04 Oct 25 '21 at 22:29
  • Thanks @JoãoDias for the references. the sealed interface by jorgecastillo is explains a lot! – mochadwi Dec 13 '21 at 03:07
26

I would also add that sealed interface can be chosen instead of a class to mark an object with additional characteristics and use it in the when statement. For example let's say we have some number of classes that inherited from a sealed class Device:

sealed class DeviceItem(val name: String) {
    object Camera : DeviceItem("Camera")
    object Lamp : DeviceItem("Lamp")
    // ... etc, more devices
}

And we need to use an instance of DeviceItem in when statement, but we don't want to handle all the items, only specific items:

fun onDeviceItemClicked(item: DeviceItem) {
    when (item) {
        // ....
    }
}

In this case we should either add all device items to the when statement with an empty body for devices that we don't want to handle, and the code becomes cumbersome, or use else statement to handle those device items with the empty body. But if we use else we will not be notified of the error, when a new device item is added and requires some handling, which can lead to bugs. Starting from Kotlin 1.7 it will be a compilation error if when operator is not exhaustive. So basically to handle such cases we can provide a sealed interface and handle only items, which implement it:

sealed interface ClickableItem

sealed class DeviceItem(val name: String) {
    object Camera : DeviceItem("Camera"), ClickableItem
    object Lamp : DeviceItem("Lamp")
    // ... etc, more devices
}

fun onDeviceItemClicked(item: ClickableItem) {
    when (item) {
        Camera -> { /* do something */ }
    }
}

In this case when a new device item, which implements ClickableItem interface, is added there will be a compilation error, saying that when statement should be exhaustive and we must handle it.

Sergio
  • 27,326
  • 8
  • 128
  • 149