Android Kotlin Basics – Visibility Modifiers

About This Series

This “Android Kotlin Basics” blog series is all about fundamentals. We’ll take a look at the basics of building Android apps with Kotlin from the SUPER basics, to the standard basics, to the not-so-basics. We’ll also be drawing comparisons to how things are done in Kotlin vs. Java and some other programming languages to build Android apps (like C# and Xamarin or JavaScript/TypeScript for Hybrid implementations).

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!

Watch it here: https://app.pluralsight.com/library/courses/building-android-apps-kotlin-getting-started/table-of-contents

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:

• public
• private
• protected
• 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 public and 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:

Access Levels

Modifier	Class	Package	Subclass	World
public	Yes	Yes	Yes	Yes
protected	Yes	Yes	Yes	No
no modifier	Yes	Yes	No	No
private	Yes	No	No	No

source: https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

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:

• public
• private
• protected
• internal

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:

Access Levels

Modifier	Class	Package	Subclass	World	Module*
public or no modifier	Yes	Yes	Yes	Yes	Yes
protected	Yes	No	Yes	No	No
internal	Yes	Yes	Yes if in Module	No	Yes
private	Yes	No	No	No	No

*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:

• protected is not visible to the entire package – it is basically private but also exposes to sublcasses. This is the same as C# protected.
• internal is like public if the referencing code is within the same Module
• private is not just for classes, since Kotlin does not actually require a class for functions. private restricts 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.

If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Interested in sponsoring developer content? Message @Suave_Pirate on twitter for details.