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}")
	}
	}

view raw uglytask_printAssignment.kt hosted with ❤ by GitHub

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()

view raw lessuglytask_printAssignment.kt hosted with ❤ by GitHub

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}")
	}
	}

view raw task_printAssignment.kt hosted with ❤ by GitHub

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.