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:
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:
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 🙂 ):
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:
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:
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:
Now, printAssignment() leverages all of Kotlin’s powers, including smart cast, making it easier to the eye:
and the rest of the code does not need any extra help like named arguments:
As for scalability, when we want to add a new way of assignment we just extend AssignedTo and we are good to go.
