Encapsulation in Rust: Strengthening Code with Privacy and Modules

Introduction

Welcome to the second lesson of the " Clean Coding with Structs and Traits in Rust " course! In our previous session, we explored creating single-responsibility structs, emphasizing focused design for better readability and maintainability. Today, we'll delve into another fundamental principle of clean software design— encapsulation . While encapsulation is a key concept in object-oriented programming, Rust approaches it differently through its powerful module system and ownership model. Understanding Rust's unique take on encapsulation will enhance your ability to build robust and secure systems. Please note: we'll mostly focus on the module system in this lesson; Rust's ownership model will be discussed at a later time.

Why Encapsulation Matters in Rust

Encapsulation in Rust is crucial for enforcing data invariants, ensuring memory safety, and maintaining control over how data is accessed and modified. Rust achieves encapsulation through its module system and visibility modifiers, which govern the accessibility of structs, functions, and other items across different parts of your codebase. Why is encapsulation beneficial? Enforcing Invariants : By restricting direct access to data, you ensure that internal states remain valid and consistent. Think of a bank account—you wouldn't want customers to directly modify their balance; instead, all transactions should go through proper validation and recording procedures. Memory Safety : Encapsulation complements Rust's ownership and borrowing rules, preventing data races and invalid memory access. This is like having a secure vault where only authorized personnel with proper credentials can access sensitive documents, preventing unauthorized duplications or removals. Simplified Maintenance : Hiding implementation details allows for internal changes without affecting external code, as long as the public interface remains consistent. Similar to how car manufacturers can upgrade internal engine components without requiring drivers to learn new ways to operate their vehicles. Preventing Misuse : Limiting access reduces the risk of unintended or malicious modifications to your data. Consider a thermostat system—users interact through a simple interface of temperature controls, while the complex heating and cooling mechanisms remain safely hidden from tampering.

The Risks of Inadequate Encapsulation

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Refactored Example: Proper Encapsulation

Let's refactor the code to demonstrate proper encapsulation by leveraging Rust's module system and visibility modifiers:

Rust

mod library {
    // The Book struct is public, but its fields are private
    pub struct Book {
        title: String,
        author: String,
        price: f64,
    }

    impl Book {
        // Public constructor with validation
        pub fn new(title: &str, author: &str, price: f64) -> Book {
            if price < 0.0 {
                panic!("Price cannot be negative");
            }
            Book {
                title: title.to_string(),
                author: author.to_string(),
                price,
            }
        }

        // Public method to get the price
        pub fn price(&self) -> f64 {
            self.price
        }

        // Public method to set the price with validation
        pub fn set_price(&mut self, price: f64) {
            if price < 0.0 {
                panic!("Price cannot be negative");
            }
            self.price = price;
        }
    }
}

fn main() {
    // Bring the Book struct into scope
    use library::Book;

    // Create a Book instance using the public constructor
    let mut book = Book::new("Clean Code", "Robert C. Martin", 42.0);

    // Update the price using the setter method
    book.set_price(30.0); // Valid update

    // Attempt to directly access a private field (will cause a compile-time error)
    // book.price = -5.0; // Error: field `price` of struct `library::Book` is private
}

mod library {
    // The Book struct is public, but its fields are private
    pub struct Book {
        title: String,
        author: String,
        price: f64,
    }

    impl Book {
        // Public constructor with validation
        pub fn new(title: &str, author: &str, price: f64) -> Book {
            if price < 0.0 {
                panic!("Price cannot be negative");
            }
            Book {
                title: title.to_string(),
                author: author.to_string(),
                price,
            }
        }

        // Public method to get the price
        pub fn price(&self) -> f64 {
            self.price
        }

        // Public method to set the price with validation
        pub fn set_price(&mut self, price: f64) {
            if price < 0.0 {
                panic!("Price cannot be negative");
            }
            self.price = price;
        }
    }
}

fn main() {
    // Bring the Book struct into scope
    use library::Book;

    // Create a Book instance using the public constructor
    let mut book = Book::new("Clean Code", "Robert C. Martin", 42.0);

    // Update the price using the setter method
    book.set_price(30.0); // Valid update

    // Attempt to directly access a private field (will cause a compile-time error)
    // book.price = -5.0; // Error: field `price` of struct `library::Book` is private
}

Let's anaylize the refactored code:

Private Fields: The title, author, and price fields are private by default within the library module since they are not declared pub. This hides the internal state from external code.
Controlled Access Through Methods: Public methods new, price, and set_price provide controlled interaction with the Book's data, enforcing necessary validations.
Enforcing Invariants: The new constructor and set_price method include checks to prevent the price from being negative, maintaining valid states.
Encapsulated Implementation: External code cannot directly access or modify the private fields, preserving data integrity and preventing unintended side effects.

This refactored version demonstrates proper encapsulation by using Rust's module system and visibility modifiers effectively, achieving a design that upholds encapsulation principles and that leads to safer and more robust code.

Introduction

Why Encapsulation Matters in Rust

The Risks of Inadequate Encapsulation

Join the 1M+ learners on CodeSignal

Rust's Module System and Visibility

Bad Example: Improper Use of Access Modifiers

Refactored Example: Proper Encapsulation

Best Practices for Encapsulation in Rust

Summary