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")
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:
classLessUglyTask private constructor(
valname:String,
valassignedUser:User?,
valassignedGroup: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
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:
One thought on “Use sealed classes for better domain representation”