I am learning Kotlin right now. For context, I am a Java developer for +10 years.
I stumbled upon the concept of backing properties. As I understand it, the problem to be solved is this: I have a property in a class. I want this property to be mutable and visible only in the containing class, so I declare it as private var. The property should only be modified in the containing class, but it should be readable outside the class. So, the Kotlin docs propose something like this:
private var _word = "test"
val word: String
get() = _word
This works and fulfills the above requirements, but this looks a bit odd, for a Java developer. In Java, we only need 1 field (there is no such thing as a property in Java):
private String word = "test";
public String getWord() {
return word;
}
AFAIK, same result.
Today I learned that in Kotlin, I simply can make a setter private. So what about this Kotlin code:
var word = "test"
private set
All requirements fulfilled, much more concise code.
Im I missing something? Why do I need a backing property?
You're right, there's no reason to do this:
private var _word = "test"
val word: String
get() = _word
Because you can just do this:
var word = "test"
private set
Just like in Java with a private field and a getter method, you can choose later to change getter logic without breaking external code. In Java you could choose to do something more complicated than use a single private backing field. Maybe calculate something involving multiple backing fields, etc. In Kotlin, you can come back later and change it to use other backing properties later if it gets more complicated, and change only the getter implementation.
The most common reason I've seen to use a backing property is so you can return a less specific type in your public property:
private val _myList: MutableList<String> = mutableListOf()
val myList: List<String> get() = _myList
This code helps prevent outside classes from mutating the returned list.
The Kotlin designers have mentioned in presentations that they plan to add a new syntax in the future that will eliminate the need for a backing property in this use case. Something like this:
// Not valid syntax yet in Kotlin 1.6
private val myList: MutableList<String> = mutableListOf()
public get: List<String>
Another reason to have a backing property is simply when there isn't a one-to-one correspondence between what you're returning and how it is stored or generated. For example:
private val myRandom = Random(1234)
val aNumber: Int get() = myRandom.nextInt(100)
One other use for backing properties is to allow you to store a null value internally, but expose a non-null type, and provide some fallback value (which you might not want to store, if null has a specific meaning).
Here's the example from the docs:
private var _table: Map<String, Int>? = null
public val table: Map<String, Int>
get() {
if (_table == null) {
_table = HashMap() // Type parameters are inferred
}
return _table ?: throw AssertionError("Set to null by another thread")
}
What's happening here is your typical singleton getInstance()-style accessor, where if the object isn't instantiated yet, you create and store it before returning it. Unlike a lazy delegate, it's internally a var meaning it can be replaced with a new Map, or null in this example (with some handler code anticipating a potential concurrency issue)
The caller sees none of this though - outwardly it's just a plain val that returns a non-null Map, accessed like any other property, with no need to handle a potential null. All that nullability is abstracted away, it's an internal detail.
You'd have to do the same thing in Java (let's say if you wanted to use the @NonNull annotation on your getter), creating an internal variable and wrangling its state. It's just that in Kotlin, you get a basic backing field "for free" (if you even need one) and it's only if that isn't adequately needs-suiting that you need to start creating and poking at properties yourself