Rust中解决可变与不可变借用冲突的设计模式是什么？

问题场景 #

下面是一段Room的Rust实现代码，意图是当Page内容为空时，调用Page的generateContent方法生成内容，但该方法需要依赖Room的信息，代码触发了借用冲突错误：

impl Room {
  pub fn getPageContent(&mut self, bookNumber: u32, pageNumber: u16, alp: &Alphabet) {
    let page = &mut self.books[(bookNumber-1) as usize].pages[(pageNumber-1) as usize];
    if page.text.is_empty() {
      page.generateContent(alp, bookNumber, &self);
    }
  }
}

错误提示：

cannot borrow self as immutable because it is also borrowed as mutable

当前面临的两难处境：

• 若把Room的所需信息逐个传给Page，需要所有信息实现Clone，如果generateContent依赖10种不同信息，会大幅增加工作量和复杂度；
• 若直接在getPageContent中生成内容，会导致所有逻辑集中在Room中，规模化后维护性极差。

规模化解决方案 #

1. 拆分Room的状态与行为（单一职责原则） #

把Page生成内容所需的Room只读数据抽离成单独的RoomContext结构体，该结构体仅包含generateContent需要的不可变数据。调用时只需传递&RoomContext而非整个&Room，从根源上避免借用冲突：

// 抽离只读上下文，仅存放生成内容所需的必要数据
struct RoomContext {
    config: RoomConfig,
    metadata: RoomMetadata,
    // ...其他Page需要的只读信息
}

impl Room {
    // 提供获取上下文的方法，返回不可变引用
    pub fn context(&self) -> &RoomContext {
        &self.context
    }

    pub fn getPageContent(&mut self, bookNumber: u32, pageNumber: u16, alp: &Alphabet) {
        let page = &mut self.books[(bookNumber-1) as usize].pages[(pageNumber-1) as usize];
        if page.text.is_empty() {
            // 传递上下文引用，而非整个Room
            page.generateContent(alp, bookNumber, self.context());
        }
    }
}

impl Page {
    // 现在依赖的是RoomContext而非完整Room
    pub fn generateContent(&mut self, alp: &Alphabet, book_number: u32, context: &RoomContext) {
        // 使用context中的数据生成内容
        self.text = format!("Generated content with config: {}", context.config.key);
    }
}

这种方式既解决了借用问题，又符合单一职责原则，状态拆分后各模块依赖更清晰，规模化时更容易维护和扩展。

2. 使用内部可变性（Interior Mutability） #

如果确实需要在持有Page可变引用的同时访问Room的其他可变数据，可以用RefCell实现内部可变性（仅限单线程场景），但需谨慎使用避免运行时panic：

use std::cell::RefCell;

struct Room {
    books: Vec<Book>,
    // 将Page需要访问的共享数据包装成RefCell
    shared_data: RefCell<RoomSharedData>,
}

impl Room {
    pub fn getPageContent(&mut self, bookNumber: u32, pageNumber: u16, alp: &Alphabet) {
        let page = &mut self.books[(bookNumber-1) as usize].pages[(pageNumber-1) as usize];
        if page.text.is_empty() {
            // 借用shared_data的不可变引用
            let shared = self.shared_data.borrow();
            page.generateContent(alp, bookNumber, &shared);
        }
    }
}

impl Page {
    pub fn generateContent(&mut self, alp: &Alphabet, book_number: u32, shared_data: &RoomSharedData) {
        // 使用shared_data生成内容
    }
}

这种方式适合需要共享可变数据的场景，但规模化应用中要严格控制使用范围，避免滥用导致逻辑混乱。

3. 反转控制（依赖倒置） #

将Page的内容生成逻辑抽象为trait，由Room提供数据而非Page主动从Room获取。通过trait抽象实现逻辑解耦，后续可灵活替换生成逻辑：

// 抽象内容生成逻辑
trait ContentGenerator {
    fn generate_page_content(&self, alp: &Alphabet, book_number: u32) -> String;
}

// Room实现生成器 trait
impl ContentGenerator for Room {
    fn generate_page_content(&self, alp: &Alphabet, book_number: u32) -> String {
        // 这里可以访问Room的所有不可变数据，生成内容
        format!("Page content for book {}: {}", book_number, self.global_setting)
    }
}

impl Room {
    pub fn getPageContent(&mut self, bookNumber: u32, pageNumber: u16, alp: &Alphabet) {
        let page = &mut self.books[(bookNumber-1) as usize].pages[(pageNumber-1) as usize];
        if page.text.is_empty() {
            // 由Room生成内容后赋值给Page
            page.text = self.generate_page_content(alp, bookNumber);
        }
    }
}

这种方式把内容生成逻辑转移到Room的trait实现中，但通过抽象保持了扩展性，规模化时不同类型的Page可以对应不同的ContentGenerator实现，避免逻辑过度集中。

内容的提问来源于stack exchange，提问作者oui