MENU
  1. ホーム
  2. Rust
  3. Rustのアクセス指定子を使いこなす：実例で学ぶ効果的な利用法

Rustのアクセス指定子を使いこなす：実例で学ぶ効果的な利用法

Rust

Rustは、安全性と効率性を重視したシステムプログラミング言語として注目されています。その中でも、アクセス指定子はコードの可読性を高め、意図しない動作を防ぐための重要な役割を果たします。適切なアクセス制御を行うことで、モジュールの境界を明確にし、ソフトウェアの設計を強固なものにすることができます。本記事では、Rustのアクセス指定子の基本的な使い方から、具体的なケーススタディを通じて、効果的な利用方法を学びます。これにより、より堅牢でメンテナンス性の高いコードを書くための知識を習得できるでしょう。

目次

アクセス指定子とは？Rustの基本構造


アクセス指定子は、プログラム内でモジュールや構造体などの要素にアクセスできる範囲を制御するための機能です。Rustでは、この仕組みが独特の方式で実装されており、モジュールベースの設計と組み合わせることで高い安全性と柔軟性を提供しています。

Rustにおけるアクセス指定子の種類


Rustでは主に以下のアクセス指定子が用意されています。

  • pub: 公開アクセス。指定された要素をモジュール外から利用可能にします。
  • crate: パッケージ全体で利用可能な範囲を指定します。
  • デフォルト（非公開）: 指定がない場合、要素は定義されたモジュール内でのみアクセス可能です。

アクセス指定子の基本的な使い方


以下のコードは、アクセス指定子の基本的な使い方を示した例です。

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

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

fn main() {
    outer::inner::public_function(); // OK
    // outer::inner::private_function(); // エラー: 非公開の関数にはアクセスできません
}

アクセス指定子の重要性

  • カプセル化の促進: 必要な部分だけを公開することで、モジュールの設計が明確になります。
  • エラーの防止: 意図しないコードの変更や誤用を防ぎます。
  • 可読性の向上: 外部に公開される部分が明確になるため、コード全体の理解が容易になります。

Rustのアクセス指定子を正しく活用することで、安全で効率的なコード構築が可能になります。次のセクションでは、各指定子の詳細とその適用方法について掘り下げます。

`pub`の使い方：公開範囲を制御する

Rustのpub（パブリック）指定子は、モジュールや構造体の要素を外部に公開するために使用されます。デフォルトでは非公開となる要素にpubを付与することで、他のモジュールやクレートからのアクセスを許可できます。

`pub`の基本的な使用例


以下のコードは、pub指定子を使って関数や構造体を公開する基本的な例です。

mod library {
    pub mod utilities {
        pub fn helper_function() {
            println!("This is a public helper function.");
        }

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

fn main() {
    library::utilities::helper_function(); // OK: 公開されている関数
    // library::utilities::private_function(); // エラー: 非公開関数にはアクセス不可
}

構造体の公開


構造体全体を公開する場合はpubを使いますが、フィールドごとに公開範囲を制御することも可能です。

pub struct PublicStruct {
    pub public_field: i32,
    private_field: i32,
}

impl PublicStruct {
    pub fn new(public: i32, private: i32) -> Self {
        PublicStruct {
            public_field: public,
            private_field: private,
        }
    }

    pub fn get_private_field(&self) -> i32 {
        self.private_field
    }
}

上記の例では、構造体PublicStruct全体が公開されていますが、フィールドprivate_fieldは非公開のままです。非公開フィールドには、公開されたメソッドを通じてのみアクセスできます。

モジュール間での`pub`の活用


pubはモジュールの設計において重要な役割を果たします。以下は、モジュール内で定義された関数を外部に公開する例です。

mod outer {
    pub mod inner {
        pub fn greet() {
            println!("Hello from inner module!");
        }
    }
}

fn main() {
    outer::inner::greet(); // OK: モジュール外部からアクセス可能
}

`pub`の利点と注意点

