[레벨 1] 01. 1단계 - 자동차 경주 구현

## 🛠 구현 기능 목록

* [x] 경주할 자동차의 이름을 입력한다.
* [x] 각 자동차의 이름은 `쉼표(,)`를 기준으로 구분한다.
* [x] 시도할 회수를 입력한다.
* [x] 시도할 회수는 `0이상` 이다.
* [x] 시도할 회수는 `숫자 이외의 값` 또는 `음수`를 전달할 경우 `예외를 throw` 한다.
* [x] 자동차의 이름은 `5자 이하`이다.
* [x] 자동차의 이름이 `6자 이상`이면 `예외 throw` 한다.
* [x] 자동차의 이름은 `null`, `''`, `' '` 이 올 수 없다.
* [x] 자동차의 이름이 `중복`될 경우 `예외를 throw` 한다.
* [x] 시도할 회수만큼 자동차는 움직일 수 있다.
* [x] 회수마다 `전진하는 조건을 판단`하여 자동차를 이동시킨다.
* [x] `0에서 9 사이에 random 값`을 구한 후 `random 값이 4 이상` 인 경우 `전진`하고, `3 이하`인 경우 멈춘다.
* [x] 실행 결과를 출력한다.
* [x] 경주가 완료된 후 현재 위치를 확인한 뒤 우승자를 출력한다.
* [x] 우승자는 한 명 이상일 수 있다.
* [x] 입력에 실패할 경우 `예외를 catch`하고 `재입력` 받는다.

나중에 프로젝트가 커지게되면 요구사항을 그룹화해서 나눠보는것도 좋을거에요.
자동차라는 그룹 하위에 이름에 대한 정책들, 움직임에 대한 정책들 같이요.
지금도 충분히 좋아요~

정말 잘 나누어주셨네요 👍
저는 개인적으로 문서화가 굉장히 중요하다고 생각해요. 협업하는 사람들 혹은 새로합류하는 사람들을 위해서 큰 도움이 됩니다.
큰 장점을 가지신것같아요. 나중에 많은 도움이 될거에요!

자동차의 이동 유무를 판단하기 위한 전략 패턴을 사용하였습니다. 
Car 객체를 생성하는 시점에 전략을 정할 수 있어서 유연하게 이동과 관련된 단위 테스트를 진행할 수 있었습니다. 
후에 이동에 대한 다른 요구사항이 추가된다면 구현체를 추가하고 교체하는 행위로 쉽게 변경이 가능할 것으로 판단됩니다! 
이번에 전략 패턴을 적용하며 위와 같은 장점 들을 알 수 있었습니다.

네 저도 매트가 이야기한 코드의 유연성, 테스트의 용이성 측면에서 좋은 선택이라고 생각해요!

public class Car {
    private final CarName name;
    private int position;
    private final MovingPolicy movingPolicy;

    public Car(String name, MovingPolicy movingPolicy) {
        this.name = new CarName(name);
        this.position = 0;
        this.movingPolicy = movingPolicy;
    }

    public void move() {
        if (movingPolicy.isMovable()) {
            position++;
        }
    }

    public String getName() {
        return name.getName();
    }

    public int getPosition() {
        return position;
    }
}

public class Car {
    private final CarName name;
    private int position;

    public Car(String name) {
        this.name = new CarName(name);
        this.position = 0;
    }

    public void move(MovingPolicy movingPolicy) {
        if (movingPolicy.isMovable()) {
            position++;
        }
    }

    public String getName() {
        return name.getName();
    }

    public int getPosition() {
        return position;
    }
}

지금 상황에서라면 1번 모습이 더 낫습니다. 
자동차의 움직임이 변경되는 요구사항이 없기 때문에 굳이 move를 할때마다 전략을 넘겨주는 행위는 불필요하다고 생각해요.
추후에 예를 들어, 객체에 매번 메세지를 보낼때마다 행위가 달라져야하는 요구사항이 생긴다면 2번으로 코드를 작성해도 될 것 같아요. 
혹은 클래스내에 전략을 List로 가지고있고 인자값을 받은 후 맞는 전략을 선택해서 실행하게끔요.

