哲学——为什么类型分析胜过测试

发表于

一、类型状态模式（Typestate Pattern）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
use std::marker::PhantomData;

struct Disconnected;
struct Connected;

struct Socket<State> {
    fd: i32,
    _state: PhantomData<State>,
}

impl Socket<Disconnected> {
    fn connect(self, addr: &str) -> Socket<Connected> {
        // ... connect logic ...
        Socket { fd: self.fd, _state: PhantomData }
    }
}

impl Socket<Connected> {
    fn send(&mut self, data: &[u8]) { /* ... */ }
    fn disconnect(self) -> Socket<Disconnected> {
        Socket { fd: self.fd, _state: PhantomData }
    }
}

// Socket<Disconnected> has no send() method — compile error if you try

这段代码展示了 Rust 中一种非常高级且强大的设计模式，叫做 Typestate Pattern（类型状态模式）。

它的核心意思是：利用 Rust 的编译检查，确保你永远不会在错误的状态下调用错误的函数。

1.1 直白解释

在普通的编程语言中（比如 C++ 或 Java），你可能会写这样的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
struct Socket {
    is_connected: bool,
    fd: i32,
}

impl Socket {
    fn send(&self, data: &[u8]) {
        if !self.is_connected {
            panic!("还没连接呢！不能发数据！"); // 这种错误只有在程序运行时才会发现
        }
        // ...
    }
}

但在 Rust 代码里，如果你试图在断开连接时调用 send()，程序根本编译不通过。 编译器会直接告诉你：”对不起，Socket<Disconnected> 这个类型没有 send 方法”。

1.2 实现原理

1.2.1 定义不同的状态（标签）

1
2
struct Disconnected; // 状态 A：断开
struct Connected;    // 状态 B：连接

这两个结构体没有任何字段，它们只是”标签”。

1.2.2 让 Socket 携带状态

1
2
3
4
struct Socket<State> {
    fd: i32,
    _state: PhantomData<State>, // 告诉编译器：这个 Socket 现在处于 State 状态
}

PhantomData 就像一个占位符，它不占内存，只在编译阶段起作用，标记当前的 State 是什么。

1.2.3 为不同状态实现不同的方法

这是最关键的地方：方法是分家写的。

  • 只有 Socket<Disconnected> 才有 connect 方法：

    1
    2
    3
    impl Socket<Disconnected> {
        fn connect(self, ...) -> Socket<Connected> { ... }
    }

    注意：connect 会消耗掉原来的自己（self），返回一个全新的类型 Socket<Connected>。

  • 只有 Socket<Connected> 才有 send 和 disconnect 方法：

    1
    2
    3
    4
    impl Socket<Connected> {
        fn send(&mut self, data: &[u8]) { ... }
        fn disconnect(self) -> Socket<Disconnected> { ... }
    }

1.3 代码示例对比

如果你这么写：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
let socket = Socket { fd: 1, _state: PhantomData }; // 默认是 Disconnected

// ❌ 编译报错！
// 编译器会说：Socket<Disconnected> 没定义 send 方法
// 你在写代码阶段就能发现错误，而不是等程序跑起来崩溃
socket.send(b"hello"); 

// ✅ 必须先 connect
let mut connected_socket = socket.connect("127.0.0.1");

// ✅ 现在可以 send 了，因为类型变成了 Socket<Connected>
connected_socket.send(b"hello");

// ❌ 再次报错！
// 一旦调用 disconnect，变量会被消耗，不能再调用 send
let closed_socket = connected_socket.disconnect();
connected_socket.send(b"bye"); // 编译报错：Value used after move

1.4 优势总结

  1. 状态安全：你不可能忘记检查连接状态，因为编译器替你检查了。
  2. 零成本抽象：这些 PhantomData 和泛型状态只存在于编译期，编译出来的机器码里没有任何多余的 if-else 判断，性能极高。
  3. API 指引：开发者在使用你的库时，编辑器只弹出会展示当前状态下可用的方法。如果你没连接，编辑器压根不会提示你 send 方法。

一句话总结：它把”逻辑错误”变成了”语法错误”。

二、通过关联类型确保协议正确性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
use std::io;

trait IpmiCmd {
    type Response;
    fn parse_response(&self, raw: &[u8]) -> io::Result<Self::Response>;
}