  • 利点: 必要な部分だけを公開することで、モジュールの境界を明確にし、他のコードと安全に連携できます。
  • 注意点: 公開する範囲を広げすぎると、モジュールのカプセル化が崩れ、設計が複雑になる可能性があります。

Rustのpub指定子は、モジュール設計を安全かつ柔軟にするための基本的なツールです。次のセクションでは、crate指定子について詳しく説明します。

`crate`指定子の活用：モジュール間共有の基礎

Rustのcrate指定子は、同じクレート内での共有範囲を制御するために使用されます。これは、公開範囲をクレート全体に限定し、外部クレートからのアクセスを防ぎながら内部モジュール間で共有する際に便利です。

`crate`指定子の概要


Rustでは、要素を公開する範囲を細かく制御するためのアクセス指定子としてcrateが提供されています。

  • crateの役割: クレート全体にアクセスを許可します。外部のクレートやプログラムからはアクセスできません。
  • 使用例: 同じプロジェクト内でのモジュール間通信に便利です。

`crate`の基本的な使用例


以下のコードは、crate指定子を使った基本的な例を示しています。

mod library {
    crate fn internal_function() {
        println!("This function is accessible within the crate.");
    }

    pub mod utilities {
        crate fn helper_function() {
            println!("This is a crate-scoped helper function.");
        }
    }
}

fn main() {
    library::internal_function(); // OK: 同じクレート内からアクセス可能
    library::utilities::helper_function(); // OK: 同じクレート内からアクセス可能
}

この例では、internal_functionとhelper_functionがcrate指定されているため、クレート内であればどこからでもアクセスできますが、外部クレートからはアクセスできません。

`crate`と`pub`の違い

指定子範囲用途
pub全モジュールおよび外部クレートからアクセス可能外部公開が必要な場合に使用
crateクレート内のみアクセス可能内部モジュール間共有で使用

crateは、外部への影響を最小限に抑えつつ、プロジェクト内のモジュール間での再利用性を高めるために有効です。

`crate`の注意点と活用場面

  • 注意点: クレート外部に公開する必要がある要素に対してはcrateではなくpubを使用する必要があります。
  • 活用場面:
  • 内部ロジックの分離: 外部に公開したくないが、複数のモジュール間で再利用したい機能。
  • パッケージ内での設計整理: モジュール間の明確な責任分担を保ちながらアクセスを許可したい場合。

実用例：モジュール間の共有ロジック

mod auth {
    crate fn validate_user(user_id: u32) -> bool {
        user_id == 1001 // ダミーの検証ロジック
    }
}

mod api {
    pub fn login(user_id: u32) {
        if crate::auth::validate_user(user_id) {
            println!("Login successful!");
        } else {
            println!("Invalid user.");
        }
    }
}

fn main() {
    api::login(1001); // OK: クレート内で共有されたvalidate_userが利用される
}

この例では、validate_user関数はcrateスコープに限定されていますが、APIモジュールから呼び出され、クレート全体での内部ロジックとして利用されています。

まとめ


crate指定子は、クレート内のモジュール間で共有するが、外部には公開したくない要素を管理するのに最適です。これにより、プロジェクト内のロジックを整理し、セキュリティと設計の明確性を保つことができます。次のセクションでは、スコープ管理に役立つsuperの使い方について説明します。

子モジュールと`super`の活用：スコープの理解

Rustでは、モジュールの階層構造が設計の柔軟性と再利用性を向上させます。その中でsuperは、親モジュールや兄弟モジュールとの関係を明確にするための便利なアクセス指定子です。スコープ管理を理解することで、モジュール間でのアクセス制御がより直感的に行えます。

`super`の基本的な役割


superは、現在のモジュールの親モジュールを指します。これを使うことで、子モジュールから親モジュール内の要素にアクセスできます。

`super`の基本的な使用例


以下は、superを使用した簡単な例です。

mod parent {
    pub fn parent_function() {
        println!("This is a function in the parent module.");
    }

    pub mod child {
        pub fn child_function() {
            super::parent_function(); // 親モジュールの関数を呼び出す
        }
    }
}

fn main() {
    parent::child::child_function(); // 親モジュールの関数が呼び出される
}

この例では、super::parent_functionを使うことで、子モジュールchildから親モジュールparentの関数にアクセスしています。

兄弟モジュール間のアクセス


兄弟モジュール間でアクセスを行いたい場合も、superを使うことで実現できます。

mod parent {
    pub mod sibling1 {
        pub fn function1() {
            println!("This is sibling1's function.");
        }
    }

