Delegated Properties

Delegation without the mystification, part 2 — introduction to delegating properties via getValue and setValue, ReadOnlyProperty and ReadWriteProperty. A quick mention of lazy, observable, and delegating to different properties.

— — — — — — — — — — — — — — —

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

— — — — — — — — — — — — — — —

Tags: #FUNDAMENTAL CONCEPT #EXERCISE

This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.

It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.

Delegation can also help with the repetition involved when defining properties and their getters and setters.

A good example is an observable property — a property where a callback should be called whenever it is accessed. Using only the tools we have talked about so far, we would implement this something like the following:

However, we can see that defining a getter in this fashion is a pattern in its own right, and we would like to extract it, and possibly reuse it.

This is precisely what delegated properties are for:

You can see that this allows us to implement observable properties in a completely general way, which can then be applied to any property. Again, as with delegating interface implementations, the “thing” that we delegate to must be an instance of some class (in this case, we constructed it in place).

A couple of other things need to be unpacked here:

The delegate class provides the implementations for the getter (and possibly setter, see bellow) — as such, the property that is being delegated must be synthetic (no backing field). Any data persisting must happen in the delegate — in the example, we passed the initial value mutableMapOf() directly into the delegate, as opposed to assigning it.

The delegate class does not need to implement any interface, only operator getValue() for getters and operator setValue() for setters (we'll discuss operators in a future lesson):

• getValue receives the property owner as the first parameter, and the KProperty<*> instance corresponding to the property as the second one. The getValue method must return a value of the type of the delegated property.
• setValue receives the same arguments as getValue, along with a third one, which is the value being set. It returns Unit.

As mentioned in the previous point, implementing an interface is not necessary. However, as a convenience, ReadOnlyProperty and ReadWriteProperty are available as templates, so you don’t have to remember the signatures.

Here’s the same example, but for a var equivalent, where we also observe mutations and take advantage of ReadWriteProperty:

As it turns out, a similar implementation is already part of the standard library.

Any property can be delegated, not just class properties:

There’s more to be said about delegated properties, but we’ll leave that to the docs. I strongly recommend that you take a look at the standard delegates — some of them are pretty cool, especially lazy and delegating to a different property.

Exercises

Go back to Delegating Interface Implementation, jump to the Table of Contents, or continue to Delegation — Summary.