Antwort.

In Kotlin ermöglichen Sichtbarkeitsmodifikatoren die Kontrolle über den Zugriff auf Deklarationen: Klassen, Eigenschaften, Funktionen und Top-Level (auf Dateiebene) Entitäten. Im Gegensatz zu Java, wo Modifikatoren nur auf Klassenebene wirken, gelten sie in Kotlin auch für Top-Level-Deklarationen, was wichtig für die Strukturierung großer Projekte und API-Bibliotheken ist.

Hintergrund

In Java gibt es keine Sichtbarkeitsmodifikatoren für Funktionen oder Eigenschaften außerhalb von Klassen – alles befindet sich innerhalb einer public (oder package-private) Klasse. In Kotlin ist es üblich, das Projekt anders zu strukturieren, oft befinden sich Funktionen oder Eigenschaften nicht innerhalb einer Klasse, sondern direkt in der Datei.

Problem

Oft erwarten Java-Entwickler, dass public standardmäßig genauso funktioniert wie in Java, aber in Kotlin ist eine Top-Level-Funktion (oder Eigenschaft) in allen Modulen sichtbar, wenn nicht anders markiert. Eine inkorrekte Festlegung der Sichtbarkeit kann zu einer lexikalischen Verunreinigung der öffentlichen API, unerwarteter Sichtbarkeit interner Hilfsfunktionen oder zum Fehlen benötigter öffentlicher Funktionen führen.

Lösung

In Kotlin sind folgende Modifikatoren verfügbar:

public: Deklaration ist überall sichtbar (ist der Standardmodifikator für Top-Level).
internal: Deklaration ist in allen Dateien desselben Moduls sichtbar (einem Gradle-Modul, einem kompilierten Artefakt, einer jar).
private: Sichtbar nur in derselben Datei/Klasse, in der sie deklariert ist. Für Top-Level - nur innerhalb der Datei.
protected: Nicht anwendbar für Top-Level-Deklarationen, nur für Klassen/Schnittstellen und deren Nachfolger.

Beispiel:

// datei: Foo.kt
private fun utilityFun() {}
internal val bar: Int = 10
public val baz: Int = 20 // public ist nicht erforderlich

fun printValue() {
    println(bar)
}

Wichtige Merkmale:

internal beschränkt die Sichtbarkeit auf das Modul (jar/Artefakt) und nicht auf das Paket.
protected kann nicht für Top-Level-Funktionen oder Eigenschaften verwendet werden.
private in Top-Level beschränkt die Deklaration auf die Grenzen der aktuellen Datei.

Fangfragen.

Kann protected für eine Top-Level-Funktion verwendet werden?

Nein, protected ist nur für Klassen- und Schnittstellenmitglieder relevant, Top-Level-Elemente werden nicht unterstützt.

Wenn eine Top-Level-Funktion mit internal deklariert wird, ist sie dann innerhalb anderer Module sichtbar?

Nein. Sie ist nur innerhalb des aktuellen jar/Gradle-Moduls sichtbar.

Was ist der Unterschied zwischen einer privaten Klasse und einer privaten Top-Level-Funktion?

private Klasse: nur innerhalb der aktuellen Datei sichtbar, kann nicht außerhalb der Datei verwendet werden.
private Top-Level-Funktion oder Eigenschaft: ebenfalls nur innerhalb der Datei sichtbar.

Beispiel:

// datei: Utils.kt
private fun helper() { /* ... */ } // nur in dieser Datei sichtbar
internal fun useful() { /* ... */ } // im gesamten Modul sichtbar

Typische Fehler und Antipatterns

Die Verwendung von public als Standard für alle Deklarationen führt zu einer "Verunreinigung" der Autovervollständigung und API.
Die Verwendung von internal für eine Bibliothek, die für externe Kunden gedacht ist, verbirgt notwendige öffentliche APIs.
Verwirrung mit protected und Versuche, sie auf Top-Level anzuwenden.

Beispiel aus dem Leben

Negativer Fall

Testhilfsmittel sind public deklariert und gelangen somit in das Artefakt, was dem Kunden der Bibliothek schadet — es wird alles sichtbar, was nicht zum öffentlichen API gehört.

Vorteile:

Schnelle Integration.

Nachteile:

Die Größe der öffentlichen API wächst, "zufällige" Methoden werden zugänglich.

Positiver Fall

Interne Funktionen sind als private deklariert, Hilfsmittel mit internal Sichtbarkeit für die allgemeine Verwendung innerhalb des Moduls, nur sorgfältig durchdachte Schnittstellen sind public zugänglich.