Antwort.

Geschichte der Frage:

Sichtbarkeitsmodifikatoren (visibility modifiers) sind ein zentrales Merkmal von Kotlin, das von Java geerbt und verbessert wurde. Sie ermöglichen es, den Zugriff auf Klassen, Funktionen und Eigenschaften einzuschränken, während sie die besten Praktiken der Kapselung und Modularität unterstützen.

Problem:

Eine falsche Verwendung der Sichtbarkeit kann zu Verletzungen der Architekturschichten, zur Offenlegung von Implementierungen nach außen oder umgekehrt dazu führen, dass Klassen und Methoden dort nicht verfügbar sind, wo sie benötigt werden. Fehler werden häufig zu spät entdeckt.

Lösung:

In Kotlin gibt es vier Sichtbarkeitsmodifikatoren:

public — überall zugänglich (Standard)
internal — nur innerhalb eines Moduls zugänglich
protected — innerhalb der Klasse und ihrer Unterklassen zugänglich
private — nur innerhalb der Datei, Klasse oder des Objekts zugänglich

Beispielcode:

open class Base {
    private fun onlyBase() {}
    protected fun baseAndDerived() {}
    internal fun insideModule() {}
    public fun anyone() {}
}

class Derived : Base() {
    fun test() {
        baseAndDerived() // zugänglich
        // onlyBase() — Fehler
    }
}

Wichtigste Merkmale:

internal ist spezifisch für Kotlin, in Java nicht vorhanden
Modifikatoren für Top-Level-Elemente funktionieren anders: private schränkt die Sichtbarkeit auf die Datei ein
In Schnittstellen sind alle Methoden und Eigenschaften standardmäßig public

Fangfragen.

Wie funktioniert der Modifikator internal bei der Veröffentlichung einer Bibliothek?

internal verbirgt Elemente innerhalb eines Moduls, aber wenn die Bibliothek in jar/aar kompiliert wird, sind internal-Elemente über Reflection sichtbar.

Was ist der Unterschied zwischen private für eine Klassenproperty und einer Top-Level-Funktion?

private bei einer Klassenproperty schränkt die Sichtbarkeit nur auf die Klasse ein, während es bei Top-Level nur auf die Datei beschränkt ist, in der das Element deklariert ist.

Kann protected auf eine Top-Level-Funktion angewendet werden?

Nein, protected ist nur für Mitglieder von Klassen oder Schnittstellen zulässig. Für Top-Level kann protected nicht verwendet werden — es wird ein Compile-Fehler auftreten.

Typische Fehler und Anti-Patterns

Übermäßig offene Klassen und Funktionen (public ohne Notwendigkeit)
Verwendung von internal, wo ein Modul unabhängige Komponenten vereint
Versuch, protected für Top-Level-Funktionen oder Eigenschaften zu verwenden

Beispiel aus der Praxis

Negativer Fall

Eine große Bibliothek hat fast alle APIs public erklärt, einschließlich Utilities und Helfer — infolgedessen wurden Benutzer von Implementierungsdetails abhängig.

Vorteile:

Einfache Nutzung für alle

Nachteile:

Schwierigkeiten mit der Abwärtskompatibilität und Refactoring

Positiver Fall

Es werden nur die erforderlichen Klassen als public deklariert, die anderen sind internal oder private, die Sichtbarkeitsstufen sind klar getrennt.