Odpowiedź.

Historia pytania:

Modyfikatory widoczności (visibility modifiers) to kluczowa cecha Kotlin, odziedziczona i udoskonalona w porównaniu do Javy. Umożliwiają one ograniczenie dostępu do klas, funkcji i właściwości, wspierając najlepsze praktyki enkapsulacji i modularności.

Problem:

Nieprawidłowe użycie widoczności może prowadzić do naruszenia warstw architektury, wycieku implementacji na zewnątrz, lub odwrotnie — uczynienia klas i metod niedostępnymi tam, gdzie są potrzebne. Błędy w tym często wykrywane są zbyt późno.

Rozwiązanie:

W Kotlinie istnieją cztery modyfikatory widoczności:

public — dostępne wszędzie (domyślnie)
internal — dostępne tylko wewnątrz jednego modułu
protected — dostępne wewnątrz klasy i jej podklas
private — dostępne tylko wewnątrz pliku, klasy lub obiektu

Przykład kodu:

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

class Derived : Base() {
    fun test() {
        baseAndDerived() // dostępne
        // onlyBase() — błąd
    }
}

Kluczowe cechy:

internal jest specyficzne dla Kotlin, nie występuje w Javie
Modyfikatory dla top-level elementów działają w szczególny sposób: private ogranicza widoczność do pliku
W interfejsach wszystkie metody i właściwości są domyślnie publiczne

Pytania z pułapką.

Jak działa modyfikator internal przy publikacji biblioteki?

internal ukrywa elementy wewnątrz jednego modułu, ale jeśli skompilujesz bibliotekę do jar/aar, elementy internal są widoczne przez refleksję.

Czym różni się private dla właściwości klasy i funkcji top-level?

private dla właściwości klasy ogranicza widoczność tylko do klasy, a dla top-level — tylko do pliku, w którym zadeklarowano element.

Czy można zastosować protected do funkcji top-level?

Nie, protected jest dozwolony tylko dla członków klasy lub interfejsu. Dla top-level protected nie można używać — wystąpi błąd kompilacji.

Typowe błędy i antywzorce

Zbyt otwarte klasy i funkcje (public bez potrzeby)
Użycie internal tam, gdzie moduł łączy niezależne komponenty
Próba użycia protected dla funkcji lub właściwości top-level

Przykład z życia

Negatywny przypadek

Duża biblioteka ogłosiła prawie całe API jako publiczne, w tym narzędzia i pomocniki — w wyniku czego użytkownicy zaczęli polegać na detalach implementacji.

Zalety:

Łatwość użycia dla wszystkich

Wady:

Trudności z kompatybilnością wsteczną i refaktoryzacją

Pozytywny przypadek

Ogłoszone tylko niezbędne klasy jako publiczne, pozostałe internal lub private, wyraźnie oddzielone poziomy widoczności.