Réponse

En Kotlin, il existe les modificateurs de visibilité suivants :

public (par défaut) : l'élément est visible partout.
internal : l'élément est visible à l'intérieur d'un seul module (jar/module gradle, etc.).
protected : visible uniquement à l'intérieur de la classe et de ses héritiers.
private : visible uniquement à l'intérieur du fichier ou de la classe.

Particularités :

Pour les fonctions, propriétés et classes top-level : private limite l'accès aux limites du fichier, internal - au module, et public/protected n'a pas de sens en dehors de la classe.
Pour les membres de classe : private - uniquement à l'intérieur de cette classe, protected - plus les héritiers, internal et public - comme décrit ci-dessus.
À l'intérieur d'un objet / d'un objet compagnon : similaire à une classe.

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

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

Question piège

"Une fonction top-level peut-elle être protégée ? Si oui, comment cela fonctionne-t-il ? Si non, pourquoi ?"

Réponse : Non, une fonction top-level ne peut pas être protégée, car il n'y a pas de classe à laquelle ce niveau d'accès appartient. Cela est géré par le compilateur - une erreur de compilation apparaîtra.

protected fun magic() {} //Erreur : le modificateur protected n'est pas autorisé pour les fonctions top-level

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

Histoire

Dans une application fintech, il a été oublié que le modificateur internal donne accès à tous les éléments du module. En conséquence, lors de la refonte, une partie de la logique a été déplacée dans un autre module gradle, après quoi l'accès aux données a cessé de fonctionner, mais les développeurs ne l'ont pas remarqué immédiatement, car il n'y avait pas d'erreurs dans les anciens tests à l'étape de compilation.

Histoire

Dans un projet multiplateforme, des données sensibles ont été définies comme des propriétés privées dans un objet compagnon. Il s'est avéré que ces données étaient sérialisées et devenaient accessibles par réflexion, car elles avaient été déclarées comme val sans utiliser d'annotations limitant l'exportation.

Histoire

Au début d'un projet mobile, le private a été utilisé pour des fonctions top-level, pensant que cela limiterait l'accès aux classes partenaires. Cependant, dans un fichier utilitaire commun, ces fonctions étaient visibles par tous, ce qui a conduit à un risque de fuite d'informations et à une utilisation imprévue dans la logique métier.