Rust 基础（六）

我们将讨论Send 和Sync 特性以及如何在自定义类型中使用它们。

16.4 具有Sync 和 Send特性的可扩展并发

有趣的是，Rust语言只有很少的并发特性。到目前为止，我们在本章中讨论的几乎所有并发特性都是标准库的一部分，而不是语言的一部分。处理并发性的选项不局限于语言或标准库;您可以编写自己的并发特性，也可以使用其他人编写的并发特性。

然而，该语言中嵌入了两个并发概念:std::marker traits Sync和Send。

16.4.1 使用Send允许在线程之间转移所有权

Send标记特征 (marker trait )表明实现Send的类型的值的所有权可以在线程之间转移。几乎每个Rust类型都是Send，但也有一些例外，包括Rc:这不能被Send，因为如果您克隆了一个Rc值并试图将克隆的所有权转移到另一个线程，两个线程可能同时更新引用计数。因此，Rc被实现为在单线程情况下使用，在这种情况下，您不希望付出线程安全性能损失。

因此，Rust的类型系统和trait边界确保您永远不会不安全地跨线程发送Rc值。当我们在示例16-14中尝试这样做时，我们得到了the trait Send is not implemented for Rc>。当我们切换到Arc(即Send)时，代码编译完成。

任何完全由Send类型组成的类型也会自动标记为Send。除了我们将在第19章讨论的原始指针外，几乎所有的原始类型都是Send。

16.4.2 使用Sync 允许多线程访问

Sync标记特征表明，从多个线程引用实现Sync的类型是安全的。换句话说，如果&T(对T的不可变引用)是Send，则任何类型T都是Sync，这意味着引用可以安全地发送到另一个线程。与Send类似，基本类型是Sync，完全由Sync类型组成的类型也是Sync。

智能指针Rc也不是Sync的原因与它不是Send的原因相同。RefCell类型(我们在第15章讨论过)和相关的Cell类型家族是不Sync的。RefCell在运行时执行的借用检查的实现不是线程安全的。智能指针Mutex是Sync的，可以用于与多个线程共享访问，正如您在“在多个线程之间共享互斥锁”一节中看到的。

16.4.3 手动实现Sync 和 Send是不安全的

因为由Sync 和 Send特征组成的类型也会自动Sync 和 Send，所以我们不需要手动实现这些特征。作为标记特征，它们甚至没有任何方法来实现。它们只是用于强制执行与并发性相关的不变量。

手动实现这些特性需要实现不安全的Rust代码。我们将在第19章中讨论使用不安全的Rust代码;就目前而言，重要的信息是，构建不由发送和同步部分组成的新并发类型需要仔细考虑以维护安全保证。“Rustonomicon”有更多关于这些保证以及如何维护它们的信息。

十七、Rust的面向对象编程特性

面向对象编程(Object-oriented programming，OOP)是一种对程序建模的方法。对象作为一个编程概念在20世纪60年代的编程语言Simula中被引入。这些对象影响了Alan Kay的编程体系结构，在该体系结构中，对象之间传递消息。为了描述这种体系结构，他在1967年创造了术语面向对象编程。许多相互竞争的定义描述了什么是OOP，根据其中一些定义，Rust是面向对象的，但另一些则不是。在本章中，我们将探讨一些通常被认为是面向对象的特征，以及这些特征如何转化为惯用的Rust。然后，我们将向您展示如何在Rust中实现面向对象的设计模式，并讨论这样做与使用Rust的一些优点来实现解决方案之间的权衡。

17.1 面向对象语言的特点

对于一门语言必须具有哪些面向对象的特性，编程界没有达成共识。Rust受到许多编程范式的影响，包括面向对象编程;例如，我们在第13章探讨了函数式编程的特性。可以说，OOP语言具有某些共同的特征，即对象、封装和继承（objects, encapsulation, and inheritance）。让我们看看每个特征的含义，以及Rust是否支持这些特征。

17.1.1 对象包含数据和行为

由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides (Addison-Wesley Professional, 1994)所著的《设计模式:可重用的面向对象软件的元素》，通俗地称为“he Gang of Four ”书，是面向对象设计模式的目录。它是这样定义OOP的:

面向对象程序由对象组成。对象既打包了数据，也打包了对数据进行操作的过程。过程通常称为方法或操作。

使用这个定义，Rust是面向对象的:结构和枚举有数据，而impl块提供结构和枚举的方法。即使结构和带有方法的枚举不称为对象，但根据 Gang of Four 对对象的定义，它们提供了相同的功能。

17.1.2 隐藏实现细节的封装

与OOP通常相关的另一个方面是封装（encapsulation），这意味着使用该对象的代码无法访问对象的实现细节。因此，与对象交互的唯一方法是通过它的公共API;使用对象的代码不应该能够进入对象的内部并直接更改数据或行为。这使程序员可以更改和重构对象的内部结构，而不需要更改使用对象的代码。

我们在第7章讨论了如何控制封装:我们可以使用pub关键字来决定代码中的哪些模块、类型、函数和方法应该是公共的，默认情况下其他的都是私有的。例如，我们可以定义一个结构AveragedCollection，它的字段包含i32个值的向量。该结构还可以有一个字段，其中包含向量中值的平均值，这意味着平均值不必在任何人需要它时按需计算。换句话说，AveragedCollection将为我们缓存计算的平均值。示例17-1给出了AveragedCollection结构的定义:
17-1

