DEV Community

Cover image for #TeachingKotlin Part 2 - Variables
Harsh Shandilya
Harsh Shandilya

Posted on • Edited on • Originally published at msfjarvis.dev

4

#TeachingKotlin Part 2 - Variables

Even the variables in Kotlin are supercharged!

Let's start with a simple data class and see how the variables in there behave.

data class Student(val name: String, val age: Int, val subjects: ArrayList<String>)
Enter fullscreen mode Exit fullscreen mode

To use the variables in this class, Kotlin let's you directly use the dot notation for accessing.


>>> val s1 = Student("Keith Hernandez", 21, arrayListOf("Mathematics", "Social Studies"))
>>> println(s1.name)

Keith Hernandez

>>> println(s1) // data classes automatically generate `toString` and `hashCode` 

Student(name=Keith Hernandez, age=21, subjects=[Mathematics, Social Studies])
Enter fullscreen mode Exit fullscreen mode

For Java callers, Kotlin also generates getters and setter methods.

final Student s1 = new Student("Keith Hernandez", 21, arrayListOf("Mathematics", "Social Studies"));
System.out.println(s1.getName());
System.out.println(s1);
Enter fullscreen mode Exit fullscreen mode

The same properties apply to variables in non-data classes as well.


>>> class Item(id: Int, name: String) {
...     val itemId = id
...     val itemName = name
... }
>>> val item = Item(0, "Bricks")
>>> println(item.itemId)
0
>>> println(item)
Line_4$Item@46fb460a
>>>
Enter fullscreen mode Exit fullscreen mode

As you can notice, the toString implementation is not identical to our data classes but that's a topic for another post. Back to variables!

Customising getters and setters

While Kotlin creates getters and setters automatically, we can customize their behaviour.

class Item(id: Int, name: String) {
    var itemId = id
    var itemName = name
    var currentState: Pair<Int, String> = Pair(itemId, itemName)
        set(value) {
            itemId = value.first
            itemName = value.second
            field = value
        }
    override fun toString() : String {
        return "id=$itemId,name=$itemName"
    }
}
Enter fullscreen mode Exit fullscreen mode

Let's take this for a spin in the Kotlin REPL and see how our currentState field behaves.

>>> val item = Item(0, "Nails")
>>> println(item)
id=0,name=Nails
>>> item.currentState = Pair(1, "Bricks")
>>> println(item)
id=1,name=Bricks
Enter fullscreen mode Exit fullscreen mode

Notice how setting a new value to currentState mutates the other variables as well? That's because of our custom setter. These setters are identical to a normal top-level function except a reference to the field in question is available as the variable field for manipulation.

Visiblity modifiers

Kotlin's visiblity modifiers aren't very well explained. There's the standard public, private and protected, but also the new inner and internal. I'll attempt to fill in those gaps.

inner

inner is a modifier that only applies to classes declared within another one. It allows you to access members of the enclosing class. A sample might help explain this better.

class Outer {
    private val bar: Int = 1
    inner class Inner {
        fun foo() = bar
    }
}

val demo = Outer().Inner().foo() // == 1
Enter fullscreen mode Exit fullscreen mode

The keyword this does not behave as some would normally expect in inner classes, go through the Kotlin documentation for this here and I'll be happy to answer any further questions :)

internal

internal applies to methods and properties in classes. It makes the field/method 'module-local', allowing it to be accessed within the same module and nowhere else. A module in this context is a logical compilation unit, like a Gradle subproject.

That's all for today! Hope you're liking the series so far. I'd love to hear feedback on what you want me to cover next and how to improve what I write :)

Top comments (0)

Great read:

Is it Time to go Back to the Monolith?

History repeats itself. Everything old is new again and I’ve been around long enough to see ideas discarded, rediscovered and return triumphantly to overtake the fad. In recent years SQL has made a tremendous comeback from the dead. We love relational databases all over again. I think the Monolith will have its space odyssey moment again. Microservices and serverless are trends pushed by the cloud vendors, designed to sell us more cloud computing resources.

Microservices make very little sense financially for most use cases. Yes, they can ramp down. But when they scale up, they pay the costs in dividends. The increased observability costs alone line the pockets of the “big cloud” vendors.