Kotlin Class Delegates: Compose with Style
Class delegation is one of the most underrated feature of Kotlin in my opinion. Not everyone is familiar with it, or does not bother to use it due to the fact that inheritance is probably the most natural approach. Today, we will say no to inheritance and give delegation a chance. To do that, let us try to familiarize ourselves first with the delegation pattern and what does it bring to the table.
Inheritance vs. Composition
For those who are not familiar, inheritance relates two classes by an “is-a” relationship while composition is “has-a”.
They both support polymorphism but one is being preferred over the other for reasons described below.
- Inheritance breaks encapsulation - this one is best described by Joshua Bloch in his book Effective Java. Basically, some classes are not “inheritance-ready” and inheriting them requires you to look at the implementation details, which breaks the encapsulation.
- Inheritance is fragile - changes in the superclass interface will propagate to all the subclasses down the hierarchy.
- Design perspective - it is easier to think of objects as a set of components combined rather than finding their shared properties.
- Lazy - inheritance does not allow for lazy loading of super class.
I am not saying that composition has no flaws but if the ideas above will not convince you to prefer composition over inheritance, nothing will.
Delegation Pattern and Composition
Now that we have established composition and its benefits over inheritance, it’s time to see how delegation relates to composition.
Delegation in computer science is the idea of passing the responsibility to another entity. The delegation pattern is a pattern built up from this idea and uses object composition to realize it.
Let us see how delegation pattern is usually implemented.
In delegation pattern, the delegates are usually the read-only properties of the class. In this example, the Vehicle method calls are being delegated to the bicycle object.
One of the most useful application of delegation is solving the multiple inheritance problem. Consider this example.
If your class needs to inherit multiple classes, you can work around it by introducing interface as contracts and delegates.
Kotlin Class Delegates
This is where it gets interesting. Because Kotlin takes the OOP design patterns by heart, it simplified some of these patterns for us by adding native support. One of these patterns is the delegation pattern.
The only requirement to the delegation pattern is for the delegate and the class that does the delegating to use the same interface. Let’s look at how delegation is done by reusing the multiple inheritance code above.
The keyword here is by . Notice the 0 boilerplate code. Stylish right?
Delegation in Kotlin does not stop in class delegation. Property delegation is also a thing, but it will be a topic for the future. Just want to point out that such a thing exists and if you might be interested, you can go check it out.
