MENU
  1. ホーム
  2. Rust
  3. Rustでアクセス指定子を活用した依存性の低いモジュール設計法

Rustでアクセス指定子を活用した依存性の低いモジュール設計法

Rust

Rust言語は、その堅牢な型システムとメモリ安全性で知られていますが、さらに効率的で保守性の高いコードを実現するためには、依存性の低いモジュール設計が重要です。その鍵となるのがアクセス指定子の適切な活用です。モジュールの公開範囲を制御し、不要な依存関係を排除することで、ソフトウェアの柔軟性と信頼性を向上させることができます。本記事では、Rustのアクセス指定子の基本から応用までを掘り下げ、実践的なモジュール設計の方法を詳しく解説します。

目次

Rustのモジュールとアクセス指定子の基礎


Rustのモジュールシステムは、コードの論理的な分割と再利用を可能にする強力な機能を提供します。モジュールを適切に設計することで、コードの可読性、保守性、そして拡張性を高めることができます。

モジュールの基本


Rustのモジュールは、modキーワードを使って定義されます。モジュールは他のモジュールやクレート内で定義された構造体、関数、列挙型などをカプセル化します。例えば、以下のようにモジュールを定義します。

mod my_module {
    pub fn public_function() {
        println!("This is a public function.");
    }

    fn private_function() {
        println!("This is a private function.");
    }
}

この例では、public_functionはpubキーワードによって公開されており、モジュール外からアクセス可能です。一方、private_functionはデフォルトのアクセス指定でモジュール内のみで使用できます。

アクセス指定子の種類


Rustでは、以下のようなアクセス指定子を使用して要素の公開範囲を制御します。

  • pub: モジュール外部からアクセス可能にします。
  • pub(crate): 同じクレート内でのみアクセス可能にします。
  • pub(super): 親モジュールからのみアクセス可能にします。
  • デフォルト（非公開）: モジュール内からのみアクセス可能にします。

これらのアクセス指定子を適切に使うことで、モジュールのスコープを制限し、不要な依存関係を避けることができます。

モジュールの階層構造


Rustではモジュールを階層的に定義できます。例えば、以下のコードはネストされたモジュールを示しています。

mod outer {
    pub mod inner {
        pub fn inner_function() {
            println!("Inner function");
        }
    }
}

fn main() {
    outer::inner::inner_function(); // 外部からアクセス可能
}

ここでouterモジュールのinnerモジュールは公開されているため、inner_functionにアクセスできます。

まとめ


Rustのモジュールシステムとアクセス指定子は、コードの設計と制御において不可欠な要素です。次に、これらを活用した依存性制御のメリットについて掘り下げます。

アクセス指定子を使った依存性制御のメリット

アクセス指定子を活用することで、モジュール間の依存性を制御し、コードベース全体の品質を向上させることができます。以下にその具体的なメリットを解説します。

依存関係の明確化


アクセス指定子を適切に設定することで、モジュールがどの部分を外部に公開し、どの部分を非公開にするかを明確に示すことができます。この明確さにより、以下の効果が得られます。

  • 不要なモジュール間の依存を防止
  • 他の開発者が意図しない部分にアクセスするリスクを軽減
  • コードの責任範囲が明確になる

例えば、pub(crate)を使用してクレート内のみに公開することで、ライブラリ利用者に不要な内部詳細を見せないようにできます。

mod internal {
    pub(crate) fn helper_function() {
        println!("Helper function for crate use only.");
    }
}

この場合、helper_functionはクレート内部でのみ利用可能であり、クレート外からはアクセスできません。

保守性の向上


アクセス指定子による適切なスコープ管理は、保守性の向上に寄与します。以下のような利点があります。

  • 変更の影響範囲を限定: 非公開の部分は外部コードから直接利用されないため、内部構造を自由に変更可能です。
  • モジュールの独立性を確保: 依存性を最小化することで、モジュールが他のモジュールから独立してテストや変更を行いやすくなります。

セキュリティと安全性


アクセス指定子を使用して、不要な部分を非公開にすることで、コードの安全性を確保できます。意図しないアクセスによるバグやセキュリティの脆弱性を未然に防ぐことができます。

mod secure {
    pub fn public_api() {
        private_logic();
    }

    fn private_logic() {
        println!("This logic is internal and secure.");
    }
}

この例では、public_apiが外部から利用可能ですが、private_logicは内部でのみ使用可能です。

コラボレーションにおける役割分担の明確化


アクセス指定子を活用することで、チーム開発時に各モジュールや機能の責任範囲を明確に定義できます。これにより、他の開発者との衝突を防ぎ、開発速度が向上します。

まとめ


アクセス指定子による依存性制御は、コードの保守性、安全性、効率性を向上させる重要な要素です。次に、具体的な実例を通じて、どのようにこれらを設計に取り入れるかを見ていきます。

実例：モジュール設計の最適化

アクセス指定子を活用して依存性の低いモジュールを設計する方法を、実例を交えて解説します。この設計では、モジュール間の明確な役割分担と公開範囲の適切な制御が重要です。

ケーススタディ：認証システムのモジュール設計


認証システムを例に、モジュール設計を考えます。このシステムは、以下の機能を提供します：

  1. ユーザー情報の管理（内部処理のみ）
  2. パスワードのハッシュ化（内部でのみ使用）
  3. ログインAPI（外部に公開）

設計するモジュール構成：

  • user: ユーザー情報を管理（非公開）
  • auth: 認証機能を提供（部分公開）
  • api: 公開APIを提供（完全公開）

モジュールのコード例

以下に、アクセス指定子を活用したモジュール設計を示します。

// userモジュール
mod user {
    pub(crate) struct User {
        pub(crate) username: String,
        password_hash: String,
    }

    impl User {
        pub(crate) fn new(username: String, password_hash: String) -> Self {
            User { username, password_hash }
        }

        pub(crate) fn validate_password(&self, password: &str) -> bool {
            // パスワードのハッシュを検証
            self.password_hash == hash_password(password)
        }

        fn hash_password(password: &str) -> String {
            format!("hashed_{}", password) // ダミーのハッシュ化処理
        }
    }
}
// authモジュール
mod auth {
    use super::user::User;

    pub(crate) fn authenticate(username: &str, password: &str) -> bool {
        let user = User::new(username.to_string(), "hashed_password".to_string());
        user.validate_password(password)
    }
}
// apiモジュール
pub mod api {
    use super::auth;

    pub fn login(username: &str, password: &str) -> bool {
        if auth::authenticate(username, password) {
            println!("Login successful!");
            true
        } else {
            println!("Login failed.");
            false
        }
    }
}

設計のポイント

  1. userモジュール
  • 内部専用のデータ構造Userを定義。
  • pub(crate)でクレート内に限定して公開し、他のモジュールからアクセス可能にする。
  • パスワードハッシュ化のロジックは非公開にすることで、外部からの変更を防ぐ。
  1. authモジュール
  • 認証処理を担当し、authenticate関数をpub(crate)で限定的に公開。
  • 他のモジュールに依存性を持たせない設計。
  1. apiモジュール
  • 外部に公開する唯一のモジュールであり、pubキーワードを使用。
  • 内部モジュールに依存しているが、直接アクセスさせない。

この設計のメリット

  1. 明確な役割分担
    各モジュールが独立した役割を持ち、責任範囲が分かりやすい。
  2. 依存性の最小化
    外部に必要最小限の機能のみ公開し、不要なモジュール間の依存を防ぐ。
  3. 保守性の向上
    内部ロジックの変更が外部に影響しないため、長期的な保守が容易。

まとめ


このように、アクセス指定子を使った適切なモジュール設計は、ソフトウェアの保守性、セキュリティ、拡張性を高めます。次は、より具体的にpub(crate)を活用した設計方法を見ていきます。

pub(crate)でのスコープ制限の具体例

Rustでは、pub(crate)を使用することでクレート内でのみ公開するスコープを指定できます。これにより、モジュール間の依存性を制御しながらも、必要な機能を共有できます。このセクションでは、pub(crate)を活用した具体的な設計例を紹介します。

ユースケース：ライブラリ内部のデータ構造の共有


以下のケースを想定します：

  • coreモジュール: ライブラリ内部のロジックを処理。
  • utilsモジュール: ヘルパー関数を提供。
  • apiモジュール: 外部利用者に公開する機能を提供。

ここで、coreとutilsは内部専用にしたいが、一部の機能をクレート全体で共有する必要があります。

コード例

以下に、pub(crate)を利用した設計例を示します。

// coreモジュール
mod core {
    pub(crate) struct InternalData {
        pub(crate) value: i32,
    }

    impl InternalData {
        pub(crate) fn new(value: i32) -> Self {
            InternalData { value }
        }

        pub(crate) fn process(&self) -> i32 {
            self.value * 2
        }
    }
}
// utilsモジュール
mod utils {
    pub(crate) fn helper_function(value: i32) -> i32 {
        value + 10
    }
}
// apiモジュール
pub mod api {
    use crate::core::InternalData;
    use crate::utils::helper_function;

    pub fn public_api(input: i32) -> i32 {
        let data = InternalData::new(input);
        let processed = data.process();
        helper_function(processed)
    }
}

設計のポイント

  1. coreモジュールのスコープ制御
  • InternalData構造体とその関連関数はpub(crate)として定義されているため、クレート内の他のモジュールから利用可能です。
  • ライブラリ外部からはアクセスできず、内部のみに限定されています。
  1. utilsモジュールのヘルパー関数
  • helper_functionもpub(crate)として定義され、内部での再利用を可能にしています。
  • APIモジュール経由でしか間接的にアクセスできません。
  1. apiモジュールの公開範囲
  • クレートの外部にはpublic_api関数のみ公開しています。
  • 内部の詳細な実装（InternalDataやhelper_function）は隠蔽されています。

この設計のメリット

  1. モジュールの独立性の確保
  • coreやutilsの実装を変更しても、外部APIには影響がありません。
  • 内部でのみ使う機能を制限することで、モジュール間の依存性を管理しやすくなります。
  1. APIの安定性
  • 外部に公開されるインターフェースが限定されているため、予期しない利用者のエラーを防ぐことができます。
  1. 保守性の向上
  • 内部で使用するコードをpub(crate)で制御することで、コードベース全体の変更に強くなります。

具体例の活用

この方法は、特にライブラリの設計や大規模プロジェクトで有効です。pub(crate)を活用することで、ライブラリの利用者に見せるべき部分と隠すべき部分を明確に分けられます。

まとめ


pub(crate)を使うことで、クレート内のモジュール間での柔軟な共有が可能になります。同時に、外部には内部の実装を隠蔽し、ライブラリ全体の保守性と安全性を高められます。次は、デザインパターンとの組み合わせによるさらなる応用例を見ていきます。

デザインパターンとの組み合わせ

Rustのアクセス指定子を活用したモジュール設計は、デザインパターンと組み合わせることでさらに効果的になります。ここでは、代表的なデザインパターンとRust特有のモジュール構造を組み合わせた応用例を紹介します。

ユースケース：ファサードパターン

ファサードパターンは、システム内部の複雑なロジックを隠蔽し、簡潔なインターフェースを提供するデザインパターンです。このパターンは、Rustのモジュールとアクセス指定子を利用することで簡単に実現できます。

ファサードパターンのコード例

以下の例では、内部処理を隠蔽し、外部に単一のAPIを公開しています。

// internal モジュール
mod internal {
    pub(crate) fn complex_logic_part1(input: i32) -> i32 {
        input * 2
    }

    pub(crate) fn complex_logic_part2(input: i32) -> i32 {
        input + 10
    }
}

// facade モジュール
pub mod facade {
    use crate::internal;

    pub fn simple_api(input: i32) -> i32 {
        let part1 = internal::complex_logic_part1(input);
        internal::complex_logic_part2(part1)
    }
}

// メイン関数
fn main() {
    let result = facade::simple_api(5);
    println!("Result: {}", result); // 出力: Result: 20
}

設計のポイント

  1. 内部ロジックの隠蔽
  • internalモジュールはpub(crate)を使い、クレート内のみに公開しています。
  • 直接アクセスを防ぐことで、外部利用者に複雑さを隠します。
  1. 外部へのシンプルなインターフェース
  • facadeモジュールはpubで公開され、簡単なAPIとして機能します。
  • 内部ロジックが変更されても外部APIは安定したままです。

ユースケース：ストラテジーパターン

ストラテジーパターンは、アルゴリズムの実装を動的に切り替えることを可能にするデザインパターンです。Rustではtraitとモジュールを組み合わせて実現できます。

ストラテジーパターンのコード例

// strategy モジュール
pub mod strategy {
    pub trait Strategy {
        fn execute(&self, input: i32) -> i32;
    }

    pub struct AddStrategy;
    pub struct MultiplyStrategy;

    impl Strategy for AddStrategy {
        fn execute(&self, input: i32) -> i32 {
            input + 10
        }
    }

    impl Strategy for MultiplyStrategy {
        fn execute(&self, input: i32) -> i32 {
            input * 10
        }
    }
}

// context モジュール
pub mod context {
    use crate::strategy::Strategy;

    pub struct Context<'a> {
        strategy: &'a dyn Strategy,
    }

    impl<'a> Context<'a> {
        pub fn new(strategy: &'a dyn Strategy) -> Self {
            Context { strategy }
        }

        pub fn execute_strategy(&self, input: i32) -> i32 {
            self.strategy.execute(input)
        }
    }
}

// メイン関数
fn main() {
    use strategy::{AddStrategy, MultiplyStrategy};
    use context::Context;

    let add_strategy = AddStrategy;
    let multiply_strategy = MultiplyStrategy;

    let context = Context::new(&add_strategy);
    println!("Result with AddStrategy: {}", context.execute_strategy(5)); // 出力: 15

    let context = Context::new(&multiply_strategy);
    println!("Result with MultiplyStrategy: {}", context.execute_strategy(5)); // 出力: 50
}

設計のポイント

  1. 柔軟なアルゴリズム選択
  • Strategyトレイトを通じて、異なるアルゴリズムを統一的に扱います。
  1. モジュールの役割分担
  • strategyモジュールはアルゴリズムの実装を担当し、contextモジュールは実行環境を提供します。

デザインパターンとの組み合わせのメリット

  • 柔軟性の向上: 内部実装の変更が外部APIに影響を与えません。
  • 再利用性の向上: モジュールごとに独立性が保たれており、他のプロジェクトで再利用しやすいです。
  • 明確な責任分担: デザインパターンを通じてモジュールの責任範囲を明確化できます。

まとめ


ファサードパターンやストラテジーパターンなどのデザインパターンとRustのアクセス指定子を組み合わせることで、柔軟で拡張性の高いモジュール設計が可能になります。次は、チーム開発での活用例と注意点を見ていきます。

チーム開発でのモジュール設計の課題と解決策

チーム開発では、モジュール設計がプロジェクト全体のスムーズな進行に重要な役割を果たします。しかし、複数の開発者が関与する中で、モジュール設計には特有の課題が発生します。このセクションでは、Rustのアクセス指定子を活用した課題解決の方法を解説します。

課題1：モジュールの責任範囲が曖昧になる

問題点
複数の開発者が同時にコードを作成する際、モジュール間の責任範囲が曖昧になると、コードの依存が複雑化し、保守性が低下します。

解決策

  • アクセス指定子を活用する
    モジュールの役割に応じてpub(crate)やpubを使い、どこからアクセス可能かを明確にします。
  • 内部ロジックは非公開（デフォルト）またはpub(crate)
  • 公開APIは明確にpubで宣言

実例

mod database {
    pub(crate) struct Connection;

    impl Connection {
        pub(crate) fn new() -> Self {
            Connection
        }

        pub(crate) fn query(&self, query: &str) {
            println!("Executing query: {}", query);
        }
    }
}

pub mod api {
    use crate::database::Connection;

    pub fn run_query() {
        let connection = Connection::new();
        connection.query("SELECT * FROM users");
    }
}

この例では、Connection構造体はpub(crate)としてモジュール内部のみに公開されています。これにより、誤った使用を防ぎ、責任範囲を明確にしています。

課題2：依存関係の循環

問題点
モジュール間で循環参照が発生すると、コンパイルエラーや予期しない動作の原因となります。

解決策

  • 明確なモジュール階層を設計する
    モジュールの依存関係を一方向に保つよう設計します。
  • ファサードパターンの導入
    内部ロジックを1つのモジュールにカプセル化し、単一の公開モジュール（ファサード）を通じて利用します。

実例

mod core_logic {
    pub(crate) fn compute() -> i32 {
        42 // ダミー計算
    }
}

pub mod facade {
    use crate::core_logic;

    pub fn public_compute() -> i32 {
        core_logic::compute()
    }
}

ファサードパターンを使うことで、循環参照を防ぎ、モジュールの依存を一方向に保つことができます。

課題3：変更が他の開発者に影響する

問題点
内部ロジックの変更が他のモジュールや開発者に予期せず影響を及ぼす可能性があります。

解決策

  • 内部ロジックを非公開にする
    モジュール外部に公開する範囲を最小限に抑えます。
  • インターフェースの安定性を保つ
    公開APIは慎重に設計し、変更を最小限に抑えます。

実例

mod internal {
    pub(crate) fn helper() {
        println!("Internal helper");
    }
}

pub mod api {
    use crate::internal;

    pub fn public_function() {
        println!("Public function");
        internal::helper();
    }
}

internal::helperはpub(crate)で限定公開されているため、モジュール外からは直接アクセスできません。

課題4：レビューの複雑さ

問題点
モジュール設計が複雑すぎると、コードレビューが困難になります。

解決策

  • シンプルで直感的な設計を心がける
    モジュールを小さく保ち、1つの責任に集中させます。
  • モジュール設計をドキュメント化
    各モジュールの目的と公開範囲をドキュメントに明記します。

まとめ


チーム開発では、Rustのアクセス指定子を適切に活用することで、責任範囲の明確化、依存関係の整理、変更の影響範囲の縮小が可能です。次は、アクセス制御のベストプラクティスを詳しく解説します。

アクセス制御のベストプラクティス

Rustにおけるアクセス指定子を活用したモジュール設計では、適切な制御を行うことでコードの保守性と安全性を向上させることができます。このセクションでは、アクセス制御におけるベストプラクティスを解説します。

1. 公開範囲は最小限に抑える

基本方針
アクセス制御の基本は、必要最小限の範囲だけを公開することです。不要な公開は、誤った依存やバグの原因となります。

実例

mod internal {
    pub(crate) fn internal_function() {
        println!("Internal function");
    }
}

pub mod api {
    use crate::internal;

    pub fn public_function() {
        println!("Public function");
        internal::internal_function();
    }
}

この設計では、internal_functionは内部でのみ利用可能であり、api::public_functionが唯一の公開されたエントリーポイントになります。

2. デフォルト非公開を積極的に利用する

Rustのモジュールや要素はデフォルトで非公開です。この性質を活用し、意図的に公開する項目を明示的に定義しましょう。

注意点

  • 無意識にpubを多用しないこと。
  • 公開範囲を明示的にドキュメント化することで、チーム間の理解を深める。

3. pub(crate)を活用してモジュール間の共有を管理

ユースケース
pub(crate)を使うことで、クレート内での共有は可能にしながら、外部には非公開にすることができます。

実例

mod utils {
    pub(crate) fn helper() -> String {
        String::from("Helper function result")
    }
}

pub mod api {
    use crate::utils;

    pub fn public_api() -> String {
        utils::helper()
    }
}

この例では、helper関数はapiモジュールからのみ利用可能であり、ライブラリ利用者には隠蔽されています。

4. モジュールの役割を明確に分離

モジュール設計において、役割を明確に分けることでコードの理解が容易になります。

例: 役割分離のモジュール構成

  • core: 内部ロジックを担当
  • utils: 補助関数を提供
  • api: 公開インターフェースを提供

5. アクセス指定子の一貫性を保つ

アクセス指定子のルールが一貫していることは、コードの可読性を向上させます。

おすすめのルール

  • モジュール内部の関数や構造体はデフォルト非公開。
  • モジュール間で共有するものはpub(crate)。
  • 外部利用者向けの機能はpub。

6. 過剰な共有を避ける

コードの再利用性を高めるために共有範囲を広げすぎると、意図しない依存関係が生まれることがあります。モジュール内で完結できるロジックは公開しない方が安全です。

7. ドキュメントを活用

アクセス指定子の設定に伴う設計意図をドキュメント化することで、チーム内での誤解を防ぎます。

例: モジュールドキュメント

/// 内部モジュール: 内部処理をカプセル化
mod internal {
    // 非公開関数
    fn hidden_logic() {}
}

まとめ


アクセス制御のベストプラクティスを守ることで、コードベースの安全性、保守性、再利用性を高めることができます。これらを意識することで、Rustのモジュール設計をより効率的に行うことが可能になります。次は、応用例と演習問題を通じて学びを深めます。

応用例と演習問題

Rustのアクセス指定子を利用したモジュール設計の知識を応用し、実際の課題に取り組むことで理解を深めましょう。このセクションでは、応用例を示した後、読者が自ら取り組める演習問題を提示します。

応用例：タスク管理システム

