Hoe werken zichtbaarheidmodifiers (visibility modifiers) in Kotlin: internal, private, protected, public? Wat zijn de verschillen tussen modifiers in verschillende contexten — voor klassen, functies, eigenschappen, objecten, top-level functies en bestanden?

Antwoord

In Kotlin zijn er de volgende zichtbaarheidmodifiers:

• public (standaard): het element is overal zichtbaar.
• internal: het element is zichtbaar binnen één module (jar/gradle module enz.).
• protected: alleen zichtbaar binnen de klasse en haar afgeleiden.
• private: alleen zichtbaar binnen het bestand of de klasse.

Kenmerken:

• Voor top-level functies, eigenschappen en klassen: private beperkt de toegang tot het bestand, internal - tot de module, en public/protected heeft geen zin buiten de klasse.
• Voor leden van een klasse: private - alleen binnen die klasse, protected - plus afgeleiden, internal en public - zoals hierboven beschreven.
• Binnen object/companion object: vergelijkbaar met de klasse.

class MyClass {
    private val secret = "verborgen"
    protected val id = 42
    internal fun foo() {}
    public fun bar() {}
}

internal fun moduleFunc() {}
private fun fileOnlyFunc() {}

---

Vragende valstrik

"Kan een top-level functie protected zijn? Zo ja — hoe werkt dat? Zo nee — waarom niet?"

Antwoord: Nee, een top-level functie kan niet protected zijn, omdat er geen klasse is waaraan dit niveau van toegang toebehoort. Dit wordt door de compiler afgehandeld - er zal een compilatiefout optreden.

protected fun magic() {} // Fout: protected modifier is niet toegestaan voor top-level functies

---

Voorbeelden van echte fouten door onbekendheid met de subtiliteiten van het onderwerp

---

Verhaal

In een fintech-app werd vergeten dat de internal-modifier toegang biedt tot alle elementen van de module. Als gevolg hiervan werd bij het refactoren een deel van de logica naar een andere gradle-module verplaatst, waardoor de toegang tot de gegevens stopte, maar de ontwikkelaars merkten dit niet meteen, omdat er bij de compilatie geen fouten waren in de oude tests.

---

Verhaal

In een multiplatformproject werden vertrouwelijke gegevens gedefinieerd als private eigenschappen in een companion object. Het bleek dat deze gegevens werden geserialiseerd en toegankelijk werden via reflectie, omdat ze als val waren gedeclareerd zonder annotaties die de export beperkten.

---

Verhaal

Bij de start van het mobiele project werd private toegepast op top-level functies, in de veronderstelling dat dit de toegang tot partnerklassen zou beperken. Echter, binnen hetzelfde bestand met utils waren deze functies voor iedereen zichtbaar, wat leidde tot een bedreiging van informatielekken en onbedoeld gebruik ervan in de bedrijfslogica.