    pub mod sibling2 {
        pub fn function2() {
            super::sibling1::function1(); // 兄弟モジュールの関数を呼び出す
        }
    }
}

fn main() {
    parent::sibling2::function2(); // sibling1の関数が呼び出される
}

ここでは、superを使うことでparentを経由し、sibling1の関数にアクセスしています。

`super`を使ったカプセル化と柔軟な設計


superを活用することで、カプセル化されたモジュール構造を保ちながら、親モジュールや兄弟モジュールとの明確な関係を構築できます。

mod app {
    fn init_config() {
        println!("Initializing configuration...");
    }

    pub mod database {
        pub fn connect() {
            super::init_config(); // アプリ全体の設定を初期化
            println!("Connecting to the database...");
        }
    }

    pub mod api {
        pub fn start_server() {
            super::init_config(); // アプリ全体の設定を初期化
            println!("Starting the server...");
        }
    }
}

fn main() {
    app::database::connect();
    app::api::start_server();
}

この例では、init_config関数がappモジュール内でのみ利用可能であり、子モジュールのdatabaseやapiからsuperを通じて再利用されています。

`super`の利点と注意点

  • 利点:
  • 階層構造を活かした再利用性の向上。
  • 親モジュールを基点にした明確なアクセスパス。
  • 注意点:
  • モジュール構造が深くなると、superの多用はコードの可読性を下げる可能性があります。
  • 親モジュール内の要素が非公開の場合、superを使ってもアクセスできません。

まとめ


superは、モジュールの階層構造を活用して親や兄弟モジュールと連携するための強力なツールです。これを適切に活用することで、スコープ管理を明確にし、柔軟で拡張性の高い設計を実現できます。次のセクションでは、アクセス指定子を用いたカプセル化の具体例について解説します。

カプセル化の実例：安全性とデザインの向上

カプセル化は、プログラム設計において、データとその操作を一つのモジュールにまとめ、外部からの直接アクセスを制限する手法です。Rustでは、アクセス指定子を活用して、カプセル化を容易に実現できます。これにより、安全性を向上させつつ、コードの可読性や保守性を高めることが可能です。

カプセル化の基本的な考え方


Rustのカプセル化では、以下を意識します。

  • 非公開フィールド: モジュール内でしかアクセスできないデータを定義する。
  • 公開メソッド: データを操作するためのインターフェースを公開する。

これにより、モジュールの内部構造を隠蔽し、外部コードが直接操作するのを防ぐことができます。

カプセル化の実装例


以下は、Rustでカプセル化を実現する具体的な例です。

mod account {
    pub struct BankAccount {
        account_holder: String,
        balance: f64,
    }

    impl BankAccount {
        // コンストラクタを公開してインスタンス作成を許可
        pub fn new(holder: &str, initial_balance: f64) -> Self {
            BankAccount {
                account_holder: holder.to_string(),
                balance: initial_balance,
            }
        }

        // 残高を取得する公開メソッド
        pub fn get_balance(&self) -> f64 {
            self.balance
        }

        // 預金を行う公開メソッド
        pub fn deposit(&mut self, amount: f64) {
            if amount > 0.0 {
                self.balance += amount;
                println!("Deposited ${:.2}. New balance: ${:.2}.", amount, self.balance);
            } else {
                println!("Invalid deposit amount.");
            }
        }

        // 引き出しを行う公開メソッド
        pub fn withdraw(&mut self, amount: f64) {
            if amount > 0.0 && amount <= self.balance {
                self.balance -= amount;
                println!("Withdrew ${:.2}. Remaining balance: ${:.2}.", amount, self.balance);
            } else {
                println!("Invalid or insufficient funds.");
            }
        }
    }
}

使用例

fn main() {
    let mut my_account = account::BankAccount::new("Alice", 1000.0);

    my_account.deposit(200.0); // OK: 残高に加算
    my_account.withdraw(500.0); // OK: 残高から減算
    println!("Final balance: ${:.2}", my_account.get_balance());

    // my_account.balance = 0.0; // エラー: balanceは非公開
}

この例では、BankAccount構造体のフィールドが非公開であり、外部から直接アクセスできません。代わりに、公開されたメソッドを通じて操作を行います。

カプセル化の利点

