Antwoord.

Achtergrond van de vraag

In Rust zijn toegankelijkheidsmodificatoren (pub, pub(crate), pub(super)) geïntroduceerd als een mechanisme voor encapsulatie en duidelijke controle van toegang tot gegevens en functies, wat ontbrak in C. Het idee is om het bereik van elementen binnen een module te beperken en bibliotheekgebruikers alleen te geven wat ze echt nodig hebben.

Probleem

De belangrijkste moeilijkheid is dat zelfs als de structuur zelf openbaar (pub) is, de velden standaard privé blijven. Er rijst ook vaak de vraag hoe de toegang tot geneste structuren en modules goed te organiseren, zonder de encapsulatie te schenden of de API "doorlatend" of juist te gesloten te maken.

Oplossing

Voor structuren moet je expliciet toegankelijkheidsmodificatoren voor de velden aangeven. Bij het ontwerpen van autogegenereerde structuren of opslagtypes is het belangrijk om goed na te denken over welke delen naar buiten zichtbaar moeten zijn en welke verborgen blijven. Dit is een belangrijk onderdeel van de API en de code-architectuur.

Voorbeeld van code:

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

// Gebruik van het veld "field" is toegankelijk,
// hidden – niet.
let e = outer::Exposed { field: 42, hidden: true };
println!("{}", e.field);
// e.hidden // compileerfout

Belangrijke kenmerken:

Alle velden van de structuur zijn standaard privé, zelfs als de structuur zelf openbaar is.
Toegang tot de velden moet expliciet worden toegestaan via pub of pub(...).
pub(crate) en pub(super) bieden meer nauwkeurige controle over het toegangsniveau tot de interne onderdelen van modules.

Vragen met een valstrik.

Kan een structuur die als pub is gedeclareerd volledig onbereikbaar zijn buiten de huidige module?

Ja, als alle velden van de structuur privé blijven, is ze alleen openbaar qua naam — je kunt een instantie van de structuur niet buiten de module maken of initialiseren.

Kan een privé veld van een structuur toegankelijk worden via overerving of een andere manier, om de systeem van modificatoren heen?

Nee, in Rust is er geen klassieke overerving zoals in OOP-talen. Toegang tot privé velden wordt beheerd door de module en is sterk beperkt.

Wat gebeurt er als je een structuur maakt met publieke velden, maar de module privé verklaart?

De structuur en zijn velden zullen niet zichtbaar zijn buiten de bovenliggende module — de modificatoren overschrijden niet de zichtbaarheid van de bovenliggende module.

Veelvoorkomende fouten en anti-patronen

Een structuur openbaar maken, maar zonder openbare velden/metodes — nutteloze abstractie.
Overmatige pub geven, interne details van de API blootleggen en het onderhoud compliceren.
Ten onrechte denken dat pub automatisch ook de velden toegankelijk maakt.

Voorbeeld uit het leven

** Negatieve case

De gebruiker heeft de structuur pub gedeclareerd, maar alle velden zijn privé gebleven. Als gevolg hiervan kan externe code het niet correct gebruiken, noch een instantie maken, noch waarden verkrijgen.

Voordelen:

Onbedoelde beperking van de zichtbaarheid beschermt interne gegevens

Nadelen:

De structuur kan niet buiten de module worden gebruikt, zelfs als dat de bedoeling was

** Positieve case

De gebruiker heeft alleen de noodzakelijke velden toegankelijk gemaakt via pub, terwijl gevoelige details privé zijn gebleven. Toegang wordt verkregen via getters/setters.