pub struct AveragedCollection {
    list: Vec<i32>,
    average: f64,
}
1
2
3
4

该结构被标记为pub，以便其他代码可以使用它，但结构中的字段保持私有。这在本例中很重要，因为我们希望确保每当从列表中添加或删除一个值时，平均值也会更新。我们通过在结构上实现add、remove和average方法来实现这一点，如示例17-2所示:
17-2

pub struct AveragedCollection {
    list: Vec<i32>,
    average: f64,
}

impl AveragedCollection {
    pub fn add(&mut self, value: i32) {
        self.list.push(value);
        self.update_average();
    }

    pub fn remove(&mut self) -> Option<i32> {
        let result = self.list.pop();
        match result {
            Some(value) => {
                self.update_average();
                Some(value)
            }
            None => None,
        }
    }

    pub fn average(&self) -> f64 {
        self.average
    }

    fn update_average(&mut self) {
        let total: i32 = self.list.iter().sum();
        self.average = total as f64 / self.list.len() as f64;
    }
}
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
26
27
28
29
30
31

公共方法add、remove和average是访问或修改AveragedCollection实例中的数据的惟一方法。当使用add方法将项添加到list 或使用remove方法删除项时，每个项的实现都调用私有update_average方法，该方法也处理平均字段的更新。

我们将list 和average字段保留为私有，因此外部代码无法直接向列表字段添加或删除项;否则，当list 更改时，平均字段可能会不同步。average方法返回平均值字段中的值，允许外部代码读取平均值但不修改它。

因为我们封装了结构AveragedCollection的实现细节，所以将来可以很容易地更改方面，比如数据结构。例如，对于list 字段，我们可以使用HashSet而不是Vec。只要add、remove和average公共方法的签名保持不变，使用AveragedCollection的代码就不需要更改。如果我们将list设为public，情况就不一定是这样了:HashSet和Vec有不同的添加和删除项的方法，因此如果要直接修改list，外部代码可能必须更改。

如果封装是一门语言被视为面向对象所必需的方面，那么Rust满足了这一要求。对代码的不同部分使用pub或不使用pub的选项支持对实现细节的封装。

17.1.3 继承，作为类型系统和代码共享

继承是一种机制，通过这种机制，一个对象可以从另一个对象的定义中继承元素，从而获得父对象的数据和行为，而不必重新定义它们。

如果一种语言必须具有继承才能成为面向对象语言，那么Rust就不是。如果不使用宏，就无法定义继承父结构的字段和方法实现的结构。

然而，如果您习惯于在编程工具箱中使用继承，则可以在Rust中使用其他解决方案，这取决于您最初获得继承的原因。

选择继承主要有两个原因。一个是代码的重用:您可以为一种类型实现特定的行为，继承使您能够为另一种类型重用该实现。您可以在Rust代码中使用默认特征方法实现以有限的方式做到这一点，您可以在示例10-14中看到这一点，当时我们在Summarytrait上添加了summarize方法的默认实现。任何实现Summarytrait的类型都可以在其上使用summarize方法，而不需要任何进一步的代码。这类似于父类具有方法的实现，继承子类也具有方法的实现。我们还可以在实现Summarytrait时覆盖summarize方法的默认实现，这类似于子类覆盖从父类继承的方法的实现。

使用继承的另一个原因与类型系统有关:允许在与父类型相同的位置使用子类型。这也称为多态性(polymorphism)，这意味着如果多个对象共享某些特征，则可以在运行时相互替换它们。

多态性

对许多人来说，多态性就是继承的同义词。但它实际上是一个更通用的概念，指的是可以处理多种类型数据的代码。对于继承，这些类型通常是子类。

Rust反而使用泛型来抽象不同的可能类型和 trait bounds，从而对这些类型必须提供的内容施加约束。这有时称为有界参数多态性( bounded parametric polymorphism)。

在许多编程语言中，继承作为一种编程设计解决方案最近已不再受欢迎，因为它常常存在共享过多代码的风险。子类不应该总是共享父类的所有特征，但可以通过继承来实现。这可能会降低程序设计的灵活性。它还引入了在子类上调用方法的可能性，这些方法没有意义，或者因为方法不应用于子类而导致错误。此外，有些语言只允许单继承(意味着一个子类只能从一个类继承)，这进一步限制了程序设计的灵活性。

出于这些原因，Rust采用了使用特征对象而不是继承的不同方法。让我们看看trait对象(trait objects )如何在Rust中启用多态性。

17.2 使用Trait对象允许不同类型值的

在第8章中，我们提到了向量的一个限制是它们只能存储一种类型的元素。我们在示例8-9中创建了一个变通方法，其中定义了一个SpreadsheetCell枚举，其中包含用于保存整数、浮点数和文本的变量。这意味着我们可以在每个单元格中存储不同类型的数据，并且仍然有一个表示一行单元格的向量。当可交换项是编译代码时知道的固定类型集时，这是一个非常好的解决方案。