  • データ保護: モジュール外部からの意図しないデータの変更を防ぎます。
  • 柔軟性: 内部ロジックを変更しても、外部インターフェースが一定であれば影響を最小限に抑えられます。
  • コードの可読性向上: モジュールが提供する機能と内部実装が明確に分離されます。

カプセル化とエラーハンドリング


以下は、エラー処理を組み込んだカプセル化の例です。

mod user {
    pub struct User {
        username: String,
        age: u8,
    }

    impl User {
        pub fn new(username: &str, age: u8) -> Result<Self, String> {
            if age < 18 {
                Err("Age must be 18 or older.".to_string())
            } else {
                Ok(User {
                    username: username.to_string(),
                    age,
                })
            }
        }

        pub fn get_username(&self) -> &str {
            &self.username
        }
    }
}

fn main() {
    match user::User::new("Alice", 17) {
        Ok(user) => println!("Welcome, {}!", user.get_username()),
        Err(e) => println!("Error: {}", e),
    }
}

ここでは、ユーザー作成時にエラー条件を設け、無効な入力を防いでいます。

まとめ


カプセル化を活用することで、データの保護と設計の柔軟性を高めることができます。Rustのアクセス指定子を適切に利用することで、設計をシンプルで直感的なものにするだけでなく、セキュリティや保守性も向上させることが可能です。次のセクションでは、小規模プロジェクトでのアクセス制御の具体例について説明します。

ケーススタディ1：小規模プロジェクトでのアクセス制御

小規模なプロジェクトでは、モジュール構造が比較的単純であるため、アクセス制御も簡潔かつ明確に設計できます。このセクションでは、シンプルなタスク管理アプリを例に、Rustでのアクセス指定子の使い分けを具体的に示します。

例：タスク管理モジュール


以下のコードは、タスク管理システムを構築する際の基本的なモジュール設計を示しています。

mod task_manager {
    pub struct Task {
        title: String,
        completed: bool,
    }

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

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

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

        pub fn get_title(&self) -> &str {
            &self.title
        }
    }

    pub mod utils {
        pub fn display_task_status(task: &super::Task) {
            if task.is_completed() {
                println!("Task '{}' is completed.", task.get_title());
            } else {
                println!("Task '{}' is not completed.", task.get_title());
            }
        }
    }
}

fn main() {
    let mut task = task_manager::Task::new("Learn Rust");

    task_manager::utils::display_task_status(&task); // 未完了のタスク状態を表示
    task.mark_completed(); // タスクを完了
    task_manager::utils::display_task_status(&task); // 完了したタスク状態を表示
}

コードのポイント

  • pub指定子の利用: Task構造体は公開されていますが、そのフィールドは非公開にしてカプセル化を維持しています。
  • utilsモジュール: ユーティリティ関数をpubとして公開し、外部から利用可能にしています。
  • 親モジュールのアクセス: utilsモジュール内では、親モジュール内の要素（Task構造体）にアクセスするためにスコープを明示しています。

設計上の利点

  • 単純で明確な構造: 小規模プロジェクトでは、機能をモジュール内に適切に分離しながら、必要な要素だけを公開することで設計が明確になります。
  • カプセル化の維持: フィールドを非公開にし、メソッドを通じて操作を行うことで、不適切な外部操作を防ぎます。
  • 再利用性の向上: ユーティリティ関数を公開することで、他の部分で再利用しやすくなります。

改善案と拡張性


この小規模プロジェクトの構造は、以下のように拡張可能です。

  • 新しい機能の追加: 例えば、タスクの優先度や期限を管理するフィールドを追加できます。
  • ユーティリティの拡充: utilsモジュールにフィルタリングやソート機能を追加することで、タスク管理の幅を広げられます。
  • エラーハンドリングの導入: 操作に失敗した場合のエラー処理を組み込むことで、堅牢性を向上させることができます。

まとめ


このケーススタディでは、小規模プロジェクトでのアクセス制御を通じて、シンプルで効果的なモジュール設計の例を示しました。Rustのアクセス指定子を正しく使うことで、カプセル化を維持しながら柔軟性と安全性の高い設計が可能です。次のセクションでは、大規模プロジェクトでのアクセス制御の設計パターンについて解説します。

ケーススタディ2：大規模プロジェクトでの設計パターン

大規模プロジェクトでは、モジュールの数が増え、相互依存関係も複雑になります。このような環境では、アクセス制御を適切に設計することで、保守性と拡張性を高めることが重要です。本セクションでは、大規模プロジェクトでのアクセス指定子の活用方法と、設計パターンを具体例とともに解説します。

例：Eコマースシステム


以下は、複数のモジュールを持つEコマースアプリケーションの設計例です。

mod ecommerce {
    pub mod catalog {
        pub struct Product {
            pub name: String,
            pub price: f64,
        }

