Antwoord

In de programmeertaal Rust wordt het toegangsniveau (zichtbaarheid) tot de methoden en velden van structuren geregeld door modifiers: pub, pub(crate), pub(super), en ook door het ontbreken van een modifier (standaard — privé).

Geschiedenis van de kwestie

Rust is oorspronkelijk ontworpen voor betrouwbaarheid en isolatie van componenten. Toegangscontrole tot de interne onderdelen van structuren maakt het mogelijk om gegevens te encapsuleren en implementatiedetails te verbergen, terwijl alleen de benodigde interfaces openbaar blijven.

Probleem

Ontwikkelaars komen vaak situaties tegen waarin een structuur openbaar is, maar de velden privé blijven, of de openbaarheid van een veld niet voldoende is vanwege de beperkingen van de zichtbaarheid van de structuur of module zelf. Het is vooral moeilijk om geneste niveaus te begrijpen: een openbare geneste structuur kan onbereikbaar zijn als de bijbehorende module verborgen is, en omgekeerd.

Oplossing

In Rust worden toegangsmodifiers toegepast op structuren, hun velden en methoden, evenals op modules en functies. Er zijn de volgende niveaus:

pub — maakt het element toegangelijk vanuit elke plaats.
pub(crate) — alleen toegankelijk binnen de huidige crate.
pub(super) — alleen toegankelijk vanuit de bovenliggende module.
Zonder modifier — het element is privé binnen de huidige module.

Voorbeeld code:

mod outer {
    pub struct PublicStruct {
        pub field: u32,
        hidden: u32,
    }

    pub(crate) struct CrateStruct {
        pub value: i32,
    }

    struct PrivateStruct {
        pub secret: i32,
    }

    pub mod inner {
        pub(super) struct SuperStruct {
            pub super_field: u8,
        }
    }
}

Belangrijke kenmerken:

De zichtbaarheid van een veld of methode kan niet groter zijn dan de zichtbaarheid van de structuur of module zelf
Voor geneste structuren wordt de uiteindelijke zichtbaarheid bepaald door de kruising van de modifier en de zichtbaarheid van alle bovenliggende modules
Publieke structuren met privé velden ondersteunen het encapsulatiepatroon (constructors/getter-methoden)

Vragen met een valstrik.

Als een structuur als pub is gedeclareerd, maar de velden zonder modifier zijn, kan er dan vanuit een andere module naar worden verwezen?

Nee, alleen de structuur wordt publiek, maar de velden blijven privé binnen de module. Voor toegang tot een veld moet het ook als pub worden gedeclareerd.

Wat gebeurt er als een structuur als pub(crate) is gedeclareerd, en het veld binnenin als pub?

De zichtbaarheid wordt beperkt door de structuur zelf. Zelfs als het veld pub is, kan er geen toegang toe worden verkregen buiten de crate, omdat de structuur niet toegankelijk is.

pub(crate) struct Secret {
    pub data: i32, // pub "doet geen" pub(crate) bypassen
}

Kan een structuur pub worden gedeclareerd binnen een privé module en er buiten toegang toe krijgen?

Nee. De uiteindelijke zichtbaarheid wordt bepaald door het minimum tussen de structuur en de module. Als de module privé is, zijn structuren en functies binnenin ook niet zichtbaar buiten deze module.

Typische fouten en anti-patronen

Velden van structuren publiek laten bij het ontwerpen van complexe API's
De zichtbaarheid van een structuur zonder noodzaak openen met "pub"
Proberen de zichtbaarheid van een veld uit te breiden, terwijl de beperkingen van de module worden genegeerd

Voorbeeld uit het leven

Negatieve case

In het project is de hele structuur openbaar gemaakt met open velden voor een snellere ontwikkeling. Later werd het moeilijk om backward compatibility te onderhouden en toegang tot de velden te controleren, omdat deze direct werden gewijzigd.

Voordelen:

Snelle start; geen noodzaak om getters te implementeren

Nadelen:

Geen controle over dataveranderingen; verslechtering van encapsulatie
Moeilijkheden bij veranderingen in de interne structuur

Positieve case

Voor de publieke structuur zijn privé velden en publieke constructeur/accessor methoden geïmplementeerd. De structuur wordt alleen geëxporteerd op het benodigde niveau van de module.