但是，有时我们希望库用户能够扩展在特定情况下有效的类型集。为了演示如何实现这一点，我们将创建一个示例图形用户界面(GUI)工具，该工具遍历项目列表，对每个项目调用一个draw方法将其绘制到屏幕上——这是GUI工具的一种常见技术。我们将创建一个名为gui的库 crate，其中包含gui库的结构。这个crate可能包括一些供人们使用的类型，例如Button或TextField。此外，gui用户希望创建自己的可绘制类型:例如，一个程序员可能添加一个Image，另一个可能添加一个SelectBox。

我们不会为这个示例实现一个完整的GUI库，但将展示如何将各个部分组合在一起。在编写库时，我们不可能知道和定义其他程序员可能想要创建的所有类型。但是我们知道gui需要跟踪许多不同类型的值，并且它需要对每个不同类型的值调用一个draw方法。它不需要知道当我们调用draw方法时会发生什么，只需要知道值会有那个方法可供我们调用。

要在具有继承的语言中做到这一点，我们可以定义一个名为Component的类，该类上有一个名为draw的方法。其他类，如Button、Image和SelectBox，将继承自Component，因此继承了绘制方法。它们都可以覆盖draw方法来定义它们的自定义行为，但框架可以将所有类型视为组件实例，并对它们调用draw。但是因为Rust没有继承，我们需要另一种方式来构造gui库，以允许用户使用新类型来扩展它。

17.2.1 使用 Trait定义共同行为

为了实现我们希望gui拥有的行为，我们将定义一个名为Draw的trait，它将有一个名为draw的方法。然后我们可以定义一个带有trait对象的向量。trait对象既指向实现我们指定trait的类型实例，又指向用于在运行时查找该类型的trait方法的表。我们通过指定某种类型的指针来创建trait对象，例如&引用或Box智能指针，然后是dyn关键字，然后指定相关的trait。(我们将在第19章“Dynamically Sized Types and the Sized Trait.”一节中讨论trait对象必须使用指针的原因)我们可以使用trait对象来代替泛型或具体类型。无论我们在哪里使用trait对象，Rust的类型系统都将在编译时确保在该上下文中使用的任何值都将实现trait对象的trait。因此，我们不需要在编译时知道所有可能的类型。

我们已经提到过，在Rust中，我们避免将结构和枚举称为“对象”，以将它们与其他语言的对象区分开来。在结构或枚举中，结构字段中的数据和impl块中的行为是分离的，而在其他语言中，数据和行为组合成一个概念通常被标记为对象。然而**，trait对象更像其他语言中的对象，因为它们结合了数据和行为。但特征对象与传统对象的不同之处在于，我们不能向特征对象添加数据**。Trait对象并不像其他语言中的对象那样普遍有用:它们的特定目的是允许跨公共行为进行抽象。

示例17-3展示了如何定义:一个叫做Draw的trait，它有一个叫做draw的方法:
17-3

pub trait Draw {
    fn draw(&self);
}
1
2
3

这种语法应该与我们在第10章中关于如何定义trait的讨论很相似。接下来是一些新的语法:示例17-4定义了一个名为Screen的结构体，它保存了一个名为components的向量。这个向量的类型是Box，这是一个trait对象;它是Box中实现了Draw特性的任何类型的替身。
17-4

pub struct Screen {
    pub components: Vec<Box<dyn Draw>>,
}
1
2
3

在Screen结构体上，我们将定义一个名为run的方法，它将在每个组件上调用draw方法，如示例17-5所示:
17-5

pub trait Draw {
    fn draw(&self);
}

pub struct Screen {
    pub components: Vec<Box<dyn Draw>>,
}