        impl Product {
            pub fn new(name: &str, price: f64) -> Self {
                Product {
                    name: name.to_string(),
                    price,
                }
            }
        }
    }

    pub mod orders {
        use super::catalog::Product;

        pub struct Order {
            pub id: u32,
            pub products: Vec<Product>,
        }

        impl Order {
            pub fn new(id: u32) -> Self {
                Order {
                    id,
                    products: Vec::new(),
                }
            }

            pub fn add_product(&mut self, product: Product) {
                self.products.push(product);
            }

            pub fn calculate_total(&self) -> f64 {
                self.products.iter().map(|p| p.price).sum()
            }
        }
    }

    pub mod users {
        pub struct User {
            pub username: String,
            pub email: String,
            pub orders: Vec<super::orders::Order>,
        }

        impl User {
            pub fn new(username: &str, email: &str) -> Self {
                User {
                    username: username.to_string(),
                    email: email.to_string(),
                    orders: Vec::new(),
                }
            }

            pub fn place_order(&mut self, order: super::orders::Order) {
                self.orders.push(order);
            }
        }
    }
}

fn main() {
    use ecommerce::catalog::Product;
    use ecommerce::orders::Order;
    use ecommerce::users::User;

    let mut user = User::new("Alice", "alice@example.com");

    let mut order = Order::new(1);
    let product1 = Product::new("Laptop", 1200.0);
    let product2 = Product::new("Mouse", 25.0);

    order.add_product(product1);
    order.add_product(product2);

    user.place_order(order);

    println!("User: {}", user.username);
    for order in &user.orders {
        println!("Order ID: {}, Total: ${:.2}", order.id, order.calculate_total());
    }
}

コードのポイント

  1. モジュール分割: 各モジュールは独立した責任を持つように設計されています。
  • catalog: 商品データの管理。
  • orders: 注文の管理と計算ロジック。
  • users: ユーザーと注文の紐付け。
  1. pub指定子の活用: モジュール間で必要な要素のみを公開しています。たとえば、ProductやOrderの一部メソッドだけが外部から使用可能です。
  2. 内部ロジックの保護: 非公開のフィールドを使用して、モジュール内のデータ保護を実現しています。

大規模プロジェクトの設計パターン

ドメイン駆動設計（DDD）

  • 各モジュールを明確なドメイン（例えば「商品」「注文」「ユーザー」）に分割します。
  • モジュール間の通信は公開されたインターフェースを通じて行います。

依存関係の管理

  • モジュール間の依存関係を最小限に抑え、循環参照を防ぎます。
  • 明示的なインポートを利用し、コードの可読性を向上させます。

フェーズ分割

  • 初期化、ビジネスロジック、外部APIの呼び出しなど、処理をフェーズごとに分けます。

設計の利点

  • 保守性: 各モジュールが独立しているため、新しい機能を追加しても既存コードへの影響が少なくなります。
  • 拡張性: 例えば、新しい支払いモジュールを追加する際も他のモジュールへの変更を最小限に抑えられます。
  • デバッグの容易さ: 各モジュールが独立しているため、問題の特定が容易です。

まとめ


大規模プロジェクトでは、モジュールの責任範囲を明確にし、アクセス指定子を適切に活用することで、保守性と拡張性を両立した設計が可能です。このケーススタディでは、Rustのモジュールシステムとアクセス制御を活用した具体例を示しました。次のセクションでは、アクセス指定子に関連するよくある間違いとその解決方法について説明します。

よくある間違いと解決策：アクセス指定子の誤用を防ぐ

Rustでアクセス指定子を使う際、適切な設計が行われないと、予期しない動作やメンテナンスの困難さにつながることがあります。このセクションでは、アクセス指定子に関するよくある誤りとその解決策を解説します。

間違い1: `pub`を多用してカプセル化を崩す

問題

すべての要素をpubとして公開すると、モジュール間の境界が曖昧になり、意図しない操作やバグの原因となります。

解決策

