[그리디] 이규형 자동차 경주 미션 3, 4단계 제출합니다.

[Leeguhyung]

안녕하세요! 이수현 리뷰어님
3,4단계 코드 리뷰 잘 부탁드립니다!

패키지 / 클래스 구조

Application.java              # 입력/출력을 조립하는 실행 진입점(main 메서드)

domain
├── Car.java                  # 이름과 위치를 가지며, 4 이상이면 전진
├── Cars.java                 # n대의 Car를 리스트로 관리, 이름 배열로 Cars를 생성하는 정적 팩토리(createCars) 포함
├── RandomNumber.java         # 랜덤 값 생성 인터페이스
├── DefaultRandomNumber.java  # RandomNumber의 실제 구현체 (0~9 사이 랜덤 값)
└── RacingGame.java           # 한 라운드씩 경주를 진행

view
├── InputView.java            # 자동차 이름/시도 횟수 입력받기
└── ResultView.java           # 라운드별 진행 상황, 최종 우승자 출력

test/domain
├── CarTest.java              # 전진/정지, 이름 검증(null/blank/5자 초과) 테스트
├── CarsTest.java             # 이동, 우승자 판별, 이름 배열로 생성하는 로직 테스트
└── FixedRandomNumber.java    # 테스트용 고정값 RandomNumber 구현체

1,2단계 미션 당시 마지막에 반영 요청이 있었던 테스트 코드의 이름과 메인에 있는 클래스 이름을 맞추는것이 좋다고 해서 반영하였습니다.
[refactor: RacingGame이 한 라운드씩 경주를 진행하도록 수정 ] 이 커밋부터 3,4 단계 미션 시작하는 부분임을 알려드립니다!

질문 및 고민사항

1. 4단계 리팩토링 힌트를 보고선 폴더 구조를 나누어 보았습니다. 아직 생소한 구조라서 알아보았는데 Model , View, Controller가 각각 데이터 처리, 화면 출력, 제어를 담당하게끔 나눈다고 적혀있었습니다. 이와 같이 폴더구조를 나누었을떄 얻을 수 있는 이점이 뭔지 리뷰어님의 생각이 궁금합니다! 그리고 또한 제가 지금 코드를 mvc에 맞게 잘 나눈건지도 궁금합니다. 2,3,4,5,6번 질문은 mvc 구조로 나누기전 작성된 것임을 알려드립니다.

2. 스터디 과정에서 인터페이스를 적용하면 메서드 약속만 정의하고 실제 동작은 여러 형태로 찍어낼 수 있어서, 난수값임에도 고정된 값으로 결정론적(예측 가능)하게 테스트가 가능하다고 배워서 반영하였는데, RandomNumber(인터페이스)와 DefaultRandomNumber(구현체)를 같은 패키지 안에 나란히 두는 게 맞는 건지 확신이 안 섰습니다. 혹시 interface만 따로 폴더를 만들어서 관리하는 형태는 어떤지 궁금합니다.

3. Application(구 Main) class를 구성할 때 안에 메소드들을 최대한 기능별로 쪼개서 구성을 했는데, 아직 클래스 즉 객체 또는 메소드를 쪼개는 기준점에 대해 확신이 없어서 명확한 기준점을 판단하는 방법이 있을까요?

4. 처음에는 createCars를 Application(구 Main)에다가 위치해놨었는데, 의미가 자동차들을 모아두는 걸 생성하는 것이다 보니 Cars로 옮겼습니다. 적절하게 잘 옮긴 걸까요?

5. 테스트를 어디까지 짜야 할지 감이 잘 오지 않습니다. 우선은 제가 필요하다고 생각한 부분에서는 대부분 짰는데, 놓치고 있는 부분이나 "이런 경우라면 테스트를 짜야 한다"는 기준점, 관점이 있을까요?

6. 아래 코드를 보면 시도 횟수만큼 경주를 시키는 건데, 경주가 한 번 돌 때마다 출력을 해야 해서 출력을 중간에 넣어놨습니다.

   private static void raceCars(Cars carsList, int tryCount) {
       DefaultRandomNumber defaultRandomNumber = new DefaultRandomNumber();
       RacingGame racingGame = new RacingGame(carsList, defaultRandomNumber);
       for (int i = 0; i < tryCount; i++) {
           racingGame.carRaceOnce();
           //경주할때마다 값 출력하기
           printRound(carsList);
       }
   }

