About This Series
Check Out the Pluralsight Course!
If you like this series, be sure to check out my course on Pluralsight – Building Android Apps with Kotlin: Getting Started where you can learn more while building your own real-world application in Kotlin along the way. You can also join the conversation and test your knowledge throughout the course with learning checks through each module!
Kotlin Visibility Modifiers
Visibility modifiers are what we use to facilitate the Encapsulation and Polymorphism aspects of object-oriented design and it seems that every language handles a few things differently. We use modifiers to restrict access to certain parts of our code from other code. We know Kotlin is interoperable with Java, but their visibility modifiers are actually different in a few ways!
Java has 4 primary modifiers:
package-private: The default if you do not explicitly provide one
However, these modifiers are not available for top level structures such as classes or interfaces. All the modifiers are used for members of those classes and interfaces, but only
package-private are used for the actual classes and interfaces.
Oracle has created a useful chart on what each modifier is and what it restricts:
Those are pretty straightforward.
public means everyone gets to see it,
protected means subclasses and packages can see it,
package-private means objects in the same package see it, but that’s it, and
private means only the immediate class can see it.
Let’s look at Kotlin’s implementation, and what I personally believe to be more useful and logical. If you come from a C# background these will seem familiar.
Kotlin has 4:
One important thing to note is that Kotlin, unlike many other languages, defaults to public. This means everything is exposed, and it is up to the developer to determine what should be hidden. Java’s approach is to enforce the security more directly with their default which then forces the developer to determine what should be exposed. It’s an interesting approach, but the more you get into Kotlin development, the more you’ll see why it is appropriate for the style. Kotlin is statically-typed object oriented, but does not require your code to be written in forced structures, and has a lot of functional aspects to it, but we’ll get into that later in the series.
Let’s create our own chart for these:
||Yes||Yes||Yes if in Module||No||Yes|
*Modules are unique to Kotlin and include all files compiled in one source-set. More info here https://kotlinlang.org/docs/reference/visibility-modifiers.html#modules
Some important things to note:
protectedis not visible to the entire package – it is basically
privatebut also exposes to sublcasses. This is the same as C#
internalis like public if the referencing code is within the same Module
privateis not just for classes, since Kotlin does not actually require a class for functions.
privaterestricts to the actual FILE that the code lives in.
Now that we know how to use encapsulation and visibility modifiers, we can start to understand more of how we can secure our code and architect our solutions in strong and logical ways.
Interested in sponsoring developer content? Message @Suave_Pirate on twitter for details.