Classes and objects

The moment loose values stop working

Here is a two-player game, written with everything you know so far:

1var name1 = "Ada"
2var score1 = 0
3var name2 = "Alan"
4var score2 = 0

It works. Now the game grows to four players. Then you want to record how many turns each person has had. Then whether they are still in the round.

Count what you are now juggling: sixteen separate names, four of which you must remember to update together every single time anybody rolls. Miss one and the scores drift apart quietly, which is the worst kind of bug.

The real problem is that the language does not know these things belong together. You know name1 and score1 describe one person. Kotlin has no idea.

A class is how you tell it.

Your first class

1class Player(val name: String, var score: Int = 0)
2
3fun main() {
4  val ada = Player("Ada")
5  val alan = Player("Alan", 5)
6  println(ada.name)
7  println(alan.score)
8}

That prints Ada then 5. One line of class declaration replaced all four loose values, and it will still be one line when the game has forty players.

Three things to notice.

The brackets after the class name are the constructor. They say what you must supply in order to make one. Player needs a name; the score is optional because it has a default of zero, exactly like the default parameters from Lesson 1.9.

val name inside the constructor does two jobs at once. It takes the name in and keeps it as a property of the object. Leave the val off and the value would be used during construction and then thrown away.

There is no new keyword. Player("Ada") is all it takes to build one. If you have seen Java or C#, this is one of the first things Kotlin quietly deletes.

Each thing you build is an instance. ada and alan are two instances of the same class, and they are completely independent — ada.score and alan.score are different boxes that happen to have the same label.

val and var work exactly as you would expect

1ada.score = 12   // fine, score is a var
2ada.name = "Zoe" // e: Val cannot be reassigned

A player's name is fixed for the life of the object; their score is not. You decide that when you write the class, and the compiler holds everyone to it afterwards — including you at midnight in three weeks.

Giving the class something to do

A class is not just a bag of values. It can hold functions too, and inside them it can see its own properties without any dots at all:

1class Player(val name: String, var score: Int = 0) {
2  fun scoreUp(points: Int) {
3    score = score + points
4  }
5}

A function that lives inside a class is called a method. You call it on an object:

ada.scoreUp(3)

Inside scoreUp, the bare word score means this particular player's score. Ada's call changes Ada's score and nobody else's. If you ever need to be explicit about which object you mean, the word this refers to it:

this.score = this.score + points

Identical meaning, more typing. Kotlin lets you drop this whenever there is no ambiguity, and by convention you do.

Keeping some things to yourself

Not every property should be public. Mark one private and only code inside the class can touch it:

1class Player(val name: String) {
2  private var rolls = 0
3}

Now ada.rolls will not compile from outside. That is not paranoia — it is a promise. The outside world can only change a Player through the methods you provided, so those methods are the only places a bug can come from.

One rough edge

Print an object and you get something disappointing:

println(alan)

Player@1b6d3586

That is the class name and a machine address. It tells you nothing about Alan, and the digits will be different every time you run the program. Comparing two objects with == is disappointing in the same way — two players with identical names and scores count as different.

Both of those are fixable in one word, and that word is the whole of Lesson 1.15.

1Ada: 7 in 2 rolls
2Alan: 5 in 0 rolls
3Player@1b6d3586