impl Screen {
    pub fn run(&self) {
        for component in self.components.iter() {
            component.draw();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

这与定义使用带 trait bounds的泛型类型参数的结构不同。泛型类型参数一次只能用一个具体类型替换，而特征对象允许在运行时为特征对象填充多个具体类型。例如，我们可以使用泛型类型和 trait bounds来定义Screen结构，如示例17-6所示:

pub trait Draw {
    fn draw(&self);
}

pub struct Screen<T: Draw> {
    pub components: Vec<T>,
}

impl<T> Screen<T>
where
    T: Draw,
{
    pub fn run(&self) {
        for component in self.components.iter() {
            component.draw();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

这将我们限制在一个Screen实例中，该实例具有所有类型为Button或全部类型为TextField的组件列表。如果您只使用同构集合，那么使用泛型和trait边界是更好的选择，因为定义将在编译时进行单一化，以使用具体的类型。

另一方面，通过使用trait对象的方法，一个Screen实例可以保存Vec，其中包含Box和Box。让我们看看这是如何工作的，然后讨论运行时性能影响。

17.2.2 实现 trait

现在我们将添加一些实现Draw特性的类型。我们将提供Button类型。同样，实际实现GUI库超出了本书的范围，因此draw方法在其主体中没有任何有用的实现。为了想象实现的样子，Button结构体可能有width, height 和 label字段，如示例17-7所示:
17-7

pub struct Button {
    pub width: u32,
    pub height: u32,
    pub label: String,
}

impl Draw for Button {
    fn draw(&self) {
        // code to actually draw a button
    }
}
1
2
3
4
5
6
7
8
9
10
11

Button上的width, height 和 label字段将不同于其他组件上的字段;例如，TextField类型可能有相同的字段加上一个placeholder字段。我们想要在屏幕上绘制的每个类型都将实现Drawtrait ，但将在draw方法中使用不同的代码来定义如何绘制特定的类型，就像Button在这里所做的那样(如前所述，没有实际的GUI代码)。例如，Button类型可能有一个附加的impl块，其中包含与用户单击按钮时发生的事情相关的方法。这类方法不适用于TextField之类的类型。

如果使用我们库的人决定实现一个具有width, height 和 label字段的SelectBox结构体，他们也会在SelectBox类型上实现Drawtrait ，如示例17-8所示:

use gui::Draw;

struct SelectBox {
    width: u32,
    height: u32,
    options: Vec<String>,
}

impl Draw for SelectBox {
    fn draw(&self) {
        // code to actually draw a select box
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

库的用户现在可以编写他们的main函数来创建Screen实例。对于Screen实例，他们可以添加一个SelectBox和一个Button，将它们放在Box中以成为一个trait对象。然后，它们可以调用Screen实例上的run方法，该方法将调用每个组件上的draw。示例17-9显示了这个实现:

use gui::Draw;

struct SelectBox {
    width: u32,
    height: u32,
    options: Vec<String>,
}

impl Draw for SelectBox {
    fn draw(&self) {
        // code to actually draw a select box
    }
}

use gui::{Button, Screen};

fn main() {
    let screen = Screen {
        components: vec![
            Box::new(SelectBox {
                width: 75,
                height: 10,
                options: vec![
                    String::from("Yes"),
                    String::from("Maybe"),
                    String::from("No"),
                ],
            }),
            Box::new(Button {
                width: 50,
                height: 10,
                label: String::from("OK"),
            }),
        ],
    };

    screen.run();
}
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
26
27
28
29
30
31
32
33
34
35
36
37
38

当我们编写库时，我们不知道有人可能会添加SelectBox类型，但我们的Screen实现能够操作新类型并绘制它，因为SelectBox实现了draw特性，这意味着它实现了绘制方法。

这个概念——只关心值响应的消息而不关心值的具体类型——类似于动态类型语言中的鸭子类型(duck typing )的概念:如果它像鸭子一样走路，像鸭子一样嘎嘎叫，那么它一定是一只鸭子!在示例17-5中 Screen中run 的实现中，run不需要知道每个组件的具体类型。它不检查组件是否是Button或SelectBox的实例，它只是调用组件上的draw方法。通过指定Box作为components向量中的值的类型，我们已经定义Screen需要可以调用draw 方法的值。

使用trait对象和Rust的类型系统来编写类似于duck类型的代码的好处是，我们不必在运行时检查一个值是否实现了一个特定的方法，也不必担心如果一个值没有实现一个方法但我们仍然调用它会出错。如果值没有实现特征对象需要的特征，Rust就不会编译我们的代码。

use gui::Screen;

fn main() {
    let screen = Screen {
        components: vec![Box::new(String::from("Hi"))],
    };

    screen.run();
}
1
2
3
4
5
6
7
8
9

We’ll get this error because String doesn’t implement the Draw trait:

$ cargo run
   Compiling gui v0.1.0 (file:///projects/gui)
error[E0277]: the trait bound `String: Draw` is not satisfied
 --> src/main.rs:5:26
  |
5 |         components: vec![Box::new(String::from("Hi"))],
  |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Draw` is not implemented for `String`
  |
  = help: the trait `Draw` is implemented for `Button`
  = note: required for the cast to the object type `dyn Draw`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `gui` due to previous error
1
2
3
4
5
6
7
8
9
10
11
12
13

这告诉了我们，要么是我们传递了并不希望传递给 Screen 的类型并应该提供其他类型，要么应该在 String 上实现Draw以便 Screen 可以调用其上的 draw。

17.2.3 Trait对象执行动态调度

回想第10章“使用泛型的代码性能”一节中，我们对在泛型上使用trait边界时编译器执行的单一化过程的讨论:编译器为我们用来代替泛型类型参数的每个具体类型生成函数和方法的非泛型实现。由单态化产生的代码正在执行静态调度（static dispatch），也就是当编译器知道您在编译时调用什么方法时。这与动态调度(dynamic dispatch)相反，动态调度是指编译器在编译时无法判断调用的是哪个方法。在动态调度情况下，编译器发出的代码将在运行时找出要调用的方法。

当我们使用trait对象时，Rust必须使用动态调度。编译器不知道使用trait对象的代码可能使用的所有类型，因此它不知道调用哪个类型上实现的哪个方法。相反，在运行时，Rust使用trait对象中的指针来知道调用哪个方法。这种查找会产生静态调度不会产生的运行时成本。动态调度还会阻止编译器选择内联方法的代码，这反过来又会阻止一些优化。然而，我们在示例17-5中编写的代码中获得了额外的灵活性，并且能够在示例17-9中提供支持，因此这是需要考虑的权衡。

17.3 实现面向对象的设计模式

状态模式(state pattern)是一种面向对象的设计模式。该模式的关键在于，我们在内部定义一个值可以拥有的一组状态。状态由一组状态对象( state objects)表示，值的行为根据其状态而变化。我们将通过一个博客帖子结构的例子，它有一个字段来保存它的状态，它将是来自集合“draft”、“review”或“published”的状态对象。

状态对象共享功能:当然，在Rust中，我们使用结构体和traits ，而不是对象和继承。每个状态对象都对自己的行为负责，并负责在应该改变为另一种状态时进行治理。保存状态对象的值不知道状态的不同行为，也不知道何时在状态之间转换。

使用状态模式的优点是，当程序的业务需求发生变化时，我们不需要更改保存状态的值的代码或使用该值的代码。我们只需要更新一个状态对象内部的代码来更改它的规则，或者添加更多的状态对象。

首先，我们将以更传统的面向对象的方式实现状态模式，然后我们将使用Rust中更自然的方法。让我们深入研究如何使用状态模式逐步实现博客文章工作流。

最终的功能是这样的:

• 博客文章一开始都是空的草稿(draft)。
• 草稿完成后，要求对该文章进行审查(review )。
• 当文章被批准后，它就会被发表（published）。
• 只有已经发布的博客文章才会返回打印内容，所以未经批准的文章不会意外发布。

任何其他对文章的修改都不会产生任何效果。例如，如果我们试图在请求审查之前批准一篇博客文章的草稿，那么该文章应该保持为未发表的草稿。

示例17-11以代码形式展示了这个工作流:这是我们将在名为blog的库crate 中实现的API的示例用法。这还不能编译，因为我们还没有实现blog crate 。
17-11

use blog::Post;

fn main() {
    let mut post = Post::new();

    post.add_text("I ate a salad for lunch today");
    assert_eq!("", post.content());

    post.request_review();
    assert_eq!("", post.content());

    post.approve();
    assert_eq!("I ate a salad for lunch today", post.content());
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

我们希望允许用户使用post::new创建一个新的博客文章草稿。我们希望允许将文本添加到博客文章中。如果我们试图立即获得帖子的内容，在批准之前，我们不应该得到任何文本，因为帖子仍然是一个草案。我们添加了assert_eq!在代码中进行演示。对此，一个很好的单元测试是断言博客文章草稿从content方法返回一个空字符串，但我们不打算为这个示例编写测试。

接下来，我们希望启用对文章进行审查的请求，并希望content 在等待审查时返回一个空字符串。当文章获得批准时，它应该被发布，这意味着当内容被调用时，文章的content 将被返回。

注意，我们在crate 中与之交互的唯一类型是Post类型。该类型将使用状态模式并保存一个值，该值将是三个状态对象之一，表示一篇文章可能处于起草阶段、等待审查或发布的各种状态。从一种状态到另一种状态的更改将在Post类型内部进行管理。状态变化是响应我们的库的用户在Post实例上调用的方法的，但是他们不必直接管理状态变化。此外，用户不能在状态上犯错误，比如在评论之前发布帖子。

17.3.1 定义Post并在Draft状态创建一个新实例

让我们开始库的实现!我们知道我们需要一个公共Post结构体来保存一些内容，因此我们将从该结构的定义和一个相关的公共new函数开始，以创建Post的实例，如示例17-12所示。我们还将创建一个私有Statetrait ，它将定义Post的所有状态对象必须具有的行为。

然后Post将在名为state 的私有字段中保存Box的trait对象在Option中以保存状态对象。稍后您将看到为什么Option是必要的。

pub struct Post {
    state: Option<Box<dyn State>>,
    content: String,
}

impl Post {
    pub fn new() -> Post {
        Post {
            state: Some(Box::new(Draft {})),
            content: String::new(),
        }
    }
}

trait State {}

struct Draft {}

impl State for Draft {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

State trait 定义了由不同post状态共享的行为。状态对象是Draft、PendingReview和Published，它们都将实现state trait 。目前，trait还没有任何方法，我们将从只定义Draft状态开始，因为这是我们希望post开始的状态。

当我们创建一个新的Post时，我们将其状态字段设置为包含Box的Some值。此Box指向Draft结构的一个新实例。这确保了每当我们创建Post的新实例时，它将以草稿的形式开始。因为Post的状态字段是私有的，所以无法在任何其他状态中创建Post !在Post::new函数中，我们将内容字段设置为一个新的空String。

17.3.2 存储文章内容的文本

我们在示例17-11中看到，我们希望能够调用一个名为add_text的方法并向它传递一个&str，然后将该&str添加为博客文章的文本内容。我们将其作为一个方法来实现，而不是将content 字段公开为pub，以便稍后我们可以实现一个方法来控制如何读取content 字段的数据。add_text方法非常简单，所以让我们将示例17-13中的实现添加到impl Post块中:

impl Post {
    // --snip--
    pub fn add_text(&mut self, text: &str) {
        self.content.push_str(text);
    }
}
1
2
3
4
5
6

add_text方法有一个对self的可变引用，因为我们正在改变调用add_text的Post实例。然后在content中的String上调用push_str函数，并传递要添加到保存的内容中的文本参数。此行为不依赖于帖子所处的状态，因此它不是状态模式的一部分。add_text方法完全不与状态字段交互，但它是我们希望支持的行为的一部分。

17.3.3 确保草稿的内容是空的

即使在调用add_text并向post添加了一些内容之后，我们仍然希望content方法返回一个空字符串片，因为post仍然处于草稿状态，如示例17-11的第7行所示。现在，让我们用最简单的方法来实现content方法，以满足这一要求:总是返回一个空字符串片。一旦我们实现了改变帖子状态的功能，我们将在后面修改它。到目前为止，文章只能处于草稿状态，所以文章内容应该总是空的。示例17-14显示了这个占位符实现:

impl Post {
    // --snip--
    pub fn content(&self) -> &str {
        ""
    }
}
1
2
3
4
5
6

使用这个添加的content 方法，示例17-11到第7行中的所有内容都可以正常工作。

17.3.4 请求审查文章会改变其状态

接下来，我们需要添加请求审查文章的功能，它应该将其状态从Draft更改为PendingReview。示例17-15显示了这段代码:

impl Post {
    // --snip--
    pub fn request_review(&mut self) {
        if let Some(s) = self.state.take() {
            self.state = Some(s.request_review())
        }
    }
}

trait State {
    fn request_review(self: Box<Self>) -> Box<dyn State>;
}

struct Draft {}

impl State for Draft {
    fn request_review(self: Box<Self>) -> Box<dyn State> {
        Box::new(PendingReview {})
    }
}

struct PendingReview {}

impl State for PendingReview {
    fn request_review(self: Box<Self>) -> Box<dyn State> {
        self
    }
}
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
26
27
28

我们为Post提供了一个名为request_review的公共方法，它将接受self的一个可变引用。然后在Post的当前状态上调用一个内部的request_review方法，第二个request_review方法使用当前状态并返回一个新状态。

我们将request_review方法添加到State特征中;所有实现trait的类型现在都需要实现request_review方法。注意，我们没有使用self、&self或&mut self作为方法的第一个参数，而是使用self: Box。这种语法意味着该方法只有在对包含该类型的Box调用时才有效。此语法获得Box的所有权，使旧状态无效，以便Post的状态值可以转换为新状态。

要使用旧状态，request_review方法需要获得状态值的所有权。这就是Post的状态字段中的Option发挥作用的地方:我们调用take方法从状态字段中取出Some值并在其位置上留下None，因为Rust不允许我们在结构中有未填充的字段。这允许我们将状态值移出Post，而不是借用它。然后我们将把post的state值设置为这个操作的结果。

我们需要暂时将state 设置为None，而不是直接用self.state = self.state.request_review();这样的代码设置它，来获得state 值的所有权。这确保Post在将旧状态值转换为新状态后不能使用旧状态值。

Draft上的request_review方法返回一个新的PendingReview结构体的新盒装实例，该结构体表示文章等待审核时的状态。PendingReview结构也实现了request_review方法，但不做任何转换。相反，它返回自己，因为当我们请求一个已经处于PendingReview状态的帖子的评论时，它应该保持在PendingReview状态。

现在我们可以开始看到状态模式的优点了:Post上的request_review方法无论其状态值如何都是相同的。每个状态都要为自己的规则负责。

我们将保持Post上的content方法不变，返回一个空字符串片。我们现在可以让Post处于PendingReview状态和Draft状态，但我们希望在PendingReview状态中也有相同的行为。示例17-11现在可以工作到第10行!

17.3.5 添加approve更改内容的行为approve

方法将类似于request_review方法:它将state设置为当前状态表示当该状态被批准时它应该拥有的值，如示例17-16所示:
17-16:

impl Post {
    // --snip--
    pub fn approve(&mut self) {
        if let Some(s) = self.state.take() {
            self.state = Some(s.approve())
        }
    }
}

trait State {
    fn request_review(self: Box<Self>) -> Box<dyn State>;
    fn approve(self: Box<Self>) -> Box<dyn State>;
}

struct Draft {}

impl State for Draft {
    // --snip--
    fn approve(self: Box<Self>) -> Box<dyn State> {
        self
    }
}

struct PendingReview {}

impl State for PendingReview {
    // --snip--
    fn approve(self: Box<Self>) -> Box<dyn State> {
        Box::new(Published {})
    }
}

struct Published {}

impl State for Published {
    fn request_review(self: Box<Self>) -> Box<dyn State> {
        self
    }

    fn approve(self: Box<Self>) -> Box<dyn State> {
        self
    }
}
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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

我们将approve方法添加到State trait 中，并添加实现State(Published )的新结构体。

类似于PendingReview上的request_review的工作方式，如果我们在Draft上调用approve方法，它将没有效果，因为approve将返回self。当我们在PendingReview上调用approve时，它返回Published结构体的一个新的boxed 实例。Published结构体实现了State trait，并且对于request_review方法和approve方法，它都返回自己，因为在这两种情况下，post应该保持Published状态。

现在我们需要更新Post上的content方法。我们希望从content返回的值依赖于Post的当前状态，因此我们将Post委托给一个根据其状态定义的内容方法，如示例17-17所示:

impl Post {
    // --snip--
    pub fn content(&self) -> &str {
        self.state.as_ref().unwrap().content(self)
    }
    // --snip--
}
1
2
3
4
5
6
7

因为目标是将所有这些规则保存在实现State的结构体中，所以我们对State中的值调用content方法，并将post实例(即self)作为参数传递。然后返回使用状态值的content方法返回的值。

我们在Option上调用as_ref方法，因为我们想要Option内的值的引用，而不是该值的所有权。因为state是Option>，所以当我们调用as_ref时，返回的是Option<&Box>。如果不调用as_ref，就会出现错误，因为无法将状态移出函数形参的借来的&self。

然后调用unwrap方法，我们知道它永远不会出错，因为我们知道Post上的方法确保当这些方法完成时，状态总是包含一个Some值。这是我们在第9章“你比编译器拥有更多信息的情况”一节中谈到的情况之一，我们知道None值永远不可能，即使编译器无法理解这一点。

此时，当我们在&Box上调用content时，deref coercion将在&和Box上生效，因此最终将在实现Statetrait的类型上调用content方法。这意味着我们需要向Statetrait定义添加内容，这也是我们将根据所拥有的状态将返回什么内容的逻辑放在哪里的地方，如示例17-18所示:

trait State {
    // --snip--
    fn content<'a>(&self, post: &'a Post) -> &'a str {
        ""
    }
}

// --snip--
struct Published {}

impl State for Published {
    // --snip--
    fn content<'a>(&self, post: &'a Post) -> &'a str {
        &post.content
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

我们为返回空字符串片的content方法添加一个默认实现。这意味着我们不需要实现Draft和PendingReview结构体上的内容。Published结构体将覆盖content方法并返回post.content中的值。

注意，这个方法需要生命周期注释，正如我们在第10章中讨论的那样。我们将post的引用作为参数并返回该post的一部分的引用，因此返回的引用的生存期与post参数的生存期相关。

我们已经完成了—示例17-11现在都可以工作了!我们已经使用博客文章工作流的规则实现了状态模式。与规则相关的逻辑存在于状态对象中，而不是分散在Post中。

为什么不是Enum?

您可能想知道为什么我们不使用带有不同post状态的枚举作为变量。这当然是一个可能的解决方案，试试它，并比较最终的结果，看看你更喜欢哪一个!使用枚举的一个缺点是，每个检查枚举值的地方都需要一个匹配表达式或类似表达式来处理每个可能的变量。这可能比trait对象解决方案更加重复。

17.3.6 状态模式的权衡

我们已经展示了Rust能够实现面向对象的状态模式来封装一个帖子在每个状态下应该具有的不同类型的行为。Post上的方法对各种行为一无所知。根据我们组织代码的方式，我们只需查看一个地方就可以知道一个已发布的帖子的不同行为方式:State trait在published结构上的实现。

如果要创建一个不使用状态模式的替代实现，则可以在Post上的方法中使用match 表达式，甚至在检查Post状态并更改这些地方的行为的主代码中使用match 表达式。这意味着我们必须查看多个地方，以理解处于已发布状态的帖子的所有含义!这只会增加我们添加的更多状态:每个匹配表达式都需要另一个 arm。

有了状态模式，Post方法和我们使用Post的位置不需要匹配表达式，要添加一个新的状态，我们只需要添加一个新的结构，并在这个结构上实现trait方法。

使用状态模式的实现很容易扩展以添加更多功能。要了解维护使用状态模式的代码的简单性，可以尝试以下建议:

• 添加一个reject方法，将post的状态从PendingReview更改回Draft。
• 在将状态更改为Published之前，需要两次调用进行批准。
• 只允许用户在文章处于Draft状态时添加文本内容。提示:让状态对象负责内容可能发生的变化，但不负责修改Post。

状态模式的一个缺点是，因为状态实现了状态之间的转换，所以有些状态是相互耦合的。如果我们在PendingReview和Published之间添加另一个状态，例如Scheduled，我们将不得不更改PendingReview中的代码，以转换到Scheduled。如果PendingReview不需要通过添加新状态进行更改，那么工作量会更少，但这将意味着切换到另一种设计模式。

另一个缺点是我们复制了一些逻辑。为了消除一些重复，我们可以尝试在返回self的State特征上为request_review和approve方法设置默认实现;然而，这将违反对象安全性，因为trait 不知道具体的self 到底是什么。我们希望能够将State用作trait对象，因此我们需要它的方法是对象安全的。

其他的重复包括Post上的request_review和approve方法的类似实现。这两个方法都将Option state 字段中的值委托给相同方法的实现，并将state 字段的新值设置为结果。如果Post上有很多方法遵循这种模式，我们可以考虑定义一个宏来消除重复(参见第19章的“宏”一节)。

通过完全按照面向对象语言定义的方式实现状态模式，我们没有充分利用Rust的优势。让我们看看可以对blogcrate 进行的一些更改，这些更改可以将无效状态和转换转化为编译时错误。

将状态和行为编码为不同类型

我们将向您展示如何重新考虑状态模式，以获得一组不同的权衡。我们不是完全封装状态和转换，以便外部代码不了解它们，而是将状态编码为不同的类型。因此，Rust的类型检查系统将通过发出编译器错误来防止只允许使用已发布帖子的的地方使用草稿帖子。

让我们考虑一下示例17-11中main的第一部分:

fn main() {
    let mut post = Post::new();

    post.add_text("I ate a salad for lunch today");
    assert_eq!("", post.content());
}
1
2
3
4
5
6

我们仍然可以使用Post::new在草稿状态下创建新帖子，并且可以向帖子的内容添加文本。但是，我们不会在草稿文章中使用返回空字符串的content方法，而是使草稿文章完全没有content方法。这样，如果我们试图获取一个草稿文章的内容，我们将得到一个编译器错误，告诉我们方法不存在。因此，我们不可能在生产中意外地显示草稿帖子内容，因为那些代码甚至不会编译。示例17-19显示了Post结构和DraftPost结构的定义，以及它们各自的方法:

pub struct Post {
    content: String,
}

pub struct DraftPost {
    content: String,
}

impl Post {
    pub fn new() -> DraftPost {
        DraftPost {
            content: String::new(),
        }
    }

    pub fn content(&self) -> &str {
        &self.content
    }
}

impl DraftPost {
    pub fn add_text(&mut self, text: &str) {
        self.content.push_str(text);
    }
}
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

Post和DraftPost结构都有一个私有content 字段，用于存储博客文章文本。结构不再有状态字段，因为我们将状态的编码移到了结构的类型。Post结构将表示已发布的文章，它有一个返回content的content方法。

我们仍然有一个Post::new函数，但是它返回的不是Post的实例，而是DraftPost的实例。因为内容是私有的，并且没有任何返回Post的函数，所以现在不可能创建Post的实例。

DraftPost结构体有一个add_text方法，所以我们可以像以前一样将文本添加到内容中，但请注意，DraftPost没有定义内容方法!因此，现在该程序确保所有帖子都是从草稿帖子开始的，并且草稿帖子的内容不能显示。任何绕过这些约束的尝试都将导致编译器错误。

将转换实现为不同类型的转换

那么，我们如何获得一篇发表的文章呢?我们想要执行这样的规则:一篇文章的草稿必须经过审查和批准才能发表。处于pending review状态的帖子仍然不应该显示任何内容。让我们通过添加另一个结构PendingReviewPost来实现这些约束，在DraftPost上定义request_review方法以返回PendingReviewPost，并在PendingReviewPost上定义approve方法以返回Post，如示例17-20所示:

impl DraftPost {
    // --snip--
    pub fn request_review(self) -> PendingReviewPost {
        PendingReviewPost {
            content: self.content,
        }
    }
}

pub struct PendingReviewPost {
    content: String,
}

impl PendingReviewPost {
    pub fn approve(self) -> Post {
        Post {
            content: self.content,
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

request_review和approve方法拥有self的所有权，因此使用DraftPost和PendingReviewPost实例，并将它们分别转换为PendingReviewPost和published Post。这样，在调用了DraftPost实例的request_review之后，就不会有任何滞留的实例，等等。PendingReviewPost结构体上没有定义内容方法，因此试图读取其内容会导致编译器错误，就像使用DraftPost一样。因为获得一个定义了内容方法的已发布的Post实例的唯一方法是调用PendingReviewPost上的approve方法，而获得PendingReviewPost的唯一方法是调用DraftPost上的request_review方法，所以我们现在已经将博客文章工作流编码到类型系统中。

但我们也必须对main做一些小的改变。request_review和approve方法返回新实例，而不是修改调用它们的结构，因此我们需要添加更多的let post =遮蔽赋值来保存返回的实例。我们也不能让关于草稿和等待审阅帖子的内容的断言为空字符串，我们也不需要它们:我们不能再编译试图在这些状态下使用帖子内容的代码。main中更新的代码如示例17-21所示:
17-21:

use blog::Post;

fn main() {
    let mut post = Post::new();

    post.add_text("I ate a salad for lunch today");

    let post = post.request_review();

    let post = post.approve();

    assert_eq!("I ate a salad for lunch today", post.content());
}
1
2
3
4
5
6
7
8
9
10
11
12
13

我们需要对main进行更改以重新分配post，这意味着该实现不再完全遵循面向对象的状态模式:状态之间的转换不再完全封装在post实现中。然而，我们的收获是无效状态现在是不可能的，因为类型系统和编译时发生的类型检查!这确保了某些错误，例如未发布的帖子的内容显示，在它们投入生产之前就能被发现。

在示例17-21之后的blog crate 上尝试本节开头建议的任务，看看您对这个版本代码的设计有什么看法。注意，在这个设计中，有些任务可能已经完成了。

我们已经看到，即使Rust能够实现面向对象的设计模式，其他模式(如将状态编码到类型系统中)也可以在Rust中使用。这些模式有不同的取舍。尽管您可能非常熟悉面向对象的模式，但是重新考虑这个问题以利用Rust的特性可以带来好处，例如在编译时防止一些错误。面向对象模式在Rust中并不总是最好的解决方案，这是因为面向对象语言不具备某些特性，比如所有权。

看完本章，不管你是否认为Rust是一种面向对象的语言，你现在都知道可以使用trait对象在Rust中获得一些面向对象的特性。动态分派可以为代码提供一些灵活性，以换取一些运行时性能。您可以使用这种灵活性来实现面向对象的模式，这有助于代码的可维护性。Rust还有一些面向对象语言不具备的特性，比如所有权。面向对象的模式并不总是利用Rust优势的最佳方式，但它是一种可用的方式