3 min read
·
By Henrik Gundersen
·
December 5, 2019
Sealed classes in Kotlin are a concept close to enums that we are used to from other languages. While enums are used to represent a set of values — sealed classes are used for representing restricted class hierarchies. This means that each type have to be within a limited set of values and can have several instances containing state. This gives us the possibility to make more expressive data models.
To declare a sealed class — put the sealed
modifier in front of the class name. Note that a sealed class can have subclasses, but all of them must be declared in the same file as the sealed class itself.
To illustrate this, let's look into a simple example. In this example we are doing a payment with different payment methods:
sealed class PaymentMethod() {
data class CreditCard(val token: String, val expireDate: String) : PaymentMethod()
data class DirectPayment(val phoneNumber: String) : PaymentMethod()
}
Each of these payment methods have different requirements for input data. When handling a CreditCard
payment we need a token
and expireDate
. A DirectPayment
however only requires a phoneNumber
.
As we can see here, each of the values have to extend the sealed class PaymentMethod
. Every type defined inside PaymentMethod
, might have their own state, extend state from PaymentMethod
or they can even be an object
with no state at all.
when
expressionThe real power of sealed classes can be seen using the when
expression. As described earlier, there is a restricted set of possible types when defining sealed classes. This restriction makes it possible for the compiler to warn you if you are not handling all possible outcomes in the when
expression.
In the following example we are trying to process a payment:
data class Payment(amount: Int, paymentMethod: PaymentMethod)
// Does not compile :(
fun processPayment(payment: Payment) =
when (payment.paymentMethod) {
is PaymentMethod.CreditCard -> processCreditCardPayment(payment.amount, paymentMethod.token, paymentMethod.expireDated)
}
This code will not compile. Can you see what's missing in the processPayment
function?🤔
As you probably could see, we didn't handle all possible outcomes of PaymentMethod
. Let's add the missing type DirectPayment
to the processPayment
method:
data class Payment(amount: Int, paymentMethod: PaymentMethod)
// Compiles :)
fun processPayment(payment: Payment) =
when (payment.paymentMethod) {
is PaymentMethod.CreditCard ->
processCreditCardPayment(payment.amount, paymentMethod.token, paymentMethod.expireDated)
is PaymentMethod.DirectPayment ->
processDirectPayment(payment.amount, paymentMethod.phoneNumber)
}
The above code will now compile since all possible values of PaymentMethod
is handled inside the when
expression.
Another important benefit we get from using when
expressions, is smartcast
. When the paymentMethod
matches one of the is
statements - we can use the object directly without the need for explicit casting.
Sealed classes gives us a new tool for creating cleaner and better data models. By utilizing sealed classes with the when
expression, the compiler will also help us to handle all possible values. Even though this sometimes might feel cumbersome, it will definitely make the code more solid and more maintainable.
Loading…