경주와 출력이 같이 있는 느낌이라 분리를 하고 싶은데 잘 생각이 나지 않습니다. 이정도는 그대로 놔둬도 괜찮은 걸까요? 아니면 따로 수정이 더 필요한 부분일까요?

[soohyun1904]

주석에 학습하신 내용을 정리해두셨네요. 찾아보고 기록하는 습관은 좋습니다.

다만 주석의 용도를 한번 생각해보시면 좋겠어요. repeat()나 String.join()이 무슨 메서드인지는 나중에 이 코드를 읽는 사람에게 필요한 정보일까요? 코드를 보면 알 수 있는 걸 다시 설명하는 주석은 시간이 지나면 잘 안 맞게 되기도 하고요.

보통 주석은 코드만으로는 알 수 없는 것을 적을 때 값어치가 있다고 봅니다. 왜 이렇게 했는지, 왜 이 방법을 쓰지 않았는지 같은 거요.

[Leeguhyung]

말씀해주신 부분에 공감합니다. 자바를 처음 배우다 보니 새로 알게 된 메서드(repeat(), String.join() 등)를 바로 기록해두고 싶어서 주석으로 남겼는데, 돌아보니 코드를 읽는 분께 필요한 정보가 아니라 제 학습 메모였던 것 같습니다. 다만 코드를 보면서 바로 복습할 수 있다는 점 때문에 당분간은 학습 메모 주석을 유지하고 싶습니다.(주석에 //[학습] 붙여서 구분 시키겠습니다) 대신 "왜 이렇게 했는지, 왜 이 방법을 쓰지 않았는지"를 적은 주석을 추가하는 습관을 길러보도록 하겠습니다,

[soohyun1904]

이 부분 좋은 것 같습니다. get 메소드로 호출 후 겪을 수 있는 문제를 막아두셨네요.

[Leeguhyung]

감사합니다! 더 좋은 코드 보여드릴 수 있도록 하겠습니다.

[soohyun1904]

위치를 항상 0에서 시작하도록 고정하셨는데, 그러면 특정 위치에 있는 자동차를 만들 방법이 없어집니다. CarsTest에서 우승자 판별을 테스트하실 때 자동차를 움직이는 코드가 꽤 들어가지 않으셨나요?

검증하려는 건 우승자를 고르는 규칙인데 거기까지 도달하는 과정이 테스트의 대부분을 차지하게 되거든요. 위치를 받는 생성자가 하나 더 있으면 어떨까요?

[Leeguhyung]

반영하였습니다. 말씀해주신 대로 우승자 판별 테스트에서 moveIfPossible()로 위치를 옮기는 테스트로 구성했었고, 4, 5가 "전진 조건을 만족하는 값"이라는 걸 알아야 읽혀서 이동 조건이 바뀌면 우승자 테스트도 같이 깨질 수 있다는 점을 느꼈습니다. 그래서 Car가 위치를 생성자로 받도록 변경했고 게임에서는 항상 0에서 시작하도록 Cars.createCars()에서 new Car(name.trim(), 0)으로 시작 위치를 넘기도록 했습니다.

우승자 테스트는 new Car("A", 7), new Car("B", 2)처럼 위치를 직접 지정해서 전진 과정 없이 우승자 규칙만 검증하도록 수정했습니다. 이제 우승자 판별만을 위한 테스트 코드가 된 것 같습니다.

[soohyun1904]

이름 검증을 생성자에서 하고 계시네요. 잘못된 상태의 객체가 아예 못 만들어지게 막은 것 좋습니다.

한 걸음 더 가보면, 지금 이름은 String이라 Car 밖으로 나가는 순간 그냥 문자열이 됩니다. getCarName()으로 꺼낸 값을 다른 곳에서 다루게 되면 검증은 따라가지 않죠. 이름에 관한 규칙이 이름 자신에게 붙어 있으면 어떨까요? 그러면 그 타입이 존재한다는 것만으로 검증을 통과했다는 게 보장되고, Car는 이름 규칙을 몰라도 됩니다.

"원시값 포장"으로 찾아보시면 방향이 잡힐 겁니다.

[Leeguhyung]

읽어보았을때 별도로 carName 같은 클래스를 만들어서 그쪽에서 처리하자라는 뜻으로 이해했는데. 이렇게 되면 이름만 받아내는 것이라 객체를 흉내내기만 하는 경우가 발생할 것 같은데 어떻게 생각하시나요?

[soohyun1904]

좋은 지적입니다. 실제로 값만 감싸고 getValue() 하나만 있는 클래스는 말씀하신 대로 객체를 흉내만 내는 셈이 되고, 원시값 포장을 두고 자주 나오는 비판이기도 해요.

다만 저는 검증 자체가 이미 행동이라고 봅니다. CarName이 생성될 때 규칙을 확인한다면, 그 타입을 받은 쪽은 "이건 올바른 이름"이라는 걸 따로 확인할 필요가 없어지죠. 지금은 그 보장이 Car 생성자 안에서만 유효하고요.

그리고 행동은 앞으로 더 붙을 수 있습니다. 예를 들어 같은 이름의 자동차를 막아야 한다면 이름끼리 같은지 비교해야 하는데, 그 비교를 누가 하는 게 자연스러울까요?

사실 정답은 없고 기준이 다를 뿐입니다. 지금 구조에서 이름에 붙을 행동이 검증 하나뿐이라 과하다고 판단하신다면, 그 판단도 충분히 납득이 갑니다. 이유가 있는 선택이면 그대로 두셔도 좋아요.

[Leeguhyung]

아직 제가 엄청난 판단을 할 수 있는 지식이 있진않지만 이 부분 같은 경우는 흉내낸다는 느낌이 먼저 왔기에 유지하도록 하겠습니다.

[soohyun1904]

공동 우승 케이스를 테스트하신 것 좋습니다. 구현하다 보면 우승자가 한 명이라고 생각하기 쉬운데, 여러 명일 수 있다는 걸 놓치지 않으셨네요. 이렇게 "보통은 이렇지만 가끔 저럴 수도 있는" 경우를 테스트로 잡아두면 나중에 코드를 고칠 때 안전망이 됩니다.

[Leeguhyung]

감사합니다!

[soohyun1904]

이런 걸 정적 팩토리 메서드라고 하는데, 이름 배열에서 Cars를 만드는 책임을 Cars자신이 가진 것 좋습니다.

시간이 남으시면 생성자와 어떤 차이가 있는지 한번 찾아보세요. 이름을 붙일 수 있다는 것 말고도 몇 가지가 더 있습니다.

생성자의 특징에 대해 알면 조금 좋을 것 같아요.

[Leeguhyung]

네 알겠습니다! 정적 팩토리 메서드와 생성자 차이 확인후 코멘트 추가로 남기겠습니다.

[soohyun1904]

이 부분 추가적으로 알려주시면 좋을 거 같아요.

[Leeguhyung]

차이점에 대해서 말씀드리겠습니다.
첫 번째, 이름을 붙일 수 있습니다. 생성자는 클래스 이름만 쓸 수 있지만, 정적팩토리메서드는 createCars처럼 무엇을 만드는지 드러낼 수 있습니다.
두 번째, 정적팩토리 메소드에서는 new 처럼 새 객체를 계속해서 선언하지 않아도 됩니다.

[soohyun1904]

지금 같은 이름의 자동차를 여러 대 만들 수 있는데, 경주에서 이게 허용되어야 할까요? 출력에서 누가 누군지 구분이 안 될 것 같은데요. 만약 막아야 한다면 그 판단은 누가 할 수 있을까요?

[Leeguhyung]

듣고보니 맞는 말씀입니다. 제가 놓치고 있었던 예외사항중 하나였던 것 같습니다

    private void validateNoDuplicateNames(List<Car> cars) {
        Set<String> duplicateNames = new HashSet<>(); //[학습] Set은 중복을 허용하지 않는 자료구조
        for (Car car : cars) {
            if (!duplicateNames.add(car.getCarName())) { //false면 중복이니까
                throw new IllegalArgumentException("자동차 이름은 중복될 수 없습니다.");
                //중복 검증을 하여, 동일한 이름의 자동차가 존재하면 예외를 발생시킵니다.
            }
        }
    }

이와 같은 메소드를 추가하여 중복일 경우 예외처리가 가능하도록 추가해놓았습니다.

[Leeguhyung]

또한 예외검증 추가로 테스트코드도 추가할 필요가 있어보여 추가완료하였습니다.

[soohyun1904]

우승자를 별도 메서드로 나눠서 판단하신 것 좋습니다.

다만 addWinnerIfMatch()가 파라미터로 받은 winners를 직접 수정하고 있는데, 이런 코드는 나중에 위험해질 수 있습니다. 메서드 이름만 보면 판단만 할 것 같은데 실제로는 리스트를 바꾸고 있어서, 호출하는 쪽에서는 언제 무엇이 변경됐는지 추적하기 어려워지거든요. 리스트가 안 바뀐 줄 알았는데 바뀌어 있으면 원인을 찾는 데 시간이 오래 걸립니다.

파라미터를 고치는 대신 값을 반환하도록 바꿔보시면 어떨까요? 그러면 이 메서드가 뭘 하는지가 시그니처만 봐도 드러납니다.

참고로 findWinner()도 이름이 단수인데 여러 명을 반환하고 있어서, findWinners()가 더 자연스러워 보입니다.

[Leeguhyung]

아직 직접 리스트를 넘겼을때 추적하기 어려워진다는점이 아직까지 와닿는 말은 아니지만 반영하였습니다.

public List<Car> findWinners() {
        //최대위치인 차만 고르면됨
        int maxPosition = getMaxPosition();
        List<Car> winners = new ArrayList<>();
        for (Car car : cars) {
            winners.addAll(winnerOf(car, maxPosition)); //[학습] addAll은 다른 리스트의 요소를 통째로 추가하는 메서드임
        }
        return winners;
    }
    //add로 하면 값을 car로 받아야하는데 이때 우승자가 없는경우 반환값을 정하기 어려워 addAll 사용

    //winnerOf()는 우승자면 그 차 한 대짜리 리스트를, 아니면 빈 리스트를 반환만 합니다
    private List<Car> winnerOf(Car car, int maxPosition) {
        if (car.samePosition(maxPosition)) {
            return List.of(car);
        }

        return List.of();
    }

위와같은 형태로 바꿔보았습니다.

처음에는 Car를 반환하고 add로 넣는 방법도 생각했는데, 우승자가 아닌 경우에 반환할 값이 없어서(null이 or if사용) 우승자면 한 대짜리 리스트, 아니면 빈 리스트를 반환하고 addAll로 합치는 방식으로 했습니다. 규칙상 indent depth를 1까지만 허용해서 for 안에서 if를 쓰지 않으려는 이유도 있었습니다
이름도 findWinners()로 변경 완료하였습니다.

[soohyun1904]

솔직하게 말씀해주셔서 좋습니다. 『클린 코드』 3장에 이 얘기가 나오는데, 인수는 보통 "넣어주는 값"으로 읽히기 때문에 그걸로 결과를 받아오면 읽는 사람의 예상이 어긋난다는 겁니다. 지금은 코드가 짧아 괜찮지만, 그 리스트를 다른 곳에서도 쓰고 있었다면 "누가 값을 넣었지?"를 찾으러 호출한 곳을 다 뒤져야 하죠.

[soohyun1904]

안녕하세요, 규형님. 리뷰어 달수입니다.

먼저 코드 전반이 깔끔합니다. 질문을 여섯 개나 정리해서 올려주신 것만 봐도 그냥 돌아가게만 만든 게 아니라는 게 보이네요.

1번

먼저 규형님이 어떤 기준으로 MVC를 나누셨는지 들어보고 싶습니다. 폴더를 나눈 이유를 직접 말로 정리해보시면 그 과정에서 얻는 게 있을 것 같아서요. 그 다음에 제 의견을 말씀드리겠습니다.

다만 힌트를 하나 드리면, 찾아보신 MVC 그림에서 화살표가 어디서 어디로 가는지 한번 확인해보세요.

DTO, 의존 방향, MVC는 이 대답을 듣고 리뷰하고 답해보겠습니다.

2번

도메인 내부에서 외부 API를 써야 하거나 할 때는 구현체를 다른 곳에 두기도 합니다. 다만 아키텍처 이야기라 나중에 자연스럽게 알게 되실 것 같아 지금은 답하지 않겠습니다.

대신 되묻고 싶은 게 있는데요. 인터페이스와 구현체가 같은 패키지에 있어서 불편하셨던 적이 있나요? 없다면 그대로 두셔도 좋습니다. 지금 보기 편한 코드가 좋은 코드라고 생각합니다. 지금도 충분히 잘 작성하신 것 같아요.

3번

솔직히 말씀드리면 명확한 기준은 없고, 하다 보면 느는 종류의 감각입니다. 다만 저는 이럴 때 이 질문을 씁니다. "이 클래스가 바뀌어야 하는 이유가 몇 개인가?" 화면 형식이 바뀌어도 고쳐야 하고 게임 규칙이 바뀌어도 고쳐야 한다면, 그건 두 가지 이유를 가진 셈이니 나눌 때가 된 거죠.

메서드는 조금 더 단순합니다. 이름을 붙여보려는데 "그리고"가 들어가면 두 개로 나눌 신호입니다.

4번

잘 옮기셨습니다. 이름 배열에서 Cars를 만드는 건 Cars가 제일 잘 아는 일이니까요. Application에 있을 때보다 확실히 나아졌습니다.

다만 지금은 Application이 입력받고 → Cars 만들고 → RacingGame 만들고 → 돌리는 걸 전부 하고 있는데, 이 조립을 누가 맡아야 할지는 1번 답변 주시면 같이 이야기해보죠.

5번

테스트도 정답은 없습니다. 다만 하나 말씀드리면, 꼼꼼하게 짤 부분과 아닌 부분을 구분하시면 좋겠어요. 앱의 핵심이거나 동작이 불분명한 곳은 꼼꼼하게, 눈으로 봐도 확실한 범위는 굳이 추가하지 않는 편입니다.

범위를 알아보는 것도 좋지만 그 전에 테스트는 왜 할까요? 이 질문에 대한 본인의 답이 생기면 어디까지 짤지도 자연스럽게 따라올 겁니다.

6번

저도 똑같은 고민을 했었습니다. 경주와 출력이 한 반복문 안에 있으니 섞여 보이는 게 맞아요.

다만 제 생각엔 이 둘이 붙어 있다는 것 자체보다, 누가 무엇을 알아야 하는가가 먼저인 것 같습니다. 만약 RacingGame이 반복을 돌리면서 출력까지 하게 되면 도메인이 화면을 알아야 하는데, 그게 괜찮은 걸까요?

코드가 좋아서 저도 다시 학습을 한 것 같습니다. 시간 되시면 천천히 보시며 될 것 같아요

---

• .gitkeep은 파일이 없을 때 폴더를 유지하려고 만드는 파일이라, 이제 클래스들이 들어왔으니 삭제하셔도 좋습니다.
• 코드는 작성 후에 한 번 정리하고 올리시면 좋아요. Reformat Code(맥 ⌘⌥L, 윈도우 Ctrl+Alt+L), Optimize Imports(맥 ⌃⌥O, 윈도우 Ctrl+Alt+O)로 정리됩니다. Settings의 Actions on Save에 등록해두면 저장할 때 자동으로 적용돼서 앞으로 신경 안 쓰셔도 되고요.

[Leeguhyung]

1번 답변 : 처음 폴더를 나누게 된것은 4단계 리팩토링 힌트부분에 model view 나누라는 힌트가 있었기에 나누게 되었습니다. 나눈 기준점에 대해 말씀드리겠습니다. 저는 model view를 나눌때 객체라던가 돌아가는 코드에 대해서(아직 model 에 대한 감이 완벽하지 않습니다) Model로 분류를 하였고 입출력이 있는 것들은 view로 배치하였습니다.(6번질문과 이어지는 내용이기도 합니다)
화살표는 model->controller->view->user->controller->model로 순환하는 과정을 거치고있습니다. 이로써 model은 view를 모르고있다? 의존하지 않는 형태이고 view는 model에 거쳐서 오기때문에 의존성을 갖고있어도 된다고 해석해봤습니다. 또한 controller는 model과 view를 이어주고 있는 것으로 보이는데. 우리 코드에서 그럼 컨트롤러는 Application을 말하고 있는 것일까요?
mvc에 대해 틀린 해석이 있다면 피드백 부탁드립니다.

2번 답변: 감사합니다.

3번 답변: 감사합니다. 조금 더 감을찾을때까지 열심히 공부해보겠습니다.

4번 답변: 1번 답을 아직 못들어서 공란으로 남겨두겠습니다.

5번 답변: 테스트는 일일이 사람이 체크하기 힘든 것들을 미리 작성하여. 코드작성의 효율을 높이는 것이라고 생각하고 있습니다.
아직 프로젝트의 크기가 크지 않아 테스트를 한다는 것이 크게 와닿진 않는데요. 나중에 더 큰 규모의 프로젝트를 진행한다면 와닿아질꺼라 생각하고 있습니다. 맞을까요?

6번 답변: 1번에서 정리한 것처럼 RacingGame이 출력까지 하면 domain이 view를 알게 되어 방향이 어긋난다고 생각합니다. 그래서 반복과 출력을 컨트롤러 역할인 Application에서 하는 지금 구조가 맞다고 이해하고 있는데 맞을까요?

[soohyun1904]

지금 RacingGame은 cars.move()를 한 줄 전달하는 것 말고는 하는 일이 없습니다. 이런 클래스는 두 방향 중 하나를 고르면 좋을 것 같아요.

하나는 역할을 주는 겁니다. 지금 Cars가 우승자 판단까지 하고 있는데, "가장 멀리 간 차가 이긴다"는 자동차들의 성질일까요, 경주의 규칙일까요? 시도 횟수도 경주가 알 만한 정보고요.

다른 하나는 없애는 겁니다. 하는 일 없이 전달만 하는 층이라면 오히려 읽는 사람이 한 단계 더 따라가야 하니까요.

어느 쪽이든 괜찮습니다. 규형님이 고르신 방향과 그 이유가 궁금하네요.

[Leeguhyung]

들어보니 말씀하신부분이 맞는 것 같습니다. 그래서 RacingGame에 역할을 주기로 하였습니다.
가장 멀리 간 차가 이긴다는 자동차 목록의 성질이 아니라 경주의 규칙이라고 생각해서, Cars에 있던 findWinners()와 그 내부에서 쓰던 winnerOf(), getMaxPosition()을 RacingGame으로 옮겼습니다. 즉, Cars는 자동차 관리에만 힘쓰고 RacingGame에 우승자 판별까지 넣어서 구분지어놓았습니다.

[Leeguhyung]

시도횟수도 RacingGame이 알만한 부분이라서 그렇게 코드수정하였습니다.

[soohyun1904]

1번

그림을 직접 따라가서 "model은 view를 모른다" 까지 읽어내신 것 좋습니다.
model로 분류한 기준을 "객체, 돌아가는 코드"라고 하셨는데, 감이 완벽하지 않다고 하셨지만 방향은 맞습니다. 게임의 규칙과 상태를 가진 것들이 model이죠.

두 가지를 덧붙이겠습니다.

---

1) 컨트롤러는 따로 있어야 합니다

