Respuesta

En el lenguaje de programación Rust, el nivel de acceso (visibilidad) a los métodos y campos de las estructuras está regulado por modificadores: pub, pub(crate), pub(super), así como la ausencia de modificador (por defecto, privado).

Historia del asunto

Rust fue diseñado originalmente para garantizar la fiabilidad y la aislamiento de los componentes. Controlar el acceso a las partes internas de las estructuras permite encapsular datos y ocultar detalles de implementación, manteniendo públicos solo los interfaces necesarios.

Problema

Los desarrolladores a menudo se enfrentan a situaciones en las que una estructura es pública, pero sus campos permanecen privados, o la publicabilidad de un campo resulta insuficiente debido a las restricciones de visibilidad de la propia estructura o módulo. Especialmente difícil de entender son los niveles anidados: una estructura anidada pública puede no estar disponible si el módulo contenedor está oculto, y viceversa.

Solución

En Rust, los modificadores de acceso se aplican a estructuras, sus campos y métodos, así como a módulos y funciones. Existen los siguientes niveles:

pub — hace que el elemento esté disponible desde cualquier lugar.
pub(crate) — solo está disponible dentro del crate actual.
pub(super) — solo está disponible desde el módulo padre.
Sin modificador — el elemento es privado dentro del módulo actual.

Ejemplo de código:

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,
        }
    }
}

Características clave:

La visibilidad de un campo o método no puede exceder la visibilidad de la propia estructura o módulo.
Para las estructuras anidadas, la visibilidad final se determina por la intersección del modificador y la visibilidad de todos los módulos parentales.
Las estructuras públicas con campos privados mantienen el patrón de encapsulación (constructores/métodos getter).

Preguntas engañosas.

Si una estructura se declara como pub, pero sus campos no tienen modificador, ¿se puede acceder a ellos desde otro módulo?

No, solo la estructura en sí se vuelve pública, pero sus campos permanecen privados dentro del módulo. Para acceder al campo, también debe declararse con pub.

¿Qué sucederá si se declara una estructura como pub(crate) y un campo dentro de ella como pub?

La visibilidad se limita a la propia estructura. Incluso si el campo es pub, no se puede acceder a él fuera del crate porque la estructura no está disponible.

pub(crate) struct Secret {
    pub data: i32, // pub no "pasa" a través de pub(crate)
}

¿Se puede declarar una estructura pub dentro de un módulo privado y acceder a ella desde afuera?

No. La visibilidad final se determina por el mínimo entre la estructura y el módulo. Si el módulo es privado, las estructuras y funciones dentro de él tampoco son visibles fuera de este módulo.

Errores comunes y anti-patrones

Dejar los campos de las estructuras públicos al diseñar API complejas.
Abrir la visibilidad de la estructura sin necesidad con "pub".
Tratar de ampliar la visibilidad de un campo, ignorando la restricción del módulo.

Ejemplo de la vida real

Caso negativo

En el proyecto, toda la estructura se hizo pública con campos abiertos para acelerar el desarrollo. Más tarde, se volvió difícil mantener la compatibilidad hacia atrás y controlar el acceso a los campos, ya que se modificaban directamente.

Ventajas:

Inicio rápido; no es necesario implementar getters.

Desventajas:

Sin control sobre la modificación de datos; empeoramiento de la encapsulación.
Dificultad para cambiar la estructura interna.

Caso positivo

Para la estructura pública, se implementaron campos privados y métodos públicos constructores/accesores. La estructura se exporta solo al nivel necesario del módulo.