Restricting Class Hierarchies in Kotlin

Kotlin is a statically typed, general-purpose programming language developed by JetBrains, that has built world-class IDEs like IntelliJ IDEA, PhpStorm, Appcode, etc. It was first introduced by JetBrains in 2011 and is a new language for the JVM. Kotlin is an object-oriented language, and a “better language” than Java, but still be fully interoperable with Java code. In this article, we will learn how to restrict the class hierarchies in Kotlin. Before we move ahead, you should know some basic concepts of OOPs and familiarity with class and properties of classes like inheritances.

So, When we are sure that a value or a class can have only a limited set of types or number of subclasses, that’s when we try to restrict class hierarchy. Yes, this might sound like an enum class but, actually, it’s much more than that. Enum constant exists only as a single instance, whereas a subclass of a sealed class can have multiple instances that can contain a state. Let’s look at an example in the mentioned steps.

Step by Step Implementation

Step 1. We will create a sealed class named ToastOperation. Under the same source file, we will define a ShowMessageToast subclass:

class ShowMessageToast(val message:String):ToastOperation()

Step 2. Also, we’ll define a ShowErrorToast object:

object ShowErrorToast:ToastOperation()

Step 3. As you may have noted, we have defined an object rather than a full class declaration, because the howErrorToast object doesn’t have any state. Also, by doing so, we have removed it from the when block, since there is just one instance. Now, we can use it in a when statement, as follows:

Kotlin

fun doToastOperation (toastOperation: ToastOperation) {
  when (toastOperation) {
    is ShowMessageToast
         ->Toast.makeText(this, toastOperation.message, Toast.LENGTH_LONG).show()
    ShowErrorToast->Toast . makeText (this, "Error...Grr!",Toast.LENGTH_LONG).show()
  }
}

Step 4. The key benefit is that we don’t need to implement the else block, which acted as the default block when the other statements didn’t fit the bill. According to documentation, a sealed class can have subclasses, but all of them must be declared in the same file as the sealed class itself. However, the subclasses of subclasses need not be defined in the same file. It is abstract by itself, and you cannot instantiate objects from it. Here’s our structure of sealed classes:

sealed class ToastOperation {

}
object ShowErrorToast:ToastOperation()
class ShowMessageToast (val message:String):ToastOperation()

As you can see, we’ve kept all the subclasses under the same source file in which we have defined the sealed class. In the preceding example, we were sure that we can only have two types of toasts: an error toast and a toast with a custom message. So we created a sealed class ToastOperation and created two subclasses of ToastOperation. Note that if we aren’t sure of types of subclasses, we will not use a sealed class, in that case, an enum class might be better suited.

If you are using Kotlin versions prior to 1.1, you’ll need to implement the subclasses inside the sealed class, much like this:

sealed class ToastOperation {
    object ShowErrorToast:ToastOperation()
    class ShowMessageToast(val message:String):ToastOperation()
}

Note: You can use the preceding way in the new version of Kotlin as well.