Réponse.

Historique de la question :

Les modificateurs de visibilité (visibility modifiers) sont une caractéristique clé de Kotlin, héritée et améliorée par rapport à Java. Ils permettent de restreindre l'accès aux classes, fonctions et propriétés, en soutenant les meilleures pratiques d'encapsulation et de modularité.

Problème :

Une utilisation incorrecte de la visibilité peut entraîner une rupture des couches d'architecture, une fuite d'implémentation vers l'extérieur, ou au contraire - rendre des classes et méthodes inaccessibles là où elles sont nécessaires. Les erreurs à ce sujet sont souvent découvertes trop tard.

Solution :

En Kotlin, il existe quatre modificateurs de visibilité :

public - accessible partout (par défaut)
internal - accessible uniquement à l'intérieur d'un module
protected - accessible à l'intérieur de la classe et de ses sous-classes
private - accessible uniquement à l'intérieur du fichier, de la classe ou de l'objet

Exemple de code :

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

class Derived : Base() {
    fun test() {
        baseAndDerived() // accessible
        // onlyBase() - erreur
    }
}

Caractéristiques clés :

internal est spécifique à Kotlin, absent en Java
Les modificateurs pour les éléments au niveau supérieur fonctionnent de manière particulière : private limite la visibilité au fichier
Dans les interfaces, toutes les méthodes et propriétés sont par défaut publiques

Questions pièges.

Comment fonctionne le modificateur interne lors de la publication d'une bibliothèque ?

internal cache les éléments à l'intérieur d'un module, mais si la bibliothèque est compilée en jar/aar, les éléments internes sont visibles par réflexion.

Quelle est la différence entre privé pour une propriété de classe et une fonction de niveau supérieur ?

private sur une propriété de classe limite la visibilité uniquement à la classe, tandis que pour un niveau supérieur - uniquement au fichier où l'élément est déclaré.

Peut-on appliquer protected à une fonction de niveau supérieur ?

Non, protected est seulement admissible pour les membres d'une classe ou d'une interface. Pour un niveau supérieur, protected ne peut pas être utilisé - cela entraînera une erreur de compilation.

Erreurs typiques et anti-patterns

Classes et fonctions excessivement ouvertes (public sans nécessité)
Utilisation d'internal là où le module regroupe des composants indépendants
Tentative d'utiliser protected pour des fonctions ou propriétés de niveau supérieur

Exemple de la vie réelle

Cas négatif

Une grande bibliothèque a déclaré presque toutes les API publiques, y compris des utilitaires et des helpers - en conséquence, les utilisateurs sont devenus dépendants des détails d'implémentation.

Avantages :

Simplicité d'utilisation pour tous

Inconvénients :

Difficultés avec la compatibilité ascendante et le refactoring

Cas positif

Seules les classes nécessaires sont déclarées publiques, les autres sont internes ou privées, les niveaux de visibilité sont clairement séparés.