Rust에서 접근 제어자(pub, pub(crate), pub(super))는 데이터와 함수에 대한 캡슐화를 명확히 하고 접근을 제어하기 위한 메커니즘으로 등장했습니다. C에서는 이러한 기능이 부족했습니다. 아이디어는 모듈 요소의 가시성을 제한하고 라이브러리 사용자에게 실제로 필요한 것만 제공하는 것입니다.
핵심적인 어려움은 구조체가 공개(pub)로 선언되더라도 필드는 기본적으로 비공개로 남아 있다는 것입니다. 또한 중첩된 구조체와 모듈에 대한 접근을 올바르게 구성하는 방법에 대한 질문이 자주 제기되며, 캡슐화를 훼손하지 않으면서 API가 "구멍이 뚫린" 상태가 되거나 반대로 너무 비공식적으로 되지 않도록 해야 합니다.
구조체의 경우 필드에 대한 접근 제어자를 별도로 지정해야 합니다. 자동 생성 구조체 또는 저장 타입을 설계할 때, 외부에 공개해야 할 부분과 숨겨야 할 부분을 신중하게 고민해야 합니다. 이는 API와 코드 아키텍처의 중요한 부분입니다.
코드 예시:
mod outer { pub struct Exposed { pub field: i32, hidden: bool, } } // "field" 필드는 사용 가능, // hidden은 불가능합니다. let e = outer::Exposed { field: 42, hidden: true }; println!("{}", e.field); // e.hidden // 컴파일 오류
주요 특징:
pub으로 선언된 구조체가 현재 모듈 외부에서 완전히 접근 불가능할 수 있나요?
네, 구조체의 모든 필드가 비공개로 남아 있다면, 구조체는 이름만으로 공개된 것이며, 모듈 외부에서 인스턴스를 생성하거나 초기화할 수 없습니다.
구조체의 비공개 필드가 상속이나 다른 방법을 통해 접근 가능해질 수 있나요?
아니요, Rust에는 OOP 언어와 같은 전통적인 상속이 없습니다. 비공식 필드에 대한 접근은 모듈에서 제어되며 상당히 제한적입니다.
모든 필드가 공개된 구조체를 생성했지만 모듈을 비공개로 선언하면 어떻게 되나요?
구조체와 그 필드는 부모 모듈 외부에서 볼 수 없게 됩니다 — 제어자는 부모 모듈의 가시성 범위를 넘어설 수 없습니다.
부정적인 사례
사용자가 구조체를 pub으로 선언했지만 모든 필드가 비공개로 남아 있습니다. 결과적으로 외부 코드는 이를 올바르게 사용하지 못하고 인스턴스를 생성하거나 값을 얻을 수 없습니다.
장점:
단점:
긍정적인 사례
사용자가 필요한 필드만 pub을 통해 열어두고 민감한 세부사항을 비공개로 남겼습니다. 접근은 게터/세터를 통해 이루어집니다.
장점:
단점: