Welcome back! Today's lesson introduces us to both a big new idea, and a new programming pattern. We'll show how Kotlin enables encapsulation (big new idea) through visibility modifiers and setters and getters (new programming pattern). This is cool stuff.
So let's get started!
The new idea that we're introducing today is encapsulation. Wikipedia defines it:
In object-oriented programming (OOP), encapsulation refers to the bundling of data with the methods that operate on that data, or the restricting of direct access to some of an object's components. Encapsulation is used to hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called "getters" and "setters") to access the values, and other client classes call these methods to retrieve and modify the values within the object.
Let's unpack that definition together:
OK great—so we want to keep some parts of our
class private while allowing other parts to be public.
But how do we do that?
Kotlin provides multiple options. Here's one:
Notice that we've introduced a visibility modifier—
private—to indicate that, while both the
age should be set by the primary constructor, they are not available outside the class.
Let's talk a bit more about what that means:
Kotlin has two visibility modifiers.
By default properties and methods are
public—meaning that can be accessed by anyone.
However, there are two other options:
private: the property or method can be accessed or called only in code that is part of that
internal: this won't make sense to us yet, but we'll come back to it...
For now we'll stick to
private and, when omitted, to
internal a few lessons from now.
And keep in mind that if you don't mark a method or field as
internal, it ends up as public.
This is normally the right thing, so it's a good default for Kotlin to provide.
When we declare properties in Kotlin as primary constructor parameters or within the class, Kotlin provides a reasonable set of defaults supporting common programming patterns. Here are some of our options.
First option: public, set in the primary constructor, can be read and written outside the class after creation:
Note that we can use
val here if we want a variable that is only set in the primary constructor and can't change afterward.
Second option: public, not set in the primary constructor, can be read and written outside the class after creation:
Third option: private, set in the primary constructor, can only be read and written by instance methods after creation:
Fourth option: private, not set in the primary constructor, can only be read and written by instance methods after creation:
Let's review these options together!
However, there are times where we need a bit more control. Let's see how to accomplish that by customizing the methods that Kotlin uses to change variable values.
If these options seem confusing, don't worry: we'll get lots of practice at choosing the right approach for each situation that we encounter!