SOLID Principles in Rust: Theory and Practice (Advanced Level)

Introduction: SOLID in the World of Rust

SOLID principles are the foundation of flexible and maintainable architecture. However, their implementation in Rust has its own specifics, due to the unique ownership system, traits, and the absence of classical OOP. In this article, we will examine how to apply each of the five principles at an advanced level, using idiomatic Rust. We will not just list the rules, but show how they transform in the context of the type system and borrowing.

This article is intended for developers already familiar with the basics of Rust and SOLID. We will focus on the nuances: how to avoid violating LSP when working with generic types, how ISP affects trait design, and why DIP in Rust often requires the use of trait objects or Box.

1. Single Responsibility Principle (SRP) and Ownership

In Rust, SRP gains an additional dimension due to strict ownership rules. A class (or struct) should have only one reason to change. But how does this relate to the transfer of ownership?

Problem: A struct managing resources and logic

Consider an example where a struct simultaneously manages a file descriptor and parses data. This violates SRP.

use std::fs::File;use std::io::Read;

// ❌ SRP violation: the struct both manages the resource and processes datastruct DataProcessor {    file: File,}

impl DataProcessor {    fn new(path: &str) -> Self {        DataProcessor {            file: File::open(path).unwrap(),        }    }

    fn process(&mut self) -> Vec<u8> {        let mut buffer = Vec::new();        self.file.read_to_end(&mut buffer).unwrap();        // ... complex processing logic        buffer    }}

Solution: Separation through ownership transfer

We separate responsibilities: one struct is responsible for reading, another for processing. Ownership is transferred explicitly.

use std::fs::File;use std::io::Read;

// ✅ First responsibility: file managementstruct FileReader {    file: File,}

impl FileReader {    fn new(path: &str) -> Self {        FileReader {            file: File::open(path).unwrap(),        }    }

    fn read(self) -> Vec<u8> {        let mut buffer = Vec::new();        // self.file is consumed (moved), as it is not needed after reading        self.file.read_to_end(&mut buffer).unwrap();        buffer    }}

// ✅ Second responsibility: data processingstruct DataProcessor {    data: Vec<u8>,}

impl DataProcessor {    fn new(data: Vec<u8>) -> Self {        DataProcessor { data }    }

    fn process(&self) -> Vec<u8> {        // Immutable processing        self.data.iter().map(|&b| b + 1).collect()    }}

fn main() {    let reader = FileReader::new("data.bin");    let raw_data = reader.read(); // reader is no longer available    let processor = DataProcessor::new(raw_data);    let result = processor.process();}

The key point: we used self (ownership) instead of &self in read() to explicitly indicate that FileReader is no longer needed after reading. This makes the data flow transparent and prevents resource leaks.

2. Open/Closed Principle (OCP) and Traits

OCP states: entities should be open for extension but closed for modification. In Rust, this is ideally implemented through traits and generics without using virtual tables (vtable), if not required.

Advanced example: Zero-cost strategy

Suppose we have a logging system. Instead of modifying the application core for each new backend, we use polymorphism through traits.

/