トラック
/
Cairo
Cairo
/
演習
/
赤 vs. 青:ダーウィン流
赤 vs. 青:ダーウィン流

赤 vs. 青:ダーウィン流

学習演習

はじめに

モジュール

モジュールは、関連するコードをまとめて名前の衝突を避けるための仕組みで、ごく単純なコードベースを除けば、たいていどのコードベースにも登場します。

構文は次のとおりです。

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;という構文を使えば、モジュールや型に別名を付けられます。そうすれば、そのモジュールや型を使える場所ならどこでも、別名を使えます。

説明

経営陣は、ラジコンカーのプロジェクトにダーウィン的な原則を適用し始めました。 開発者たちは2つのチーム、_Red_と_Blue_に分けられ、それぞれが独立して設計を改善する任務を負っています。 互いのチームの設計上の決定に関わる必要はありません。 あなたは、コードを見て、テストのために2つの取り組みをどううまく統合できるかを検討するよう依頼されました。

1. 2つのチームのコードを分離する、より適切な方法を見つける

コードの意図をよりよく表すために、モジュールを使ってみてください。

現在、MotorやTelemetryといった重要な型には、RemoteControlCar自体は言うまでもなく、それぞれのチームの色に対応する<Color>RemoteControlCarTeamという接頭辞が付いています。 この接頭辞の唯一の目的は、同じ名前の型をプログラム内で共存させることです。 これは、モジュールを使うことでよりうまく表現できます。 こうした目的には、型に接頭辞を付けるよりもモジュールを使うほうが有利だとわかるでしょう。

2. 命名の仕組みをシンプルにする

経営陣は、定義の中でチームを"Red Remote Control Car Team"と"Blue Remote Control Car Team"と呼ぶこと、そしてこれらの長い名前をコード自体でも使うことを求めています。 しかし、チームを参照するときには、これらの名前はかなり煩わしいものです。

これから車を組み立てていくモジュールの中で、より短い識別子"Red"と"Blue"を使う方法を見つけてください。

GitHubで編集する リンクは新しいウィンドウまたはタブで開きます
Cairo Exercism

赤 vs. 青:ダーウィン流を始める準備はできましたか?

Exercismに登録すれば、25個のコンセプト68個の演習、そして本物の人間によるメンタリングとともに、Cairoを学んでマスターできます。すべて無料です。