public class AA {
    private final List<AAPolicy> AAPolicies;

정리하면 잘못된건 없고 필요에 맞춰서 유연하게 사용하는것이 중요하다고 생각해요! 

public class Car {
    private final String name;
    ...
    
    public Car(String name, MovingPolicy movingPolicy) {
        validateNull(name);
        validateEmpty(name);
        validateBlank(name);
        validateNameLength(name);
        this.name = name;
        ...
    }

    private void validateNull(String name) {
        if (name == null) {
            throw new IllegalArgumentException();
        }
    }
    private void validateEmpty(String name) {
        if (name.isEmpty()) {
            throw new IllegalArgumentException();
        }
    }
    private void validateBlank(String name) {
        if (name.isBlank()) {
            throw new IllegalArgumentException();
        }
    }
    private void validateNameLength(String name) {
        if (name.length() > 5) {
            throw new IllegalArgumentException();
        }
    }
    ...
}

public class CarName {
    private final String name;

    public CarName(String name) {
        validateNull(name);
        validateEmpty(name);
        validateBlank(name);
        validateNameLength(name);
        this.name = name;
    }

    private void validateNull(String name) {
        if (name == null) {
            throw new IllegalArgumentException("이름은 null이 될 수 없습니다.");
        }
    }

    private void validateEmpty(String name) {
        if (name.isEmpty()) {
            throw new IllegalArgumentException("이름이 비어 있습니다.");
        }
    }

    private void validateBlank(String name) {
        if (name.isBlank()) {
            throw new IllegalArgumentException("이름은 공백이 될 수 없습니다.");
        }
    }

    private void validateNameLength(String name) {
        if (name.length() > 5) {
            throw new IllegalArgumentException("이름은 5자를 초과할 수 없습니다.");
        }
    }

    public String getName() {
        return name;
    }
}

public class Car {
    private final CarName name;
    private int position;
    private final MovingPolicy movingPolicy;

    public Car(String name, MovingPolicy movingPolicy) {
        this.name = new CarName(name);
        this.position = 0;
        this.movingPolicy = movingPolicy;
    }

    public void move() {
        if (movingPolicy.isMove()) {
            position++;
        }
    }

    public String getName() {
        return name.getName();
    }

    public int getPosition() {
        return position;
    }
}

어떤 행위를 할때는 필요에 의해서 하는게 중요하다고 생각해요. 무조건 객체 포장해야지 가 아니라 왜 포장을 해야될까를 생각해보고 하는것이 중요합니다.
매트가 조치를 한 내용을 보니 잘 하신것으로 보여요.

* Car에서 이름검증 수행
* 역할이 너무 많아짐을 인지
* 분리의 필요성 인지

public class CarName {
    private final String name;

    public CarName(String name) {
        ...
        validateNameLength(name);
        this.name = name;
    }
    ...
    private void validateNameLength(String name) {
        if (name.length() > 5) {
            throw new IllegalArgumentException("이름은 5자를 초과할 수 없습니다.");
        }
    }
    ...
}

메서드에서 이름을 검증한다는 것은 드러납니다.
하지만 이 이름의 길이인 5라는 값을 해당 메서드 말고 다른곳에서 쓰이면 어떻게 될까요? 모두 5라는 숫자가 들어가야합니다.
혹여나 길이에 대한 정책이 바뀌게되면 모든 5를 전부 찾아서 바꿔야되겠죠. 실수로 한 부분을 바꾸지 않는다면 장애가 날 수도 있습니다.

현재 위와 같은 모습으로 보이는데요, Controller가 domain패키지에 위치하는것이 맞을까요?
자동차 만을 위한 정책이 들어가야 domain패키지의 역할에 맞다고 생각해요. Controller에 view를 의존하고있는데 domain이 controller를 가지게되면 view도 가지게 되는 꼴이됩니다. controller를 다른 패키지로 옮겨보면 어떨까요?

public class InputView {
    private static final String INPUT_NAMES_MESSAGE = "경주할 자동차 이름을 입력하세요(이름은 쉼표(,)를 기준으로 구분).";
    private static final String SPLIT_REGEX = ",";
    private static final int SPLIT_LIMIT = -1;
    private static final String INPUT_COUNT_MESSAGE = "시도할 회수는 몇회인가요?";

