Tag: type

Sealed Classes in Kotlin – An Explanation

Sealed Classes in Kotlin – An Explanation

Sealed Classes in Kotlin – An Explanation

Today I came across Sealed Classes in Kotlin, which I had never heard of before. After some research I found that this concept is nothing new and is also available in Scala for example. So, yet another Scala feature JetBrains considered relevant and suitable for Kotlin? I like that 🙂 Read this post if you’re interested in more Kotlin features.

Actually this is a quite simple feature, which I’m going to explain in the following.

Feature Explanation

A sealed class can be subclassed and may include abstract methods which means sealed classes are abstract implicitly, although the documentation doesn’t clearly say so. To actually make a class “sealed” we have to put the sealed modifier before its name, as we can see here:

sealed class MyClass

Restriction

The important thing about sealed classes is that its subclasses must be declared in the same file as the sealed class itself.

Benefit

The feature allows us to define class hierarchies that are restricted in its’ types, i.e. subclasses. Since all subclasses need to be defined inside the file of the sealed class, there’s no chance of unknown subclasses which the compiler doesn’t know about.

Wait… Isn’t this what an enum actually is?

Kotlin’s sealed classes are some kind of extension of plain enums: As opposed to enums, subclasses of sealed classes can be instantiated multiple types and can actually contain state.

Use Case

The main advantage of sealed classes reveals itself if it’s used in when expressions. Let’s compare a normal class hierarchy to one of a sealed class handled in a when. First, we’ll create a hierarchy of Mammals and then put it in a method with a when:

open class Mammal(val name: String)
class Cat(val catName: String) : Mammal(catName)
class Human(val humanName: String, val job: String) : Mammal(humanName)
fun greetMammal(mammal: Mammal): String {
    when (mammal) {
        is Human -> return "Hello ${mammal.name}; You're working as a ${mammal.job}"
        is Cat -> return "Hello ${mammal.name}"
        else -> return "Hello unknown"
    }
}

The else is mandatory, otherwise the compiler will complain. This is because it just cannot verify that all possible cases, i.e. subclasses, are covered here. It may be possible that a subclass Dog is available at any time which is unknown at compile time.

Sealed “to the rescue”

But what if we knew there wouldn’t be other Mammals in our application? We’d want to leave out that else.

The problem of unknown subclasses can be avoided by sealed classes. Let’s modify the base class Mammal, its’ subclasses can remain the same.

sealed class Mammal(val name: String)

Now we can simply omit the else clause since the compiler can verify that all possible cases are covered because only the subclasses in the file of the sealed class exist, without exception. The method now looks as follows:

fun greetMammal(mammal: Mammal): String {
    when (mammal) {
        is Human -> return "Hello ${mammal.name}; You're working as a ${mammal.job}"
        is Cat -> return "Hello ${mammal.name}"
        // `else` clause not required, all the cases covered 
    }
}

That’s it. In conclusion really simple and handy, isn’t it? Have fun trying it yourself!

I’m going to create an example in KotlinByExample for this topic as soon as possible.

Finally, if you want to read about sealed classes in more detail I recommend the book Kotlin in Action to you!

Simon


 

Please follow and like me 🙂

Enjoy this blog? Please spread the word :)