以下は、タスク管理システムをモジュール設計の観点から構築する例です。この設計では、pub(crate)を活用して内部ロジックを隠蔽しながら、外部にはシンプルなAPIを提供します。

// task モジュール
mod task {
    pub(crate) struct Task {
        pub(crate) title: String,
        completed: bool,
    }

    impl Task {
        pub(crate) fn new(title: &str) -> Self {
            Task {
                title: title.to_string(),
                completed: false,
            }
        }

        pub(crate) fn mark_completed(&mut self) {
            self.completed = true;
        }

        pub(crate) fn is_completed(&self) -> bool {
            self.completed
        }
    }
}

// manager モジュール
mod manager {
    use crate::task::Task;

    pub(crate) struct TaskManager {
        tasks: Vec<Task>,
    }

    impl TaskManager {
        pub(crate) fn new() -> Self {
            TaskManager { tasks: Vec::new() }
        }

        pub(crate) fn add_task(&mut self, title: &str) {
            self.tasks.push(Task::new(title));
        }

        pub(crate) fn complete_task(&mut self, index: usize) {
            if let Some(task) = self.tasks.get_mut(index) {
                task.mark_completed();
            }
        }

        pub(crate) fn list_tasks(&self) {
            for (i, task) in self.tasks.iter().enumerate() {
                let status = if task.is_completed() {
                    "Completed"
                } else {
                    "Pending"
                };
                println!("{}: {} [{}]", i, task.title, status);
            }
        }
    }
}

// api モジュール
pub mod api {
    use crate::manager::TaskManager;

    pub struct PublicAPI {
        manager: TaskManager,
    }

    impl PublicAPI {
        pub fn new() -> Self {
            PublicAPI {
                manager: TaskManager::new(),
            }
        }

        pub fn add_task(&mut self, title: &str) {
            self.manager.add_task(title);
        }

        pub fn complete_task(&mut self, index: usize) {
            self.manager.complete_task(index);
        }

        pub fn list_tasks(&self) {
            self.manager.list_tasks();
        }
    }
}

// メイン関数
fn main() {
    let mut api = api::PublicAPI::new();
    api.add_task("Learn Rust");
    api.add_task("Build a project");
    api.list_tasks();
    api.complete_task(0);
    api.list_tasks();
}

ポイント

  • taskとmanagerモジュールは内部ロジックを提供し、pub(crate)でアクセス制限をかけています。
  • apiモジュールは公開インターフェースを提供し、内部実装を隠蔽しています。

演習問題

以下の課題に取り組んでみましょう。

問題1: 内部ロジックの拡張


タスクに「期限」を追加してください。この「期限」を設定し、期限が過ぎたタスクをリストに表示するときに特別なマーク（例: [Overdue]）を付けるように変更してください。

問題2: APIに新しい機能を追加


タスクの名前を更新するAPI機能を追加してください。この機能は、タスクのインデックスを指定して新しい名前を設定できるものとします。

問題3: モジュールの役割分担を再考


現行の設計を見直し、役割が分散しすぎていないか、または集中しすぎていないかを評価してください。必要に応じてモジュール構成を再編成してみてください。

問題4: テストケースの作成


上記の機能を検証するテストケースをRustの#[test]マクロを使って作成してください。

解答例について


これらの問題の解答例を作成することで、アクセス指定子の理解がさらに深まります。コードを実際に実行して結果を確認してみてください。

まとめ


応用例を参考にしながら演習問題に取り組むことで、Rustのアクセス指定子を利用したモジュール設計の実践力を養うことができます。次はこの記事全体のまとめを行います。

まとめ

本記事では、Rustのアクセス指定子を活用した依存性の低いモジュール設計について、基礎から応用までを解説しました。アクセス指定子の仕組みを理解し、pubやpub(crate)を適切に使うことで、コードの保守性、再利用性、そして安全性を高める方法を学びました。

具体的なモジュール設計の例やデザインパターンとの組み合わせ、チーム開発での注意点、さらに演習問題を通じて、実践的なスキルを身につける機会を提供しました。Rustのモジュール設計を効果的に行うことで、プロジェクトの成功に貢献できるエンジニアリングスキルを強化できます。

引き続きRustの学習を深め、効率的なモジュール設計を実践してみてください！

Rust
モジュール設計 アクセス指定子 Rust

コメント

コメントする

目次