  • 最小限の公開: 必要な要素だけを公開し、内部ロジックは非公開にする。
  • モジュール設計の見直し: 再利用性を考慮しつつ、モジュールの責任範囲を明確にする。

例

間違った設計:

pub struct Data {
    pub value: i32,
}

fn main() {
    let mut data = Data { value: 42 };
    data.value = -1; // 意図しない直接変更
}

改善例:

pub struct Data {
    value: i32,
}

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

    pub fn get_value(&self) -> i32 {
        self.value
    }

    pub fn set_value(&mut self, value: i32) {
        if value >= 0 {
            self.value = value;
        }
    }
}

間違い2: 非公開要素にアクセスしようとしてエラーになる

問題

アクセス指定子を理解せずに非公開要素にアクセスしようとすると、コンパイルエラーが発生します。

解決策

  • アクセス範囲の確認: モジュール間で使用する場合、必要に応じて適切なアクセス指定子を設定する。
  • superやcrateの活用: スコープに応じた指定子を正しく使用する。

例

間違った設計:

mod module_a {
    pub struct Item {
        private_value: i32, // デフォルトで非公開
    }
}
fn main() {
    let item = module_a::Item { private_value: 42 }; // エラー
}

改善例:

mod module_a {
    pub struct Item {
        private_value: i32,
    }

    impl Item {
        pub fn new(value: i32) -> Self {
            Item { private_value: value }
        }

        pub fn get_value(&self) -> i32 {
            self.private_value
        }
    }
}

fn main() {
    let item = module_a::Item::new(42);
    println!("Value: {}", item.get_value()); // OK
}

間違い3: `super`の多用による可読性の低下

問題

深いモジュール構造でsuperを多用すると、コードが分かりにくくなる場合があります。

解決策

  • 浅いモジュール設計: 階層を整理し、モジュールの深さを最小限にする。
  • エイリアスを利用: モジュールパスが長くなる場合はエイリアスで簡略化する。

例

間違った設計:

mod parent {
    pub mod child {
        pub mod grandchild {
            pub fn function() {
                super::super::parent_function();
            }
        }

        fn parent_function() {
            println!("Parent function");
        }
    }
}

改善例:

mod parent {
    pub mod child {
        pub fn function() {
            println!("Simplified function call");
        }
    }
}

fn main() {
    parent::child::function(); // シンプルで分かりやすい
}

間違い4: 不要な公開がセキュリティリスクを生む

問題

データや関数を公開しすぎると、セキュリティや設計上の問題が発生する可能性があります。

解決策

  • 内部データの非公開化: 内部でのみ必要な要素は非公開にする。
  • 外部APIの最小化: 公開するメソッドや構造体を最小限に抑える。

例

改善例:

mod auth {
    pub struct Credentials {
        username: String,
        password: String, // 非公開で保護
    }

    impl Credentials {
        pub fn new(username: &str, password: &str) -> Self {
            Credentials {
                username: username.to_string(),
                password: password.to_string(),
            }
        }

        pub fn validate(&self, input_password: &str) -> bool {
            self.password == input_password
        }
    }
}

まとめ


Rustのアクセス指定子は、適切に使用することでコードの安全性と保守性を大幅に向上させます。一方で、誤用すると設計の複雑化やバグの原因となります。本セクションで紹介した典型的な間違いとその解決策を参考に、より安全で効率的なコードを書くことを心がけましょう。次のセクションでは、これまでの内容を総括します。

まとめ

本記事では、Rustにおけるアクセス指定子の基本的な使い方から、実際のプロジェクトでの活用方法、そして設計上のよくある間違いとその解決策までを解説しました。アクセス指定子は、コードの安全性と可読性を高める重要なツールです。

特に、pubやcrateを活用したモジュール間のアクセス制御や、superを利用した親子モジュール間の連携は、プロジェクト設計の基盤となります。また、カプセル化を通じて、データ保護やメンテナンスのしやすいコードを構築する方法を学びました。

Rustのアクセス指定子を正しく理解し、適切に使用することで、シンプルで拡張性の高いプログラムを作成できるようになります。この知識を活用し、安全で堅牢なコードを実現してください。

Rust
プログラミング基礎 アクセス指定子 Rust

コメント

コメントする

目次