Rust trait对象类型处理：非泛型场景下的优雅惯用法实现咨询

现有写法的合理性 #

你目前的写法本身就是符合Rust惯用法的标准实现。你需要Test结构体不带泛型、运行时根据配置选择不同的Source实现，这种需求天然需要用动态分发的trait对象来处理，而用枚举承载所有可能的Message类型，也是处理有限类型集合统一返回的常规操作，你觉得奇怪大概率是还不习惯这种「枚举做统一类型承载 + trait对象做动态分发」的组合模式。

优化方案 #

根据你的业务场景可以选两种优化方向：

方案1：保留现有架构，做小范围优化

如果你的消息类型、Source类型未来不会频繁新增，完全可以保留现有写法，只做代码精简：

• 抽离重复的Message匹配逻辑，给Message枚举实现公共方法，避免多处写重复的match：

impl Message {
    fn to_formatted_str(&self) -> String {
        match self {
            Message::MessageTypeA(a) => format!("a is {:?}", a),
            Message::MessageTypeB(b) => format!("b is {:?}", b),
        }
    }
}

修改后do_sth和do_sth_else可以直接调用该方法，代码更简洁：

fn do_sth(&mut self) -> String {
    self.source.next().to_formatted_str()
}

fn do_sth_else(&mut self, message: Message) -> String {
    message.to_formatted_str()
}

• 把Config到Source的映射逻辑抽离到Config的实现中，降低Test和Source实现的耦合。

方案2：消息也用trait对象，支持灵活扩展

如果未来需要频繁新增消息类型，不想每次新增都修改Message枚举，可以把Message也抽象为trait，返回trait对象：

trait Message: std::fmt::Debug {
    fn to_formatted_str(&self) -> String;
    // 其他所有消息需要提供的公共方法都在这里定义
}

struct MessageA(i32);
impl Message for MessageA {
    fn to_formatted_str(&self) -> String {
        format!("a is {:?}", self.0)
    }
}

struct MessageB(f32);
impl Message for MessageB {
    fn to_formatted_str(&self) -> String {
        format!("b is {:?}", self.0)
    }
}

// 对应修改Source trait的返回值
trait Source {
    fn next(&mut self) -> Box<dyn Message>;
}

这种方案的优势是新增消息/Source类型不需要修改现有枚举定义，扩展性更强；劣势是如果需要访问消息的独有字段，需要借助Any trait做向下转型，使用成本比枚举匹配高，适合所有消息的公共行为可以完全封装在Message trait中的场景。

补充说明 #

你之前尝试的关联类型、泛型方案都是编译期单态化的实现，无法满足你「运行时确定类型、Test结构体不带泛型」的需求，没有更特殊的替代实现，动态分发trait对象就是该场景下的最优解。

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