Merge pull request #318 from JesseAtSZ/patch-3

Update module.md
pull/326/head
Sunface 3 years ago committed by GitHub
commit be1d935199
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -1,10 +1,10 @@
# 模块 Module # 模块 Module
在本章节我们将深入讲讲Rust的代码构成单元模块。使用模块可以将包中的代码按照功能性进行重组最终实现更好的可读性及易用性。同时我们还能非常灵活地去控制代码的可见性进一步强化了Rust的安全性。 在本章节,我们将深入讲讲 Rust 的代码构成单元:模块。使用模块可以将包中的代码按照功能性进行重组,最终实现更好的可读性及易用性。同时,我们还能非常灵活地去控制代码的可见性,进一步强化 Rust 的安全性。
## 创建嵌套模块 ## 创建嵌套模块
小旅馆sorry是小餐馆相信大家都挺熟悉的学校外的估计也没少去那么咱就用小餐馆为例看看Rust的模块该如何使用。 小旅馆sorry是小餐馆相信大家都挺熟悉的学校外的估计也没少去那么咱就用小餐馆为例看看 Rust 的模块该如何使用。
使用`cargo new --lib restaurant`创建一个小餐馆,注意,这里创建的是一个库类型的`package`, 然后将以下代码放入`src/lib.rs`中: 使用 `cargo new --lib restaurant` 创建一个小餐馆,注意,这里创建的是一个库类型的 `Package`,然后将以下代码放入 `src/lib.rs` 中:
```rust ```rust
// 餐厅前厅,用于吃饭 // 餐厅前厅,用于吃饭
mod front_of_house { mod front_of_house {
@ -31,10 +31,10 @@ mod front_of_house {
- 模块中可以定义各种 Rust 类型,例如函数、结构体、枚举、特征等 - 模块中可以定义各种 Rust 类型,例如函数、结构体、枚举、特征等
- 所有模块均定义在同一个文件中 - 所有模块均定义在同一个文件中
类似上述代码中所做的,使用模块,我们就能将功能相关的代码组织到一起,然后通过一个模块名称来说明这些代码为何被组织在一起。这样其它程序员在使用你的模块时,就可以更快理解和上手。 类似上述代码中所做的,使用模块,我们就能将功能相关的代码组织到一起,然后通过一个模块名称来说明这些代码为何被组织在一起。这样其它程序员在使用你的模块时,就可以更快理解和上手。
## 模块树 ## 模块树
在[上一节](./crate.md)中,我们提到过`src/main.rs`和`src/lib.rs`被称为包根(crate root),这个奇葩名称的来源(我不想承认是自己翻译水平太烂- , -)是由于这两个文件的内容形成了一个模块`crate`,该模块位于包的树形结构(由模块组成的树形结构)的根部: 在[上一节](./crate.md)中,我们提到过 `src/main.rs` `src/lib.rs` 被称为包根(crate root),这个奇葩名称的来源(我不想承认是自己翻译水平太烂-,-)是由于这两个文件的内容形成了一个模块 `crate`,该模块位于包的树形结构(由模块组成的树形结构)的根部
```console ```console
crate crate
└── front_of_house └── front_of_house
@ -57,11 +57,11 @@ crate
## 用路径引用模块 ## 用路径引用模块
想要调用一个函数,就需要知道它的路径,在 Rust 中,这种路径有两种形式: 想要调用一个函数,就需要知道它的路径,在 Rust 中,这种路径有两种形式:
- **绝对路径**, 从包根开始,路径名以包名或者`crate`作为开头 - **绝对路径**,从包根开始,路径名以包名或者 `crate` 作为开头
- **相对路径**, 从当前模块开始,以`self`,`super`或当前模块的标识符作为开头 - **相对路径**,从当前模块开始,以 `self``super` 或当前模块的标识符作为开头
让我们继续经营那个惨淡的小餐馆,这次为它实现一个小功能: 让我们继续经营那个惨淡的小餐馆,这次为它实现一个小功能
<span class="filename">文件名: src/lib.rs</span> <span class="filename">文件名src/lib.rs</span>
```rust ```rust
mod front_of_house { mod front_of_house {
@ -79,10 +79,10 @@ pub fn eat_at_restaurant() {
} }
``` ```
上面的代码为了简化实现,省去了其余模块和函数,这样可以把关注点放在函数调用上。`eat_at_restaurant`是一个定义在包根中的函数,在该函数中使用了两种方式对`add_to_waitlist`进行调用。 上面的代码为了简化实现,省去了其余模块和函数,这样可以把关注点放在函数调用上。`eat_at_restaurant` 是一个定义在包根中的函数,在该函数中使用了两种方式对 `add_to_waitlist` 进行调用。
#### 绝对路径引用 #### 绝对路径引用
因为`eat_at_restaurant`和`add_to_waitlist`都定义在一个包中,因此在绝对路径引用时,可以直接以`crate`开头,然后逐层引用,每一层之间使用`::`分隔: 因为 `eat_at_restaurant` `add_to_waitlist` 都定义在一个包中,因此在绝对路径引用时,可以直接以 `crate` 开头,然后逐层引用,每一层之间使用 `::` 分隔:
```rust ```rust
crate::front_of_house::hosting::add_to_waitlist(); crate::front_of_house::hosting::add_to_waitlist();
``` ```
@ -101,19 +101,19 @@ crate
└── take_payment └── take_payment
``` ```
可以看出,绝对路径的调用,完全符合了模块树的层级递进,非常符合直觉,如果类比文件系统,就跟使用绝对路径调用可执行程序差不多:`/front_of_house/hosting/add_to_waitlist`, 使用`crate`作为开始就和使用`/`作为开始一样。 可以看出,绝对路径的调用,完全符合了模块树的层级递进,非常符合直觉,如果类比文件系统,就跟使用绝对路径调用可执行程序差不多:`/front_of_house/hosting/add_to_waitlist`,使用 `crate` 作为开始就和使用 `/` 作为开始一样。
#### 相对路径引用 #### 相对路径引用
再回到模块树中,因为`eat_at_restaurant`和`front_of_house`都处于包根`crate`中,因此相对路径可以使用`front_of_house`作为开头: 再回到模块树中,因为 `eat_at_restaurant``front_of_house` 都处于包根 `crate` 中,因此相对路径可以使用 `front_of_house` 作为开头:
```rust ```rust
front_of_house::hosting::add_to_waitlist(); front_of_house::hosting::add_to_waitlist();
``` ```
如果类比文件系统,那么它类似于调用同一个目录下的程序,你可以这么做: `front_of_house/hosting/add_to_waitlist`, 嗯也很符合直觉。 如果类比文件系统,那么它类似于调用同一个目录下的程序,你可以这么做`front_of_house/hosting/add_to_waitlist`嗯也很符合直觉。
#### 绝对还是相对? #### 绝对还是相对
如果只是为了引用到指定模块中的对象,那么两种都可以,但是在实际使用时,需要遵循一个原则:**当代码被挪动位置时,尽量减少引用路径的修改**,相信大家都遇到过,修改了某处代码,导致所有路径都要挨个替换,这显然不是好的路径选择。 如果只是为了引用到指定模块中的对象,那么两种都可以,但是在实际使用时,需要遵循一个原则:**当代码被挪动位置时,尽量减少引用路径的修改**,相信大家都遇到过,修改了某处代码,导致所有路径都要挨个替换,这显然不是好的路径选择。
回到之前的例子, 如果我们把`front_of_house`模块和`eat_at_restaurant`移动到一个模块中`customer_experience`, 那么绝对路径的引用方式就必须进行修改:`crate::customer_experience::front_of_house ...`, 但是假设我们使用的相对路径,那么该路径就无需修改,因为它们两的相对位置其实没有变: 回到之前的例子,如果我们把 `front_of_house` 模块和 `eat_at_restaurant` 移动到一个模块中 `customer_experience`,那么绝对路径的引用方式就必须进行修改:`crate::customer_experience::front_of_house ...`但是假设我们使用的相对路径,那么该路径就无需修改,因为它们两的相对位置其实没有变:
```console ```console
crate crate
└── customer_experience └── customer_experience
@ -139,7 +139,7 @@ crate
不过,如果不确定哪个好,你可以考虑优先使用绝对路径,因为调用的地方和定义的地方往往是分离的,而定义的地方较少会变动。 不过,如果不确定哪个好,你可以考虑优先使用绝对路径,因为调用的地方和定义的地方往往是分离的,而定义的地方较少会变动。
## 代码可见性 ## 代码可见性
让我们运行下面(之前)的代码: 让我们运行下面(之前)的代码
```rust ```rust
mod front_of_house { mod front_of_house {
mod hosting { mod hosting {
@ -156,7 +156,7 @@ pub fn eat_at_restaurant() {
} }
``` ```
意料之外的报错了,毕竟看上去确实很简单且没有任何问题: 意料之外的报错了,毕竟看上去确实很简单且没有任何问题
```console ```console
error[E0603]: module `hosting` is private error[E0603]: module `hosting` is private
--> src/lib.rs:9:28 --> src/lib.rs:9:28
@ -165,7 +165,7 @@ error[E0603]: module `hosting` is private
| ^^^^^^^ private module | ^^^^^^^ private module
``` ```
错误信息很清晰:`hosting`模块是私有的,无法在包根进行访问,那么为何`front_of_house`模块就可以访问?因为它和`eat_at_restaurant`同属于一个包根作用域内,同一个模块内的代码自然不存在私有化问题(所以我们之前章节的代码都没有报过这个错误!)。 错误信息很清晰:`hosting` 模块是私有的,无法在包根进行访问,那么为何 `front_of_house` 模块就可以访问?因为它和 `eat_at_restaurant` 同属于一个包根作用域内,同一个模块内的代码自然不存在私有化问题(所以我们之前章节的代码都没有报过这个错误)。
模块不仅仅对于组织代码很有用,它还能定义代码的私有化边界:在这个边界内,什么内容能让外界看到,什么内容不能,都有很明确的定义。因此,如果希望让函数或者结构体等类型变成私有化的,可以使用模块。 模块不仅仅对于组织代码很有用,它还能定义代码的私有化边界:在这个边界内,什么内容能让外界看到,什么内容不能,都有很明确的定义。因此,如果希望让函数或者结构体等类型变成私有化的,可以使用模块。
@ -174,7 +174,7 @@ Rust出于安全的考虑默认情况下所有的类型都是私有化的
#### pub 关键字 #### pub 关键字
类似其它语言的 `public` 或者 Go 语言中的首字母大写Rust 提供了 `pub` 关键字,通过它你可以控制模块和模块中指定项的可见性。 类似其它语言的 `public` 或者 Go 语言中的首字母大写Rust 提供了 `pub` 关键字,通过它你可以控制模块和模块中指定项的可见性。
由于之前的解释,我们知道了只需要将`hosting`模块标记为对外可见即可: 由于之前的解释,我们知道了只需要将 `hosting` 模块标记为对外可见即可:
```rust ```rust
mod front_of_house { mod front_of_house {
pub mod hosting { pub mod hosting {
@ -196,9 +196,9 @@ error[E0603]: function `add_to_waitlist` is private
哦?难道模块可见还不够,还需要将函数 `add_to_waitlist` 标记为可见的吗? 是的,没错,模块可见性不代表模块内部项的可见性,模块的可见性仅仅是允许其它模块去引用它,但是想要引用它内部的项,还得继续将对应的项标记为 `pub` 哦?难道模块可见还不够,还需要将函数 `add_to_waitlist` 标记为可见的吗? 是的,没错,模块可见性不代表模块内部项的可见性,模块的可见性仅仅是允许其它模块去引用它,但是想要引用它内部的项,还得继续将对应的项标记为 `pub`
在实际项目中一个模块需要对外暴露的数据和API往往就寥寥数个如果将模块标记为可见代表着内部项也全部对外可见那你是不是还得把那些不可见的一个一个标记为`private`? 反而更是麻烦的多。 在实际项目中,一个模块需要对外暴露的数据和 API 往往就寥寥数个,如果将模块标记为可见代表着内部项也全部对外可见,那你是不是还得把那些不可见的,一个一个标记为 `private`?反而是更麻烦的多。
既然知道了如何解决,那么我们为函数也标记上`pub`: 既然知道了如何解决,那么我们为函数也标记上 `pub`
```rust ```rust
mod front_of_house { mod front_of_house {
pub mod hosting { pub mod hosting {
@ -209,13 +209,13 @@ mod front_of_house {
/*--- snip ----*/ /*--- snip ----*/
``` ```
Bang, 顺利通过编译,感觉自己又变强了。 Bang顺利通过编译,感觉自己又变强了。
## 使用 `super` 引用模块 ## 使用 `super` 引用模块
在[用路径引用模块](#用路径引用模块)中,我们提到了相对路径有三种方式开始:`self`、`super`和 `crate` 或者模块名,其中第三种在前面已经讲到过,现在来看看通过 `super` 的方式引用模块项。 在[用路径引用模块](#用路径引用模块)中,我们提到了相对路径有三种方式开始:`self`、`super`和 `crate` 或者模块名,其中第三种在前面已经讲到过,现在来看看通过 `super` 的方式引用模块项。
`super`代表的是父模块为开始的引用方式,非常类似于文件系统中的`..`语法: `../a/b` `super` 代表的是父模块为开始的引用方式,非常类似于文件系统中的 `..` 语法:`../a/b`
<span class="filename">文件名: src/lib.rs</span> <span class="filename">文件名src/lib.rs</span>
```rust ```rust
fn serve_order() {} fn serve_order() {}
@ -231,7 +231,7 @@ mod back_of_house {
} }
``` ```
嗯,我们的小餐馆又完善了,终于有厨房了! 看来第一个客人也快可以有了。。。在厨房模块中,使用`super::serve_order`语法,调用了父模块(包根)中的`serve_order`函数。 嗯,我们的小餐馆又完善了,终于有厨房了看来第一个客人也快可以有了。。。在厨房模块中,使用 `super::serve_order` 语法,调用了父模块(包根)中的 `serve_order` 函数。
那么你可能会问,为何不使用 `crate::serve_order` 的方式?额,其实也可以,不过如果你确定未来这种层级关系不会改变,那么 `super::serve_order` 的方式会更稳定,未来就算它们都不在包根了,依然无需修改引用路径。所以路径的选用,往往还是取决于场景,以及未来代码的可能走向。 那么你可能会问,为何不使用 `crate::serve_order` 的方式?额,其实也可以,不过如果你确定未来这种层级关系不会改变,那么 `super::serve_order` 的方式会更稳定,未来就算它们都不在包根了,依然无需修改引用路径。所以路径的选用,往往还是取决于场景,以及未来代码的可能走向。
@ -239,7 +239,7 @@ mod back_of_house {
`self` 其实就是引用自身模块中的项,也就是说和我们之前章节的代码类似,都调用同一模块中的内容,区别在于之间章节中直接通过名称调用即可,而 `self`,你得多此一举: `self` 其实就是引用自身模块中的项,也就是说和我们之前章节的代码类似,都调用同一模块中的内容,区别在于之间章节中直接通过名称调用即可,而 `self`,你得多此一举:
```rust ```rust
fn serve_order() { fn serve_order() {
self::back_of_house self::back_of_house::cook_order()
} }
mod back_of_house { mod back_of_house {
@ -248,7 +248,7 @@ mod back_of_house {
crate::serve_order(); crate::serve_order();
} }
fn cook_order() {} pub fn cook_order() {}
} }
``` ```
@ -268,7 +268,7 @@ mod back_of_house {
## 模块与文件分离 ## 模块与文件分离
在之前的例子中,我们所有的模块都定义在 `src/lib.rs` 中,但是当模块变多或者变大时,需要将模块放入一个单独的文件中,让代码更好维护。 在之前的例子中,我们所有的模块都定义在 `src/lib.rs` 中,但是当模块变多或者变大时,需要将模块放入一个单独的文件中,让代码更好维护。
现在,把`front_of_house`前厅分离出来,放入一个单独的文件中`src/front_of_house.rs`: 现在,把 `front_of_house` 前厅分离出来,放入一个单独的文件中 `src/front_of_house.rs`
```rust ```rust
pub mod hosting { pub mod hosting {
pub fn add_to_waitlist() {} pub fn add_to_waitlist() {}
@ -288,11 +288,11 @@ pub fn eat_at_restaurant() {
} }
``` ```
so easy! 其实跟之前在同一个文件中也米有太大的不同,但是有几点值得注意: so easy!其实跟之前在同一个文件中也没有太大的不同,但是有几点值得注意:
- `mod front_of_house;` 告诉 Rust 从另一个和模块 `front_of_house` 同名的文件中加载该模块的内容 - `mod front_of_house;` 告诉 Rust 从另一个和模块 `front_of_house` 同名的文件中加载该模块的内容
- 使用绝对路径的方式来引用`hosting`模块: `crate::front_of_house::hosting;` - 使用绝对路径的方式来引用 `hosting` 模块:`crate::front_of_house::hosting;`
需要注意的是,和之前代码中 `mod front_of_house{..}` 的完整模块不同,现在的代码中,模块的声明和实现是分离的,实现是在单独的 `front_of_house.rs` 文件中,然后通过 `mod front_of_house;` 这条声明语句从该文件中把模块内容加载进来。因此我们可以认为,模块 `front_of_house` 的定义还是在 `src/lib.rs` 中,只不过模块的具体内容被移动到了 `src/front_of_house.rs` 文件中。 需要注意的是,和之前代码中 `mod front_of_house{..}` 的完整模块不同,现在的代码中,模块的声明和实现是分离的,实现是在单独的 `front_of_house.rs` 文件中,然后通过 `mod front_of_house;` 这条声明语句从该文件中把模块内容加载进来。因此我们可以认为,模块 `front_of_house` 的定义还是在 `src/lib.rs` 中,只不过模块的具体内容被移动到了 `src/front_of_house.rs` 文件中。
在这里出现了一个新的关键字`use`,联想到其它章节我们见过的标准库引入`use std::fmt;` 可以大致猜测,该关键字用来将外部模块中的项引入到当前作用域中来,这样无需冗长的父模块前缀即可调用: `hosting::add_to_waitlist();`,在下节中,我们将对`use`进行详细的讲解。 在这里出现了一个新的关键字 `use`,联想到其它章节我们见过的标准库引入 `use std::fmt;`,可以大致猜测,该关键字用来将外部模块中的项引入到当前作用域中来,这样无需冗长的父模块前缀即可调用`hosting::add_to_waitlist();`,在下节中,我们将对 `use` 进行详细的讲解。

Loading…
Cancel
Save