Parcours
/
Cairo
Cairo
/
Exercices
/
Rouge contre Bleu : à la manière de Darwin
Rouge contre Bleu : à la manière de Darwin

Rouge contre Bleu : à la manière de Darwin

Exercice d'apprentissage

Introduction

Modules

Les modules permettent de regrouper du code lié, afin d'éviter les conflits de noms, et on en trouve dans quasiment toutes les bases de code, sauf les plus triviales.

La syntaxe est la suivante :

mod my_module {
    pub struct MyStruct {}

    pub struct OtherClass {}
}

En dehors de la portée du module, les types contenus dans des modules sont désignés en préfixant leur nom du double deux-points ::. Sinon, et c'est le cas le plus courant, tu peux placer une directive use en haut du fichier (ou à l'intérieur d'un module), et les types s'utilisent alors sans préfixe. Au sein d'un même module, il n'est pas nécessaire de qualifier les noms de types.

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 {};
        }
    }
}

Tu peux créer un alias d'un module ou d'un type avec la syntaxe use core::array::ArrayTrait as Arr;, puis utiliser cet alias partout où ce module ou ce type peut être utilisé.

Instructions

La direction commence à appliquer des principes darwiniens à un projet de voiture télécommandée. Les développeurs ont été répartis en deux équipes, Red et Blue, et ont pour mission d'améliorer la conception chacune de son côté. Ils n'ont pas à se préoccuper des choix de conception de l'autre équipe. On t'a demandé de jeter un œil au code et de voir comment combiner au mieux les deux efforts à des fins de test.

1. Trouve un moyen plus approprié d'isoler le code des deux équipes

Utilise des modules pour mieux exprimer l'intention du code.

Pour l'instant, les types importants comme Motor et Telemetry, sans parler de RemoteControlCar lui-même, sont préfixés par la couleur de l'équipe correspondante, <Color>RemoteControlCarTeam. La seule raison d'être de ce préfixe est de permettre à des types portant le même nom de coexister dans le programme. Un module permet de l'exprimer bien mieux. Tu verras que, pour ce genre de besoins, un module présente des avantages par rapport au préfixage des types.

2. Simplifie le système de nommage

La direction exige que les équipes soient appelées « Red Remote Control Car Team » et « Blue Remote Control Car Team » dans les définitions, et que ces noms longs soient même utilisés dans le code lui-même. Toutefois, ces noms sont assez lourds quand on doit faire référence aux équipes.

Trouve un moyen d'utiliser les identifiants plus courts « Red » et « Blue » dans le module où tu construiras les voitures.

Modifie via GitHub Le lien s'ouvre dans une nouvelle fenêtre ou un nouvel onglet
Cairo Exercism

Prêt à commencer Rouge contre Bleu : à la manière de Darwin ?

Inscris-toi sur Exercism pour apprendre et maîtriser Cairo avec 25 concepts68 exercices, et un vrai mentorat humain, le tout gratuitement.