Application이 컨트롤러냐고 물으셨는데, 지금은 Application이 컨트롤러 역할을 떠맡고 있는 상태라고 보는 게 정확합니다. 입력받고, 자동차를 만들고, 경주를 돌리고, 출력하는 흐름이 전부 main 주변에 있으니까요.

그런데 main의 본래 역할은 프로그램을 시작하는 것, 그 이상도 이하도 아닙니다.

컨트롤러가 하는 일은 그림에 적혀 있는 그대로예요.

사용자의 입력을 받아 해석하고 → model에게 일을 시키고 → 그 결과를 view에게 넘겨준다

이 게임으로 치면 이런 흐름입니다.

InputView에서 이름·횟수 입력
      ↓
Cars, RacingGame 준비
      ↓
라운드 진행
      ↓
ResultView로 결과 전달

이걸 컨트롤러 클래스로 분리하면 main은 컨트롤러를 만들어서 실행만 하게 됩니다. 지금 규모에선 차이가 작아 보여도, 입력 방식이나 출력 형식이 바뀌었을 때 "흐름은 어디서 고치지?" 에 대한 답이 클래스 이름으로 바로 보이게 됩니다.

---

2) view가 model을 알면 서로 붙잡게 됩니다

"view는 model을 거쳐서 오기 때문에 의존해도 된다"고 해석하셨는데, 이 부분은 다르게 봅니다.
그림을 다시 보시면 view와 model 사이엔 직접 이어진 화살표가 없습니다. view는 controller가 건네준 것만 받아서 보여주죠.