// Simplified for illustration — see ch02 for the full trait with
// net_fn(), cmd_byte(), payload(), and parse_response().

struct ReadTemp { sensor_id: u8 }
impl IpmiCmd for ReadTemp {
    type Response = Celsius;
    fn parse_response(&self, raw: &[u8]) -> io::Result<Celsius> {
        Ok(Celsius(raw[0] as i8 as f64))
    }
}


fn execute<C: IpmiCmd>(cmd: &C, raw: &[u8]) -> io::Result<C::Response> {
    cmd.parse_response(raw)
}
// ReadTemp always returns Celsius — can't accidentally get Rpm

这段代码展示了 Rust 中一个非常核心的设计哲学：通过类型系统确保协议正确性（Protocol Correctness），即所谓的”使非法状态不可表达“（Make invalid interactions unrepresentable）。

2.1 核心目标：绑定”请求”与”响应”

在底层协议（如 IPMI、NVMe）中，你发送一个特定的命令（Request），硬件会返回一段二进制数据。传统做法通常是手动解析这些字节，但这容易出错：你可能会不小心用解析”转速”的代码去解析”温度”数据。

这段代码通过 Rust 的 关联类型（Associated Types） 在编译阶段解决了这个问题。

2.2 代码逐段解析

2.2.1 定义 Trait（协议骨架）

1
2
3
4
trait IpmiCmd {
    type Response; // 关联类型：每个命令必须定义它对应的返回类型
    fn parse_response(&self, raw: &[u8]) -> io::Result<Self::Response>;
}
  • type Response; 是关键。它告诉编译器：任何实现了 IpmiCmd 的类型，都必须明确指定它返回什么类型的数据。

2.2.2 具体命令实现

1
2
3
4
5
6
7
8
9
10
struct ReadTemp { sensor_id: u8 }

impl IpmiCmd for ReadTemp {
    type Response = Celsius; // 绑定：ReadTemp 命令只能返回 Celsius 类型

    fn parse_response(&self, raw: &[u8]) -> io::Result<Celsius> {
        // 将原始字节解析为 Celsius 结构体
        Ok(Celsius(raw[0] as i8 as f64))
    }
}
  • 这里将 ReadTemp 结构体与 Celsius（摄氏度）类型硬绑定。
  • 如果你尝试在 parse_response 里返回一个 Rpm（转速）类型，编译器会直接报错。

2.2.3 泛型执行函数

1
2
3
fn execute<C: IpmiCmd>(cmd: &C, raw: &[u8]) -> io::Result<C::Response> {
    cmd.parse_response(raw)
}
  • 这是一个通用的执行函数。它的返回类型是 C::Response。
  • 这意味着：如果你传入的是 ReadTemp，函数返回值的类型在编译时就被确定为 Celsius。

2.3 为什么说这实现了”协议正确性”？

“ReadTemp always returns Celsius — can’t accidentally get Rpm”
（ReadTemp 总是返回 Celsius —— 不会意外地得到 Rpm）

  • 传统方式的风险： 在 C 语言或动态语言中，你可能写出 data = execute(READ_TEMP_CMD); rpm = parse_as_rpm(data); 这样的代码。这在逻辑上是错的，但编译器不会阻止你。
  • Rust 的安全性： 在这段代码的设计下，如果你写 let res: Rpm = execute(&read_temp_cmd, raw);，代码根本无法通过编译。因为 ReadTemp 的 Response 类型是 Celsius，它与 Rpm 类型不匹配。

2.4 硬件层面的实际应用

例子中提到的 IPMI, Redfish, NVMe Admin commands 都是复杂的硬件管理协议。

  • 这些协议有成百上千个命令。
  • 每个命令对应的二进制响应格式都不同。
  • 使用这种模式，可以为每个命令编写一个结构体，并绑定其特有的响应结构体。这样开发者在调用 API 时，类型系统会自动引导他们写出正确的解析逻辑，极大地减少了底层驱动开发中的 Bug。

2.5 总结

这段代码演示了如何利用 Rust 的 Trait 和 Associated Types 来建模复杂的交互协议。它将”运行时的协议逻辑错误”转换成了”编译时的类型错误”，从而保证了程序的绝对健壮性。

核心思想：把”逻辑错误”变成”语法错误”。