Antwoord.

Historisch gezien is Rust vanaf het begin ontworpen als een taal voor het schrijven van schaalbare, betrouwbare systeemsoftware. Het modulesysteem is gecreëerd voor een strikte scheiding van namespaces, isolatie van code en organisatie van grote projecten zonder naamconflicten. Modules maken het mogelijk om code te structureren, implementatiedetails te verbergen en het publieke API te beheren.

Het probleem is dat bij de groei van een project de vraag naar isolatie van componenten, het delen van code en het beheren van zichtbaarheid opkomt. Fouten zijn vaak gerelateerd aan onjuist gebruik van de sleutelwoorden pub, pub(crate), en ook aan het ontbreken of verkeerd organiseren van de mappen- en mapstructuur.

Oplossing: in Rust wordt een module gedeclareerd met het sleutelwoord mod; bestanden en mappen structureren de namespace, waarbij de hiërarchie wordt benadrukt. Alles is standaard privé, en de sleutelwoorden pub, pub(crate), pub(super) bieden de mogelijkheid om zichtbaarheid te beheren. Correct gebruik van exports, aliasen en een verstandige opsplitsing van het project in modules maken de code schaalbaar, onderhoudbaar en veilig.

Codevoorbeeld:

// src/lib.rs
mod network;
pub use network::client::Client;

// src/network/mod.rs
pub mod client;

// src/network/client.rs
pub struct Client {
    pub name: String,
}

Belangrijke kenmerken:

Standaard zijn elementen privé, expliciete opgave van pub is vereist voor export.
De structuur van modules wordt weerspiegeld in het bestandssysteem (mod.rs en submodules).
Mogelijkheid om interne logica te isoleren en "schone" publieke API's te vormen.

Lastige vragen.

Wat gebeurt er als de bestandsstructuur niet overeenkomt met de module-definities?

De code zal niet compileren: Rust verwacht een strikte overeenstemming tussen bestanden en modules (bijvoorbeeld, als mod foo is gedeclareerd, moet er een bestand foo.rs of een map foo/mod.rs bestaan).

Kan pub(crate) worden gebruikt om de implementatie te verbergen voor externe gebruikers, maar toegankelijk te zijn voor alle modules binnen de crate?

Ja, pub(crate) maakt een element zichtbaar in elke module van dezelfde crate, maar onzichtbaar voor externe projecten die deze crate als afhankelijkheid gebruiken.

Hoe importeer je functies uit een diep genestelde module in het hoofdbestand zonder publieke herexportatie (pub use)?

Via een directe link in de hiërarchie: crate::module::submodule::function. Zonder pub use zijn ze alleen binnen de crate beschikbaar.

Typische fouten en antipatterns

Slechte organisatie van de bestandsstructuur (ontbreken van mod.rs, dubbel declareren van modules in verschillende chunks).
Toegang tot een structveld zonder pub, wanneer een publiek API was gepland.
Gebruik van pub overal zonder noodzaak, wat de aanvalsoppervlakte vergroot en de encapsulatie vermindert.

Voorbeeld uit de praktijk

Negatieve case

In het project bevat de netwerkmodule alle componenten van de server, client, en protocolparser in één bestand network.rs. Alles is gepubliceerd, interne code is rechtstreeks aangesloten voor testing. Na verloop van tijd groeit de ongewenste samenhang en wordt het moeilijk om de publieke interface van de implementatie te scheiden.

Voordelen:

Snelle ontwikkeling in het begin, minder tijd aan het organiseren van bestanden.

Nadelen:

Er ontstaat "opblazen" van afhankelijkheden, privé-details zijn toegankelijk van buitenaf, moeilijk te onderhouden code.

Positieve case

Netwerk is opgesplitst in submodules: client, server, protocol. Alleen publieke interfaces worden geëxporteerd uit netwerk, de API is compact, details zijn ingekapseld. Tests voor elke module zijn geïsoleerd.