Addressing the "Large Struct" Code Smell by Extracting Into Focused Structs

Introduction and Context Setting

In this final lesson, we focus on addressing a prevalent code smell: the "Large Struct." Throughout our course on refactoring with confidence, we've explored various refactoring patterns, using the TDD cycle of Red, Green, Refactor to guide our improvements. Code smells like large structs indicate areas in need of refinement, as they often manage multiple responsibilities, making the code harder to maintain and understand. By applying the Extract Struct refactoring pattern, we can break down these unwieldy structs into smaller, more focused entities. This approach not only enhances code readability but also improves maintainability. Let's use our knowledge of TDD and refactoring patterns to tackle large structs effectively.

Understanding the "Large Struct" Smell and Its Challenges

The "Large Struct" smell is a common indicator of potential issues in code organization and design. This code smell emerges when a struct accumulates too many responsibilities, becoming excessively large and complex. As a result, such structs often exhibit several problems: Reduced Maintainability : With multiple responsibilities crammed into a single struct, understanding and managing the code become cumbersome for developers. Changes in one part of the struct can inadvertently affect other parts, leading to unintended side effects. Poor Readability : Large structs are often difficult to read and comprehend due to the sheer volume of code. This complexity makes it hard for developers to quickly grasp the struct's purpose and logic. Violation of Single Responsibility Principle : The Single Responsibility Principle states that a struct should only have one responsibility or focus. Large structs inherently violate this principle by handling multiple concerns, increasing the risk of bugs and making testing more challenging. Challenges in Testing : Testing large structs is often complicated because they have broad scopes with interdependent behaviors. Unit tests can become sprawling and difficult to isolate, reducing their effectiveness. Addressing the "Large Struct" smell through refactoring not only resolves these challenges but also aligns with best practices in software design. By utilizing the Extract Struct refactoring pattern, we can enhance the separation of concerns, making our codebase more robust, understandable, and easier to test.

Join the 1M+ learners on CodeSignal

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

Applying the Single Responsibility Principle and Steps for Identifying and Extracting Responsibilities in Large Structs

The Single Responsibility Principle (SRP) is a fundamental design guideline that suggests a struct should have only one reason to change, focusing on a single responsibility or functionality. When applied to refactoring large structs, SRP guides the breakdown of complex code structures into simpler components. Here's how to apply SRP alongside steps for identifying and extracting responsibilities in large structs:

Identify Responsibility Segments:
Begin by analyzing the large struct to identify groups of functions and fields that share a cohesive purpose. For example, in a ShoppingCart struct, you might find functions for item management, pricing, discount calculations, and shipping calculations. These responsibilities can be grouped and separated into focused structs.
- For instance, functions related to adding, removing, and updating items can be isolated for item management.
Define Cohesive Units and New Structs:
For each responsibility identified, think of them as potential smaller units or structs that encapsulate a single aspect of behavior. Create new structs that each encapsulate a distinct responsibility and name them according to their roles. This makes each struct's purpose clear and keeps the original struct streamlined.
- For ShoppingCart, you might create structs like:
  - CartItemCollection for managing items in the cart.
  - PriceCalculator for handling pricing logic.
  - DiscountCalculator for applying discount codes.

Move Fields and Functions:
Migrate related fields and functions to their respective new structs. Ensure that each new struct only contains functions and data relevant to its specific responsibility.

In ShoppingCart, move item-related functions, such as add_item, remove_item, and update_item_quantity, into CartItemCollection.

Rust

struct CartItem {
    id: u32,
    name: String,
    price: f64,
    quantity: u32,
}

// Manages a collection of cart items and related operations
struct CartItemCollection {
    items: Vec<CartItem>,
}

impl CartItemCollection {
    // Adds a new item to the collection
    fn add_item(&mut self, item: CartItem) {
        self.items.push(item);
    }

    // Removes an item by its ID
    fn remove_item(&mut self, item_id: u32) {
        self.items.retain(|item| item.id != item_id);
    }

    // Updates the quantity of a specific item
    fn update_item_quantity(&mut self, item_id: u32, quantity: u32) {
        if let Some(item) = self.items.iter_mut().find(|item| item.id == item_id) {
            item.quantity = quantity;
        }
    }
}

struct CartItem {
    id: u32,
    name: String,
    price: f64,
    quantity: u32,
}

// Manages a collection of cart items and related operations
struct CartItemCollection {
    items: Vec<CartItem>,
}

impl CartItemCollection {
    // Adds a new item to the collection
    fn add_item(&mut self, item: CartItem) {
        self.items.push(item);
    }

