Antwoord.

In Kotlin stellen zichtbaarheidmodificatoren je in staat om de toegang tot declaraties te beheersen: klassen, properties, functies en top-level (op bestandsniveau) entiteiten. In tegenstelling tot Java, waar modificatoren alleen op klassenniveau werken, werken ze in Kotlin ook voor top-level declaraties, wat belangrijk is voor het structureren van grote projecten en library API's.

Geschiedenis van de kwestie

In Java zijn er geen zichtbaarheidmodificatoren voor functies of properties buiten de klasse — alles bevindt zich binnen een public (of package-private) klasse. In Kotlin is het gebruikelijk om de projectstructuur op een andere manier te organiseren, waarbij een functie of property vaak niet binnen een klasse is, maar direct in het bestand.

Probleem

Ontwikkelaars van Java verwachten vaak dat public standaard werkt zoals in Java, maar in Kotlin is een top-level functie (of property) zichtbaar in alle modules, tenzij anders gemarkeerd. Onjuist gedefinieerde zichtbaarheid kan leiden tot lexicale vervuiling van de publieke API, onverwachte beschikbaarheid van interne hulpprogramma's, of onbeschikbaarheid van benodigde publieke functies.

Oplossing

In Kotlin zijn de volgende modificatoren beschikbaar:

public: de declaratie is overal zichtbaar (is de standaardmodificator voor top-level).
internal: de declaratie is zichtbaar in alle bestanden van dezelfde module (één Gradle-module, één compileerbaar artifact, één jar).
private: alleen zichtbaar in hetzelfde bestand/dezelfde klasse waar het is gedeclareerd. Voor top-level: alleen binnen het bestand.
protected: niet toepasbaar voor top-level declaraties, alleen voor klassen/interfaces en hun afgeleiden.

Voorbeeld:

// bestand: Foo.kt
private fun utilityFun() {}
internal val bar: Int = 10
public val baz: Int = 20 // public is niet verplicht

fun printValue() {
    println(bar)
}

Belangrijke kenmerken:

internal beperkt de zichtbaarheid tot de module (jar/artifact), en niet tot het pakket.
protected kan niet worden gebruikt voor top-level functies of properties.
private in top-level beperkt de declaratie tot het huidige bestand.

Vragen met een haakje.

Mag je protected gebruiken voor een top-level functie?

Nee, protected is alleen relevant voor leden van een klasse/interface; top-level elementen ondersteunen dit niet.

Als je een top-level functie declareert met internal, is deze dan zichtbaar in andere modules?

Nee. Deze is alleen zichtbaar binnen het huidige jar/Gradle-module.

Wat is het verschil tussen een private klasse en een private top-level functie?

private klasse: alleen zichtbaar binnen het huidige bestand, kan niet buiten het bestand worden gebruikt.
private top-level functie of property: is ook alleen zichtbaar binnen het bestand.

Voorbeeld:

// bestand: Utils.kt
private fun helper() { /* ... */ } // alleen zichtbaar in dit bestand
internal fun useful() { /* ... */ } // zichtbaar binnen de gehele module

Typische fouten en anti-patronen

Het gebruik van public als standaard voor alle declaraties leidt tot "vervuiling" van autocompletie en API.
Het gebruik van internal voor een library, bedoeld voor externe clients, verbergt benodigde public API's.
Verwarring met protected en pogingen om deze toe te passen op top-level.

Voorbeeld uit het leven

Negatieve case

Testhulpprogramma's zijn publiek gedeclareerd en komen zo in het artifact, waardoor de klant van de bibliotheek in de problemen komt — alles dat niet bij de public API hoort, wordt zichtbaar.

Voordelen:

Snelle integratie.

Nadelen:

De grootte van de publieke API neemt toe, er verschijnen "toevallige" methoden die toegankelijk zijn.

Positieve case

Interne functies zijn privé gedeclareerd, hulpprogramma's met internal zichtbaarheid voor algemeen gebruik binnen de module, alleen goed doordachte interfaces hebben public toegang.