Réponse.

Historique de la question

En Rust, les modificateurs de visibilité (pub, pub(crate), pub(super)) ont été introduits comme un mécanisme pour l'encapsulation et le contrôle clair de l'accès aux données et fonctions, ce qui manquait en C. L'idée est de limiter la portée des éléments du module et de donner aux utilisateurs de la bibliothèque uniquement ce qui est vraiment nécessaire.

Problème

La principale difficulté est que même si la structure elle-même est déclarée publique (pub), ses champs restent par défaut privés. Il se pose également souvent la question : comment organiser correctement l'accès aux structures et modules imbriqués sans compromettre l'encapsulation et sans rendre l'API « poreuse » ou, au contraire, trop fermée.

Solution

Pour les structures, il est nécessaire d'indiquer séparément les modificateurs d'accès pour les champs. Lors de la conception de structures générées automatiquement ou de types stockés, il est important de réfléchir attentivement aux parties qui doivent être exposées et à celles qui doivent rester cachées. C'est une partie importante de l'API et de l'architecture du code.

Exemple de code :

mod outer {
    pub struct Exposed {
        pub field: i32,
        hidden: bool,
    }
}

// L'utilisation du champ "field" est disponible,
// hidden — non.
let e = outer::Exposed { field: 42, hidden: true };
println!("{}", e.field);
// e.hidden // erreur de compilation

Caractéristiques clés :

Tous les champs d'une structure sont privés par défaut, même si la structure elle-même est publique.
L'accès aux champs doit être explicitement autorisé via pub ou pub(...).
pub(crate) et pub(super) offrent un contrôle plus précis sur le niveau d'accès aux détails internes des modules.

Questions pièges.

Une structure déclarée comme pub peut-elle être totalement inaccessible en dehors du module actuel ?

Oui, si tous les champs de la structure restent privés, elle est publique uniquement de nom — il n'est pas possible de créer ou d'initialiser une instance de la structure en dehors du module.

Un champ privé d'une structure peut-il devenir accessible par héritage ou d'une autre manière, contournant le système de modificateurs ?

Non, en Rust, il n'y a pas d'héritage classique comme dans les langages OOP. L'accès aux champs privés est contrôlé par le module et est considérablement limité.

Que se passe-t-il si vous créez une structure avec des champs publics, mais déclarez le module comme privé ?

La structure et ses champs ne seront pas visibles en dehors du module parent — les modificateurs ne dépassent pas la portée du module parent.

Erreurs typiques et anti-modèles

Laisser une structure publique, mais sans champs/méthodes publics — une abstraction inutile.
Donner un pub excessif, exposant les détails internes de l'API et compliquant la maintenance.
Croire à tort que pub rend automatiquement accessibles les champs.

Exemple de la vie

** Cas négatif

L'utilisateur a déclaré une structure pub, mais tous les champs sont restés privés. En conséquence, le code externe ne peut pas l'utiliser correctement, ni créer une instance, ni obtenir des valeurs.

Avantages :

La restriction involontaire de la portée protège les données internes.

Inconvénients :

Impossible d'utiliser la structure en dehors du module, même si cela était prévu.

** Cas positif

L'utilisateur a ouvert uniquement les champs nécessaires via pub, gardant les détails sensibles privés. Des getters/setters sont utilisés pour l'accès.