물론 view가 model을 안다고 프로그램이 안 돌아가는 건 아닙니다. 문제는 비용이에요.
지금 ResultView는 Car를 import해서 getCarName(), getCarPosition()을 직접 꺼내 쓰고 있는데, 이러면 두 가지 일이 생깁니다.

상황	결과
Car를 고칠 때	화면이 깨집니다. 예를 들어 위치를 int 대신 Position 객체로 바꾸면, 화면은 그대로인데도 ResultView를 고쳐야 하죠.
화면에 뭔가 추가할 때	Car에 게터를 늘려야 합니다. 화면 요구사항 때문에 도메인이 바뀌는 거죠.

model이 view를 몰라야 하는 이유(화면이 바뀌면 model도 바뀌어야 하니까)와 똑같은 문제가 방향만 반대로 생기는 겁니다. 둘이 서로를 붙잡고 있어서 한쪽을 움직이면 다른 쪽이 끌려오는 상태예요.

이걸 끊으려면 controller가 도메인 객체를 그대로 넘기지 않고, 화면에 필요한 값만 담은 별도의 객체로 바꿔서 넘겨주면 됩니다. 그러면 view는 그 객체만 알면 되고, Car가 내부적으로 어떻게 바뀌든 상관없어지죠.

이런 객체를 흔히 DTO(Data Transfer Object) 라고 부르는데, 이번 차시 키워드에도 있으니 한번 찾아보시면 좋겠습니다.

