1. Introduction
We often use enum in projects to define data types. It helps us to define different types for the same parent type. Also in Kotlin can be used sealed class.
Then sealed class it is useful for anything other than enum class.
What is sealed class, after all? Let’s go find out together.
We understand the concept of sealed classes by understanding the difference between it and enum classes for a common case. Let’s see the example below: Result is an enum class of two types, namely Success and Error.
1 2 3 4 5 | enum class Result(val data: String) { SUCCESS("Success"), ERROR("Error") } |
Enum is very useful. But they have limitations. For example, each subtype of enum can only be a constant variable and it has no state. That is, Type ERROR is being hard-coded with the value of Error string, when we do a real application, it has a lot of error cases. This we can’t do at Enum. Also, we cannot have other types of subclasses. What will be found in the sealed class Now that it is not verbose anymore, together we go into detail about the sealed class superiority through an example.
2. Why sealed class is superior to enum
Sealed classes give us the flexibility to contain many different types of subclasses and contain their states.
The important point to note here is that subclasses extending Sealed classes must be nested classes of Sealed class or must be declared in the same file as sealed class.
The type of enum is constants and so it is very difficult to maintain different states of the object.
The example of the Enum Result class is above. We are only storing the string value for the enum. But if in the case of an error. We want to show an Exception that causes an error. Then that is not possible with enum because it cannot hold a state of type.
1 2 3 4 5 | enum class Result(val data: String) { SUCCESS("Success"), ERROR(val exception: Exception) // not possible } |
Subclasses inherit from a sealed class include classes that are common, data classes or sealed classes and can easily contain the state of the subclass.
Let’s see an example: First, declare a sealed Employee class, by adding the sealed keyword before the class.
sealed class Employee
Employees of an IT company will include: Director, manager, developer … Specifically: Manager (Name, age, list of reporting employees) SeniorDev (Name, age, projects)
We proceed to create:
1 2 3 4 | sealed class Employee data class Manager(val name: String, val age: Int, val team: List<String>): Employee() class SeniorDev(val name: String, val age: Int, val projects: Int): Employee() |
This is not possible if we use enum.
3. Compare sealed class with abstract class
The sealed classes themselves are abstract and cannot be directly instantiated. Here we will ask the question: If the sealed class is abstract by default, why can’t we use an abstract class instead of a sealed class in the first place?
The benefit here is that an abstract class can have their derived classes anywhere in the project, while a sealed class must contain all classes that inherit it in the same file.
To explain this more clearly, if we try to define a SeniorDev class that inherits from Employee in another file, we will get a compile-time error. This is because the sealed class has a limit on inheritance amount. Instead of that limitation sealed class allows us to declare subclasses of different types. Here, subclasses can be data classes, ordinary classes, objects (Singleton in Kotlin) or the sealed classes themselves. To make it easier to imagine, let’s see the example below.
1 2 3 4 5 | sealed class Employee data class Manager(val name: String, val age: Int, val team: List<String>): Employee() class SeniorDev(val name: String, val age: Int, val projects: Int): Employee() object JuniorDev: Employee() |
Abstraction is difficult to manage. But once used sealed class will help us manage that in a very convenient way.
1 2 3 4 5 6 7 8 | val employee: Employee = SeniorDev(“Name”, 20, 10) val message = when (employee) { is Manager -> {“section manager"} is SeniorDev -> {“senior"} Junior -> {“junior"} } |
Usually when used with when we will catch the remaining cases with the else keyword, but if the object is an expression of sealed class then it is not necessary.
Assuming we use abstract in this case, the IDE will ask us to declare the keyword else. Because the abstract class allows the definition of subclasses in other project files. So the IDE cannot control it all. It is a limitation of abstract class compared to sealed class.
Go back to the example of the original Result that is often used similarly in projects. We are now rewriting them as sealed class as follows:
1 2 3 4 5 | sealed class Result { data class Success(val data: Data): Result() data class Error(val exceptiom: Exception) : Result() } |
We have 2 data classes:
- Success with data value.
- Error contains the states of the error.
Sealed classes help us write clearer, more concise code, and in some cases reduce the abstraction.
Refer:
Source mindorks : https://link.sun-asterisk.vn/3ddPoi
Kotlin : https://kotlinlang.org/docs/reference/sealed-classes.html