Dealing with Method Collisions

Why collisions occur

The Kotlin compiler creates a wrapper in the delegating class for each method that’s in the delegate. What if there’s a method in the delegating class with the same name and signature as in the delegate? Kotlin resolves this conflict in favor of the delegating class. As a consequence, you can be selective and don’t have to delegate every single method of the delegate class—let’s explore this further.

In the previous example, the Worker has a takeVacation() method and the Manager is delegating calls to that method to the Worker delegate. Although that’s the default behavior for delegation in Kotlin, it’s unlikely that any Manager would settle for that; while it makes perfect sense for a Manager to delegate work(), one would expect the takeVacation() to be executed on the instance of Manager and not be delegated.

How to deal with collisions

Kotlin requires the delegating class to implement a delegate interface, but without actually implementing each of the methods of the interface. We saw this in the Manager—it implements Worker, but didn’t provide any implementations for the work() or takeVacation() methods. For every method of the delegate interface, the Kotlin compiler creates a wrapper. But that’s true only if the delegating class doesn’t already have an implementation of a method. If the delegating class has an implementation for a method that’s in the interface, then it must be marked as override, that implementation takes precedence, and a wrapper method isn’t created.

To illustrate this behavior, let’s implement the takeVacation() method in the Manager:

// version6/project.kts
class Manager(val staff: Worker) : Worker by staff {
  override fun takeVacation() = println("of course")
}

With the override keyword, you’re making it very clear to the reader of the code that you’re implementing a method from the interface, not some arbitrary function that happens to accidentally have the same name as a method in the delegate. Seeing this, the Kotlin compiler won’t generate a wrapper for takeVacation(), but it will generate a wrapper for the work() method.

Let’s invoke the methods of the interface on an instance of this version of the Manager class.