Use sealed classes for better domain representation

Lets start with the business logic.

We have a task. A task can be unassigned OR it can be assigned either to a user OR a group.

First implementation: the ugly way

One way to implement this is by putting all the logic in the task:

class UglyTask(
  val name: String,
  val assignedUser: User? = null,
  val assignedGroup: Group? = null
) {
  init {
  if (assignedUser != null && assignedGroup != null) {
  throw IllegalArgumentException("a task can be assigned to either a user OR a group.")
  }
  }
}
view raw uglytask.kt hosted with ❤ by GitHub

By default the task is unassigned and if we want an assigned task we provide a user or a group. The or factor is being enforced by a check in the constructor.

This implementation not only relies on nulls to represent the business logic but it also hides the logic from the developer who has to read the code to understand how to create an assigned task.

The null checking comes also up when we want to figure out if and where a task is assigned which is tedious and can easily lead to bugs. As an example lets consider a simple function that prints the task’s assignment state:

fun UglyTask.printAssignment() {
when {
assignedGroup == null && assignedUser == null > println("\"$name\" is assigned to no one")
assignedGroup != null > println("\"$name\" is assigned to to group: ${assignedGroup.name}")
assignedUser != null > println("\"$name\" is assigned to to user: ${assignedUser.name}")
}
}

Finally two points that we should not neglect are readability and scalability. When using UglyTask if we want our code to be readable, in all cases, we have to pass the arguments by their names (thank you Kotlin 🙂 ):

val le0nidas = User("le0nidas")
val kotlinEnthusiasts = Group("kotlin enthusiasts")
UglyTask("buy milk").printAssignment()
UglyTask("write post", assignedUser = le0nidas).printAssignment()
// here we pass the parameter by name to avoid the usage of null
// which makes it less readable
UglyTask("write kotlin", assignedGroup = kotlinEnthusiasts).printAssignment()
UglyTask("write kotlin", null, kotlinEnthusiasts).printAssignment()
view raw uglytask_usage.kt hosted with ❤ by GitHub

As far as scalability, consider how many changes we need to do to add a new assigned entity. One to the constructor, one to the init function to enforce our business logic and one in every function that we use the task’s state (see: printAssignment()) which adds even more null checks.

Second implementation: The less ugly way

Another way is by having multiple constructors, each for every valid assignment:

class LessUglyTask private constructor(
val name: String,
val assignedUser: User?,
val assignedGroup: Group?
) {
constructor(name: String) : this(name, null, null) // assigned to no one
constructor(name: String, assignedUser: User) : this(name, assignedUser, null) // assigned to a user
constructor(name: String, assignedGroup: Group) : this(name, null, assignedGroup) // assigned to a group
}
view raw lessunglytask.kt hosted with ❤ by GitHub

This implementation also puts all the logic in the task but it removes those null checks and makes it easier for the developer to understand it:

With that said, all other drawbacks in readability and scalability remain the same:

fun LessUglyTask.printAssignment() {
when {
assignedGroup == null && assignedUser == null > println("\"$name\" is assigned to no one")
assignedGroup != null > println("\"$name\" is assigned to to group: ${assignedGroup.name}")
assignedUser != null > println("\"$name\" is assigned to to user: ${assignedUser.name}")
}
}
val le0nidas = User("le0nidas")
val kotlinEnthusiasts = Group("kotlin enthusiasts")
LessUglyTask("buy milk").printAssignment()
LessUglyTask("write post", assignedUser = le0nidas).printAssignment()
LessUglyTask("write kotlin", assignedGroup = kotlinEnthusiasts).printAssignment()

Final implementation: the sealed classes way 🙂

The best way to implement the business logic is by using Kotlin’s sealed classes. This way we can represent our business logic straight into our code and also keep our code clean, readable and scalable:

sealed class AssignedTo
object AssignedToNoOne : AssignedTo()
data class AssignedToUser(val user: User) : AssignedTo()
data class AssignedToGroup(val group: Group) : AssignedTo()
class Task(val name: String, val assignedTo: AssignedTo)
view raw task.kt hosted with ❤ by GitHub

Now, printAssignment() leverages all of Kotlin’s powers, including smart cast, making it easier to the eye:

fun Task.printAssignment() {
when (assignedTo) {
is AssignedToNoOne > println("\"$name\" is assigned to no one")
is AssignedToGroup > println("\"$name\" is assigned to ${assignedTo.group.name}")
is AssignedToUser > println("\"$name\" is assigned to ${assignedTo.user.name}")
}
}

and the rest of the code does not need any extra help like named arguments:

val le0nidas = User("le0nidas")
val kotlinEnthusiasts = Group("kotlin enthusiasts")
Task("buy milk", AssignedToNoOne).printAssignment()
Task("write post", AssignedToUser(le0nidas)).printAssignment()
Task("write kotlin", AssignedToGroup(kotlinEnthusiasts)).printAssignment()
view raw task_usage.kt hosted with ❤ by GitHub

As for scalability, when we want to add a new way of assignment we just extend AssignedTo and we are good to go.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s