---

MVC를 찾다 보면 서비스 계층 이야기도 나올 텐데, 지금 규모에선 필요 없습니다.
controller, model, view 세 가지가 각자 제자리를 찾는 데만 집중하시면 됩니다.
다만 궁금하시면 한번 넣어보셔도 좋아요. 그때는 왜 넣었는지, 컨트롤러와 무엇을 나눠 가졌는지 의도를 PR에 적어주시면 같이 이야기해보겠습니다.

5번

맞습니다. 그리고 이미 한 번 경험하셨을 수도 있어요. 이번에 코드를 꽤 많이 고치셨는데, 고칠 때마다 테스트가 통과하는 걸 보고 "안 깨졌구나" 하고 안심하지 않으셨나요? 규모가 커지면 그 안심의 값어치가 훨씬 커집니다.

다만 테스트에도 비용이 있다는 걸 같이 말씀드리고 싶어요.

테스트는 많을수록 좋을 것 같지만, 꼼꼼하게 짠 테스트가 오히려 발목을 잡기도 합니다. 코드를 하나 고쳤는데 테스트 수십 개가 한꺼번에 깨지면, 기능은 멀쩡한데도 테스트를 고치느라 시간을 다 쓰게 되거든요. 특히 어떻게 동작하는지(구현) 를 테스트하면 이런 일이 잦습니다.

예를 들어 findWinners()를 이번에 winnerOf()로 바꾸셨는데, 만약 테스트가 "우승자 리스트에 한 대씩 addAll 되는지"를 확인하고 있었다면 구조를 바꿀 때마다 테스트도 같이 고쳐야 했을 거예요. 반면 "공동 우승이면 둘 다 반환한다" 처럼 결과만 확인하는 테스트는 안쪽을 stream으로 바꾸든 뭘로 바꾸든 그대로 통과합니다.

그래서 저는 이렇게 구분합니다.

• 꼼꼼하게 — 앱의 핵심 규칙, 경계가 애매한 곳 (전진 조건 3/4, 이름 길이 5/6, 공동 우승 등)
• 가볍게 또는 생략 — 눈으로 봐도 확실한 것, 자주 바뀔 구현 세부사항

테스트는 무엇을 하는지를 지켜주는 거고, 어떻게 하는지는 자유롭게 바꿀 수 있어야 좋은 테스트라고 생각합니다.

[Leeguhyung]

1. 컨트롤러를 따로 분리 완료하였습니다
2. RacingGame에서 빈약했던 역할을 코드를 옮김으로써 역할 보완에 힘썻습니다. 재리뷰 부탁드리겠습니다.