Kotlin: should I define Function or Property?

Originally published on blog.kotlin-academy.com by Igor Wojda

Recently I realized that there is a confusion relating the usage of properties and functions. There was a good reason why Kotlin introduced the concept of properties. Question arises - when to use one over another? The simplest rule I suggest you to follow is this:

• property describes state
• function describes behaviour

Let’s take a closer look at both of them. The property represents a data structure that can describe a state of an object, for instance: Person object could have name , lastName and weight properties.

class Person (var name:String, var lastName:String, var weight:Double)

We can also have derived properties — property that is calculated on the fly eg. fullName that will be created by combining name and lastName.

class Person (var name:String, var lastName:String, var weight:Double) {
    val fullName = "$name $lastName"
}

In above example, property value is evaluated only once — during Person object creation. Sometimes this is a desirable behaviour, but in this case, when we change a value of a name or lastName properties the value stored in fullName will not be updated. Fortunately, Kotlin also gives us the ability to define a property using getter or setter. In below example value of fullName property will be evaluated on every access.

class Person (var name:String, var lastName:String, var weight:Double) {
    val fullName
        get() = "$name $lastName"
}

Function , on the other hand, is all about behaviour or action that object can perform. Our Person class could have run(), walk() and jump() methods.

class Person () {
    fun run() { /*doSth*/ }

    fun walk() { /*doSth*/ }

    fun jump() { /*doSth*/ }
}

It’s important to notice that method may (and often will) modify the state of an object indirectly as a side effect of performed action eg. each time we call jump() person weight decreases by 0.1.

class Person (var name:String, var lastName:String, var weight:Double) {
    //..

    fun jump() { 
        weight -= 0.1   
        /*doSth*/ 
    }
}

If you are still confused when to use property to function it may help you to think about them from an external client perspective. We should forget for a while about internal implementation (where a property is stored or how behaviour is implemented) and simply look at the external API (similar to adding 3rd party library to our project where we only access APIs).

person.name = "Igor"
person.weight = 79
person.jump()
person.jump()
person.jump()

There were a few good reasons why Kotlin introduces properties. One of them is property access syntax (we use height instead of getHeight/setHeight) which is more concise, another is the fact that getters and setters are closer to property declaration, unlike Java where usually we put property at the top of the class and getter/setter at the bottom. My favorite feature are property delegates that increase the ability to reuse the code. We can initialize a variable when it is needed (lazy delegate), perform some action whenever the property value is changed (observable delegate) or simply store our property in another object (Android shared preferences, map, browser session, database…) using a custom delegate.

Good thing is that Kotlin allows us to use both functions (technically methods) and properties in the interfaces.

It’s important to notice that developers coming from Java (where we didn’t have a concept of properties) tend to overuse functions. Here is a good candidate to refactor into property:

//BAD
class Person () {
    private var weight:Double = 0

    fun setWeight(weight:Double) {
        this.weight = weight
    }

    fun getWeight(): Double {
        return weight
    }
}

//GOOD
class Person (var weight:Double)

When we see a method starting with set prefix (setWeight) that has a single parameter and assigns it to private field or method starting with get that returns private field value (getWeight), we should probably define property instead.

Guidelines: How do make a decision?

Each time you want to declare the new function ask yourself two questions:

• ”Does it describe a behaviour?” — candidate for the function that describes behaviour eg. run(), walk() and jump()
• “Does it describe a state? ” — candidate for the property describes state eg. name , lastName and weight

There is also additional set of guidelines (coming from Effective Java If I remember correctly) helping us to tell if property is preferred over function:

• does not throw exception
• is cheap to calculate (or cached on the first run)
• returns the same result over multiple invocations

Above guidelines should give you pretty good idea whatever or not particular member should be function or property. In the beginning, it may be a bit unnatural to define properties (especially for Java developers), but trust me — after a while, this decision will be obvious.

To be up-to-date with great articles you can also subscribe to the newsletter.