模块是一种把相关代码组织在一起的方式,可以用来避免命名冲突。除了极其简单的代码库,几乎所有的代码库中都有模块。
语法如下:
mod my_module {
pub struct MyStruct {}
pub struct OtherClass {}
}
在模块的作用域之外引用模块里的类型时,需要在类型名前加上双冒号::语法。
另一种做法更常见:在文件顶部(或模块内部)加上use指令,之后使用这些类型就不需要加前缀了。
在同一个模块内部,不需要为类型名加限定。
mod my_module {
#[derive(Drop)]
pub struct MyStruct {}
pub struct Foo {}
#[generate_trait]
pub impl FooImpl of FooTrait {
fn bar() {
let baz = MyStruct {};
}
}
}
#[derive(Drop)]
pub struct Qux {}
#[generate_trait]
impl QuxImpl of QuxTrait {
fn box() {
let nux = my_module::MyStruct {};
}
}
mod other_module {
use super::my_module::*;
#[derive(Drop)]
pub struct Tix {}
#[generate_trait]
pub impl TixImpl of TixTrait {
fn jeg() {
let lor = MyStruct {};
}
}
}
你可以用use core::array::ArrayTrait as Arr;这样的语法给模块或类型起一个别名,之后凡是能使用该模块或类型的地方,都可以使用这个别名。
管理层开始把达尔文主义原则应用到遥控车项目中。 开发者被分成两个团队:Red 和 Blue,各自独立改进设计。 他们无需关心另一个团队的设计决策。 现在需要你查看代码,思考如何把两者的成果最好地结合起来,以便进行测试。
请使用模块来更好地表达代码的意图。
目前,像Motor和Telemetry这样的重要类型,更不用说RemoteControlCar本身,都加上了对应团队颜色的前缀<Color>RemoteControlCarTeam。
这个前缀的唯一目的,就是让同名类型能够在同一个程序中共存。
使用模块可以更好地表达这一点。
你会看到,就这些目的而言,模块比给类型加前缀更有优势。
管理层要求在定义中这两个团队应被称为“Red Remote Control Car Team”和“Blue Remote Control Car Team”,而且这些长名称还要在代码本身中使用。 不过,在引用这两个团队时,这些名称相当累赘。
找到一种方法,在你构建汽车的模块内使用更短的标识符“Red”和“Blue”。