Visibility Modifiers in Kotlin

Analogy categoryAnalogies

Introduction

Kotlin uses visibility modifiers to control the accessibility of classes, objects, functions, and properties from other parts of a codebase. The four modifiers are public, private, protected, and internal. Choosing the right visibility helps enforce encapsulation, hide implementation details, and define clear module boundaries. public is the default modifier and makes a declaration visible everywhere. private restricts visibility to the containing class, or to the containing file for top-level declarations. protected makes a member visible to the declaring class and its subclasses, but it cannot be used on top-level declarations. internal makes a declaration visible anywhere within the same Gradle or Maven module; this has no direct equivalent in Java, where the closest options are package-private or public, making internal a distinctly Kotlin feature.

🏏

Cricket analogy: A team's public match schedule is visible to everyone like public, while the coach's private strategy notes stay within the dressing room like private, and internal tactics shared across the entire franchise's staff (coaches, analysts, scouts) mirror internal's module-wide visibility.

Syntax

kotlin

public class Account {
    private val id: String = "acc-1"
    protected open val balance: Double = 0.0
    internal val ownerModuleOnly: String = "internal-data"
}

Example

kotlin

open class Vehicle {
    private val serialNumber = "SN-001"
    protected open val maxSpeed = 120
    internal val fleetId = "FLEET-9"

    fun publicInfo(): String = "Fleet: $fleetId"
}

class Car : Vehicle() {
    override val maxSpeed = 180
    fun speedInfo(): String = "Max speed: $maxSpeed"
}

fun main() {
    val car = Car()
    println(car.publicInfo())
    println(car.speedInfo())
}

Output

kotlin

Fleet: FLEET-9
Max speed: 180

Key Takeaways

public is the default and visible everywhere.
private restricts access to the containing class or file.
protected is visible to the class and its subclasses only, not at top level.
internal restricts visibility to the same module and has no direct Java equivalent.
Choosing tighter visibility improves encapsulation and hides implementation details.