Unraveling the Sealed Keyword

To define a sealed class, we simply employ the sealed keyword:

sealed class ProcessingStep(val startedAt: Instant, val finishedAt: Instant?)

class StartCalculation(startedAt: Instant, finishedAt: Instant?) : ProcessingStep(startedAt, finishedAt)

class LoadData(startedAt: Instant, finishedAt: Instant?) : ProcessingStep(startedAt, finishedAt)

While this principle also applies to interfaces, our focus here will be on classes. It's important to highlight that sealed classes and interfaces exhibit similar characteristics. So, what distinguishes a sealed class?

Key Characteristics:

• Sealed classes are inherently abstract; you cannot instantiate a class like ProcessingStep directly.
• All direct subclasses must exist within the same package as the parent class.
• Consequently, you cannot create new subclasses of ProcessingStep dynamically or via external libraries.

It’s worth noting that while direct subclasses of a sealed class are constrained to its package, indirect subclasses can be created anywhere.

At first glance, these limitations may seem restrictive. Why would one choose an abstract class with such constraints? The beauty of these restrictions lies in their outcome: every child of ProcessingStep is known at compile time. This feature is particularly advantageous in when expressions, allowing you to omit the else clause:

fun printStep(step: ProcessingStep) {

when (step) {

is StartCalculation -> println("Started at ${step.startedAt}.")

is LoadData -> println("Loading data since ${step.startedAt}.")

}

}

One might compare this to Enums, which also restrict the addition of new members at runtime, making all Enum values known at compile time. However, there’s a key difference: Enums are singletons, while sealed classes are not. You can create multiple instances of a sealed class, unlike the single instance of an Enum type.

Sealed Classes in Real-World Scenarios

Let’s explore how sealed classes and interfaces are applied in practical situations.

A prime example is the Result sealed class, which can represent either Success<T> or Error. Choosing this class instead of throwing exceptions is a strategic move. Essentially, it serves as a more focused alternative to the broader Either type, with outcomes clearly defined as either success or error. This allows subsequent code to handle results smoothly using a when expression.

Interestingly, Kotlin’s built-in result type is not a sealed class. Here’s a way to define it yourself:

sealed class Result<out T> {

data class Success<out T>(val data: T) : Result<T>()

data class Error(val message: String) : Result<Nothing>()

}

fun divide(a: Int, b: Int): Result<Int> {

return if (b == 0) {

Result.Error("Division by zero is not allowed")

} else {

Result.Success(a / b)

}

}

It becomes clear that sealed classes and interfaces help streamline code, particularly by eliminating the need for an else case in when expressions.

In more intricate scenarios, where multiple outcomes are possible, sealed classes provide an elegant solution. For instance, a network request might yield responses such as Success, Failure, or Pending, each accompanied by its respective data. This method not only simplifies branching logic but also enhances readability and maintainability.

Furthermore, using sealed classes in domain modeling offers a clear depiction of the domain’s finite states, ensuring that all potential states are accounted for during compile time. This leads to safer and more reliable code, especially in applications where business logic is complex and subject to change, as it provides a structured approach to accommodate these evolving requirements.

Potential Drawbacks

While sealed classes in Kotlin offer significant advantages, they also come with limited flexibility, particularly in larger projects or modular architectures. The requirement for all direct subclasses to reside within the same package can lead to a cluttered namespace, negatively impacting package organization and code clarity. Additionally, this package-level visibility enforces a rigid structure, which may conflict with preferred architectural patterns.

Misapplication, such as using sealed classes in contexts better suited for simpler constructs like enums or standard classes, can result in over-engineered solutions. This not only complicates the code but also places a heavier burden on developers regarding complexity and maintenance.

A thoughtful approach is essential to harness the benefits of sealed classes while avoiding these pitfalls.