"境界線を引けない設計に、信頼は宿らない。"
モジュールとは何か。
それは単なるファイル分割ではなく、意味の境界を定義する構文的構造である。
Rustは、モジュールシステムにおいて厳密な可視性制御と構造的封装を提供する。
それは、自由にアクセスすることを良しとせず、「誰が何を知るべきか」という設計倫理を構文に変換する試みだ。
この章では、Rustにおけるモジュール設計と pub による可視性指定の哲学を掘り下げ、
**「設計とは、見せないことの戦略である」**という原則を読み解いていく。
モジュールとは「意味を囲う枠組み」である
Rustにおけるモジュールは、mod を用いて次のように定義される。
mod authentication {
fn verify_token(token: &str) -> bool {
// ...
}
}
この verify_token は、デフォルトでは外部から見えない。
それは、**「この機能はモジュール内だけで使うべき」**という前提に基づいた設計である。
Rustは、「必要以上に知りすぎること」を防ぐ設計原則を徹底している。
pub は「意図のある開放」である
mod authentication {
pub fn verify_token(token: &str) -> bool {
// ...
}
}
pub をつけることで、この関数はモジュールの外からアクセス可能になる。
しかしこれは、「この関数は公開されるべき意味と安定性を持っている」という設計者の意思表明でもある。
つまり、pub は構文的なアクセス権ではなく、意味的に開かれるべきインターフェースの合図である。
「見せない」ことが構造を強くする
可視性の制限には以下のような意味がある：
- 内部実装の変更を外部に波及させない（非公開化による安定性）
- モジュール内部の凝集性を保ち、責務を分離する
- 依存の方向性を設計上明示する（依存関係の一方向化）
このように、「何を見せないか」という判断が、設計の明確性と安全性を生む。
モジュールは“責任のまとまり”であるべき
mod billing {
pub fn calculate_total(...) { ... }
fn apply_discount(...) { ... }
fn tax_rate(...) -> f64 { ... }
}
この設計では、外部に提供するAPI（calculate_total）は pub として公開し、
内部処理の補助関数は隠されている。
これは、設計者が「これだけを外部に公開し、他は隠す」と選んだ結果であり、
モジュールという空間が責任と情報のスコープを明示的に切っていることを示している。
モジュール境界をまたぐということは、設計的信頼を越えるということ
たとえば以下のような構成：
src/
├── user/
│ ├── mod.rs
│ ├── service.rs
│ └── repository.rs
├── billing/
│ └── mod.rs
このような構造では、user::service が billing::mod に直接依存するべきではない。
なぜなら、それはモジュールの責務を越えて、設計上の秩序を崩すことになるからである。
Rustのモジュール設計は、こうした構造の乱れを構文によって検知・制限する。
pub(crate) / pub(super)：段階的開放という思想
Rustには次のような可視性制御がある：
-
pub：どこからでも見える（完全公開） -
pub(crate)：同一クレート内のみ可視 -
pub(super)：親モジュールからのみ可視 -
pub(in path)：特定のモジュール階層に限定して公開
これは、**「段階的に公開範囲を拡げることで、安全な設計境界を維持する」**という設計戦略である。
モジュール境界とAPI設計は表裏一体
Rustにおける良いモジュール設計とは：
- APIがシンプルであること
- 内部の構造が分離されていること
- 変更がモジュール内に閉じていること
- 公開する構文が意味的に整合していること
それは、**「どこまでを“知ってよいか”をコード上で定義する」**ということに他ならない。
結語：設計とは見せることではなく、見せないことの選択である
Rustのモジュールと可視性制御は、情報隠蔽のための構文的装置ではない。
それは、「意味の境界をどこに置くか」という設計者の思想を表明する構文構造である。
構造を強くするのは、アクセスできることではない。
むしろ、意図なくアクセスできないことによって生まれる秩序こそが、設計における信頼性の本質である。
"良い設計とは、無闇に知ることを許さないことである。Rustのモジュールは、その知性を構文にしたものだ。"