    public static String[] getCarNames() {
        System.out.println(INPUT_NAMES_MESSAGE);
        String input = Console.readLine();
        return input.split(SPLIT_REGEX, SPLIT_LIMIT);
    }

    public static Count getCount() {
        System.out.println(INPUT_COUNT_MESSAGE);
        return new Count(Console.readLine());
    }
}

한마디로 정리하면 `view에서 domain을 생성해도 되는가?` 에 대한 질문으로 이해하였어요. 아니라면 재차 말씀부탁드려요.

현재 구조에서는 사실 뷰에서는 정말 input값만 가지고 컨트롤러로 넘어와서 컨트롤러에서 Count(도메인)을 new 해주는게 역할분리에 있어서 더 맞아보입니다.

지금 당장에 코드수정보다는 mvc 구조에 대해서 서치를 해보고 본인만의 지식으로 만들어보면 어떨까요?
여력이 된다면 수정해보시고, 조금더 레퍼런스를 찾아보고싶으시면 찾아보고 스레드로 남겨주시는것도 좋아요~
개인적으로는 추후에 코드적으로 경험할 일이 많으니 레퍼런스를 더 찾아보시는걸 추천드립니다.

public class InputView {
    private static final String INPUT_NAMES_MESSAGE = "경주할 자동차 이름을 입력하세요(이름은 쉼표(,)를 기준으로 구분).";
    private static final String SPLIT_REGEX = ",";
    private static final int SPLIT_LIMIT = -1;
    private static final String INPUT_COUNT_MESSAGE = "시도할 회수는 몇회인가요?";

    public static String[] getCarNames() {
        System.out.println(INPUT_NAMES_MESSAGE);
        String input = Console.readLine();
        return input.split(SPLIT_REGEX, SPLIT_LIMIT);
    }

    public static int getCount() {
        System.out.println(INPUT_COUNT_MESSAGE);
        return Console.readLine();
    }
}

public class RacingCarController {
    ...
    private Count getCount() {
        try {
            return new Count(InputView.getCount());
        } catch (IllegalArgumentException e) {
            OutPutView.printErrorMessage(e.getMessage());
            return getCount();
        }
    }
    ...
}

리뷰를 받는 사람은 이 사람이 왜 이렇게 이야기를 했을까를 고민하는것이 우선이 되어야한다고 생각해요. 하지만 더 중요한것은 리뷰어의 말이 전적으로 옳다는 아니라는 것입니다.
컨벤션이 잘못되었거나 요구사항대로 돌지 않는 버그가 있거나 하는 객관적인 것들은 다 반영이 되어야하는 부분이지만, 답이 없는 문제들 (예를 들면, 설계나 코딩 스타일 같은) 에 대해서는 사람마다 생각하는 것이 다르기 때문에 매트가 어떻게 생각하느냐가 더 중요해요.

같은 코드를 봐도 각자 본인만의 스타일이 있기 때문에 리뷰어들마다 다른 피드백이 올 수 있어요. 그 때마다 무조건적으로 받아들이게 되면 본인만의 아이덴티티가 모호해질 수 있어요. (아닌것같다고 생각하는 부분은 꼭 반론을 제시하시구요)
지금은 초반이라 걱정하지 않으셔도되지만 우테코가 끝날때쯤에는 매트는 어떤 스타일을 가진 개발자다 라는걸 어느정도 만들었으면 좋겠어요!

리뷰를 진행하실 때 중점적으로 살펴보는 태도에 대해서도 질문을 주셨는데, 저는 소통이 잘 되는걸 먼저 봐요. 어떤 코멘트를 남겼을때 긍정의 이모지 혹은 코멘트를 남기거나, 혹은 다르게 생각하면 반론의 스레드를 남기거나 하는것들이에요. 아무것도 달지 않으면 어떻게 생각하는지 알 수가 없으니까요. 매트는 잘 해주고 계셔서 걱정하지 않으셔도되어요!