This lesson combines what we’ve learned previously about polymorphism with what we now know about references. We’ll examine how the type of a reference variable—not the type of what it refers to—determines what methods and field we can access using dot notation. We’ll also use this opportunity to reinforce our developing view of references.
When we introduced polymorphism and “is a” relationships, we introduced how the type of a variable and the type of the object stored in it could differ:
Now, using our more precise terminology, we can be more clear about exactly what is going on here:
One additional piece of Kotlin syntax that should now become more clear is dot notation. We’ve been using it to access object fields and methods:
Now we know what is happening!
. causes Kotlin to follow the reference variable to the object it refers to: in this case it follows
s to the
String we created on the line above.
If we create two references that lead to the same place, it will follow either:
With a bit more information under our belt, let’s go over a few more important examples of places where references are used.
When a method is called in Kotlin, what is passed to the method is a reference, not a copy of the object. This allows the method to modify the object. Let’s look at how this works!
And now, using a diagram to make the relationships clear visually:
Kotlin arrays that store objects actually store object references. This has some important implications. Let’s look at an example:
Some of you might be wondering: why would I ever write a method that accepts
It seems like you lose so much information about the object by doing that!
While that is true, the tradeoff is with generality. Let’s try and make that clear through an analogy:
Only a few women have won the Turing Award, computing’s highest honor. Barbara Liskov is one of them, cited for her “contributions to practical and theoretical foundations of programming language and system design, especially related to data abstraction, fault tolerance, and distributed computing.”
Barbara Liskov is also a particularly appropriate person to learn about now, as we study polymorphism. She’s responsible for the informal rule that a subtype (or descendant) should behave like the supertype (the parent or ancestor) when using the supertype methods. But why don’t we let her explain it herself!
Need more practice? Head over to the practice page.