    // Removes an item by its ID
    fn remove_item(&mut self, item_id: u32) {
        self.items.retain(|item| item.id != item_id);
    }

    // Updates the quantity of a specific item
    fn update_item_quantity(&mut self, item_id: u32, quantity: u32) {
        if let Some(item) = self.items.iter_mut().find(|item| item.id == item_id) {
            item.quantity = quantity;
        }
    }
}

Refactor Calls and Update Dependencies:
Modify the original struct to use instances of the new structs, replacing direct calls to functions that have been moved.

For instance, ShoppingCart should now call PriceCalculator for pricing calculations, reducing its own complexity.

Rust

// Handles price calculation logic for a set of items
struct PriceCalculator;

impl PriceCalculator {
    // Calculates the total price for all items
    fn calculate_price(&self, items: &[CartItem]) -> f64 {
        items.iter().map(|item| item.price * item.quantity as f64).sum()
    }
}

// ShoppingCart now delegates responsibilities to focused structs
struct ShoppingCart {
    items: CartItemCollection,
    price_calculator: PriceCalculator,
}

impl ShoppingCart {
    // Adds an item to the cart via CartItemCollection
    fn add_item(&mut self, item: CartItem) {
        self.items.add_item(item);
    }

    // Calculates total price using PriceCalculator
    fn total_price(&self) -> f64 {
        self.price_calculator.calculate_price(&self.items.items)
    }
}

// Handles price calculation logic for a set of items
struct PriceCalculator;

impl PriceCalculator {
    // Calculates the total price for all items
    fn calculate_price(&self, items: &[CartItem]) -> f64 {
        items.iter().map(|item| item.price * item.quantity as f64).sum()
    }
}

// ShoppingCart now delegates responsibilities to focused structs
struct ShoppingCart {
    items: CartItemCollection,
    price_calculator: PriceCalculator,
}

impl ShoppingCart {
    // Adds an item to the cart via CartItemCollection
    fn add_item(&mut self, item: CartItem) {
        self.items.add_item(item);
    }

    // Calculates total price using PriceCalculator
    fn total_price(&self) -> f64 {
        self.price_calculator.calculate_price(&self.items.items)
    }
}

Reassess, Test, and Ensure SRP Compliance:
Once the refactoring is complete, reassess the code to confirm that the original large struct adheres to the SRP and no longer contains multiple responsibilities. Test as you refactor to confirm behavior remains consistent. Testing each struct individually ensures isolated responsibilities are correctly implemented.

Rust

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add_and_remove_item() {
        let mut cart = CartItemCollection { items: Vec::new() };
        let item = CartItem { id: 1, name: "Book".to_string(), price: 10.0, quantity: 1 };

        cart.add_item(item);
        assert_eq!(cart.items.len(), 1);

        cart.remove_item(1);
        assert_eq!(cart.items.len(), 0);
    }

    #[test]
    fn test_calculate_total_price() {
        let mut cart = CartItemCollection { items: Vec::new() };
        let price_calculator = PriceCalculator;

        cart.add_item(CartItem { id: 1, name: "Book".to_string(), price: 10.0, quantity: 2 });
        cart.add_item(CartItem { id: 2, name: "Pen".to_string(), price: 5.0, quantity: 3 });

        let total = price_calculator.calculate_price(&cart.items);
        assert_eq!(total, 35.0);
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add_and_remove_item() {
        let mut cart = CartItemCollection { items: Vec::new() };
        let item = CartItem { id: 1, name: "Book".to_string(), price: 10.0, quantity: 1 };

        cart.add_item(item);
        assert_eq!(cart.items.len(), 1);

        cart.remove_item(1);
        assert_eq!(cart.items.len(), 0);
    }

    #[test]
    fn test_calculate_total_price() {
        let mut cart = CartItemCollection { items: Vec::new() };
        let price_calculator = PriceCalculator;

        cart.add_item(CartItem { id: 1, name: "Book".to_string(), price: 10.0, quantity: 2 });
        cart.add_item(CartItem { id: 2, name: "Pen".to_string(), price: 5.0, quantity: 3 });

        let total = price_calculator.calculate_price(&cart.items);
        assert_eq!(total, 35.0);
    }
}

By employing these steps and principles, you achieve enhanced separation of concerns, improving the readability and maintainability of the codebase, and ensuring functionality remains correct.

Introduction and Context Setting

Understanding the "Large Struct" Smell and Its Challenges

Join the 1M+ learners on CodeSignal

Recognizing a Large Struct and Common Anti-Patterns

Applying the Single Responsibility Principle and Steps for Identifying and Extracting Responsibilities in Large Structs

Summary and Conclusion