트랙
/
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; 문법으로 모듈이나 타입에 별칭을 붙일 수 있고, 그러면 모듈이나 타입을 쓸 수 있는 곳 어디에서나 그 별칭을 사용할 수 있어요.

지침

경영진이 원격 조종 자동차 프로젝트에 다윈의 원칙을 적용하기 시작했어요. 개발자들은 _Red_와 Blue 두 팀으로 나뉘었고, 서로 독립적으로 설계를 개선하는 임무를 맡았어요. 다른 팀의 설계 결정까지 신경 쓸 필요는 없어요. 여러분은 코드를 살펴보고, 테스트를 위해 두 팀의 작업을 어떻게 하면 가장 잘 합칠 수 있을지 알아봐 달라는 요청을 받았어요.

1. 두 팀의 코드를 분리하는 더 알맞은 방법 찾기

코드의 의도를 더 잘 드러낼 수 있도록 모듈을 사용해 보세요.

현재 Motor와 Telemetry 같은 중요한 타입들은 물론 RemoteControlCar 자체까지, 해당 팀의 색을 접두사로 붙여 <Color>RemoteControlCarTeam이라고 부르고 있어요. 이 접두사의 유일한 목적은 같은 이름을 가진 타입들이 프로그램 안에서 함께 존재할 수 있게 하는 것뿐이에요. 이런 의도는 모듈을 사용하면 더 잘 표현할 수 있어요. 이런 목적에서는 타입에 접두사를 붙이는 것보다 모듈이 더 유리하다는 것을 알게 될 거예요.

2. 이름 체계 단순화하기

경영진은 정의에서 팀을 "Red Remote Control Car Team"과 "Blue Remote Control Car Team"이라고 불러야 하며, 이 긴 이름을 코드 자체에서도 사용해야 한다고 요구해요. 하지만 팀을 참조할 때 이 이름들은 꽤 번거로워요.

자동차를 만들 모듈 안에서 더 짧은 식별자인 "Red"와 "Blue"를 사용할 방법을 찾아보세요.

GitHub에서 편집 링크가 새 창이나 탭에서 열려요
Cairo Exercism

레드 vs. 블루: 다윈 스타일 문제를 시작해 볼 준비가 됐나요?

Exercism에 가입하고 Cairo 트랙을 개념 25개연습 문제 68개, 그리고 실제 사람의 멘토링과 함께 배우고 익혀 보세요. 모두 무료예요.