Antwoord.

Geschiedenis van de vraag:

Visibility modifiers zijn een sleutelkenmerk van Kotlin, geerfd en verbeterd in vergelijking met Java. Ze stellen je in staat om de toegang tot klassen, functies en eigenschappen te beperken, wat de beste praktijken van encapsulatie en modulariteit ondersteunt.

Probleem:

Onjuiste toepassing van zichtbaarheid kan leiden tot schending van architectonische lagen, uitlekkende implementatie naar buiten, of omgekeerd - klassen en methoden ontoegankelijk maken waar ze nodig zijn. Fouten hierin worden vaak te laat ontdekt.

Oplossing:

In Kotlin zijn er vier zichtbaarheid-modifiers:

public — overal toegankelijk (standaard)
internal — alleen toegankelijk binnen één module
protected — alleen toegankelijk binnen de klasse en zijn subklassen
private — alleen toegankelijk binnen het bestand, de klasse of het object

Codevoorbeeld:

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

class Derived : Base() {
    fun test() {
        baseAndDerived() // toegankelijk
        // onlyBase() — fout
    }
}

Belangrijkste kenmerken:

internal is specifiek voor Kotlin, ontbreekt in Java
Modifiers voor top-level elementen werken op een speciale manier: private beperkt de zichtbaarheid tot het bestand
In interfaces zijn alle methoden en eigenschappen standaard public

Vragen met een valstrik.

Hoe werkt de internal modifier bij het publiceren van een bibliotheek?

internal verbergt elementen binnen één module, maar als je de bibliotheek in jar/aar compileert, zijn internal-elementen zichtbaar via reflection.

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

private op een klasse-eigenschap beperkt de zichtbaarheid tot de klasse, terwijl het voor top-level alleen toegankelijk is binnen het bestand waar het element is gedeclareerd.

Kan protected worden toegepast op een top-level functie?

Nee, protected is alleen toegestaan voor leden van een klasse of interface. Voor top-level is protected niet toegestaan - er zal een compilatiefout zijn.

Typische fouten en anti-patronen

Te open klassen en functies (public zonder noodzaak)
Gebruik van internal waar de module onafhankelijke componenten verenigt
Poging om protected te gebruiken voor top-level functies of eigenschappen

Voorbeeld uit het leven

Negatief geval

Een grote bibliotheek heeft bijna alle API's public verklaard, inclusief hulpprogramma's en helpers - als gevolg daarvan gingen gebruikers afhankelijk worden van implementatiedetails.

Voordelen:

Eenvoudig gebruik voor iedereen

Nadelen:

Moeilijkheden met achterwaartse compatibiliteit en refactoring

Positief geval

Alleen noodzakelijke klassen zijn public verklaard, de rest is internal of private, niveaus van zichtbaarheid zijn duidelijk gescheiden.