Rust中结构体方法与独立函数的惯用代码组织方式探讨

我时常困惑于在Rust中组织代码时，选择为结构体实现方法（偏面向对象风格）还是使用独立函数处理该结构体（偏数据导向风格）哪种方式更符合惯用规范。由于未找到相关资料，特此请教相关信息与见解。

以下是两种实现方式的简单示例：

方法实现（面向对象风格）： #

struct Merger {
    field1: String,
    field2: String,
}

impl Merger {
    pub fn merge(&self, data_to_merge: Vec<String>) -> String {
        // do stuff...
    }
}

函数实现（数据导向风格）： #

struct MergeConfig {
    field1: String,
    field2: String,
}

fn merge(conf: &MergeConfig, data_to_merge: Vec<String>) -> String {
    // do stuff...
}

我的问题： #

1. 哪种代码组织方式更符合Rust的惯用规范？
2. 若这属于设计选择，两种方式各自的典型适用场景是什么？（似乎两种方式在任何场景下都可行）

回答 #

1. 惯用规范的选择 #

两种方式都是Rust社区认可的惯用写法，没有绝对的"更优"选项，核心取决于代码的语义表达和实际使用场景。Rust本身不强制偏向某一种风格，而是鼓励开发者选择最清晰、最符合直觉的组织方式。

2. 典型适用场景 #

结构体方法（面向对象风格）

• 结构体代表具有专属行为的"实体"时：如果你的结构体是一个拥有自身状态、且操作逻辑与自身状态强绑定的对象（比如示例中的Merger，暗示它是专门负责合并操作的实体），用方法更符合语义。调用时merger.merge(data)的写法直观体现"这个实体执行某个动作"的逻辑。
• 需要封装内部状态或实现 trait 时：方法天然适合隐藏结构体的内部细节，同时如果要实现标准库或自定义trait（如Display、Iterator），必须通过impl块定义方法。
• 操作核心依赖结构体自身状态：如果函数逻辑高度依赖结构体的字段，将其作为方法可以避免每次显式传递结构体引用，代码更简洁。

独立函数（数据导向风格）

• 结构体更偏向"配置/数据容器"时：如果结构体只是单纯承载数据（比如示例中的MergeConfig更像一组配置参数），用独立函数更合适。merge(&config, data)的写法能明确体现"用这份配置处理数据"的逻辑，语义上聚焦于"数据驱动操作"。
• 操作是通用工具，需适配多种类型时：如果逻辑未来可能需要处理其他类似结构的数据，独立函数更容易扩展（比如通过泛型参数支持不同配置结构体），而方法则绑定到特定结构体上。
• 强调无状态的数据处理过程时：当操作本身不突出"实体行为"，而是更像纯数据转换过程，独立函数的写法更符合数据导向思维，让逻辑聚焦于数据流转。

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