[우아한 테크코스 7기] 프리코스 2주차 넷째날 회고

🎁 포장해보자 🎁

오늘은 어떤 객체를 또 돌돌 말아 감싸볼까 하고 고민했던 하루였다.

우승자들을 저장하자

public class Cars {
    public List<String> getNameOfWinner() {
        return cars.getNameOfMaxPositionCars();
    }

    public List<Car> getMaxPositionCars() {
        int maxPosition = cars.stream()
                .mapToInt(Car::getPosition)
                .max()
                .orElseThrow(() -> new IllegalStateException("등록된 차량이 없습니다."));

        return cars.stream()
                .filter(car -> car.getPosition() == maxPosition)
                .collect(Collectors.toList());
    }
}

public class Game {
	 public List<String> getNameOfWinner() {
        return cars.getNameOfMaxPositionCars();
}

public class GameController {
	public void start() {
    	// 생략..
        outputView.displayWinners(game.getNameOfWinner);
    }
}

기존에는 Game 이 Cars 우승자를 찾아 이름을 반환하는 메서드를 호출해 바로 컨트롤러로 넘기도록 했다. 우승자의 값에 대해서 따로 저장하지는 않았다. 그러나 다음과 같은 고민을 했다.

🤔 1. String 의 리스트로 반환하는 것은 캡슐화가 잘 지켜지는가?

현재 Cars 에서는 Car 객체를 반환하는 대신, getter 로 이름을 꺼내 String 의 리스트 형태로 반환하고 있다.

그러나 이가 정말 캡슐화를 지킬 수 있는지에 대한 의문이 들었다. 

 

만약, 다른 코드에서 리스트 값에 접근해 다시 값을 세팅한다면? 혹은 우승자가 두명이었는데 한 요소를 삭제해버린다면?

🤔 2. 우승자의 정보를 저장하지 않아도 되는가?

내가 정의한 서비스 내에서 Game 의 역할은 한 번 사용자가 입력한 값에 대하여 게임을 한 판 진행해주는 객체이다.

즉, 게임에 관련된 정보는 모두 여기에 저장된다. 총 라운드 수, 참여하는 자동차들, 랜덤한 수에서 몇 이상이 나와야 자동차들이 움직일 수 있는지 등에 대해 정의한다.

 

그런데 이러한 Game 의 객체에 우승자를 저장하지 않는다는 것이 어색하게 생각 되었다.

🤔 3. 우승자의 이름을 반환하는 것이 Cars 의 역할인가?

현재는 Cars 가 우승자의 이름을 반환하고 있다. Cars 의 메서드명은 가장 멀리 나간 자동차의 이름을 찾는다고 되어 있지만, 사실상 이에 대한 값을 Game 은 반환만 하고 있기에 우승자를 정해주는 것과 별반 다를 바가 없다. 그렇기에 어찌보면 우승자를 정하는 것이 Cars 의 책임처럼 보이기도 했다.

 

올림픽에 출전한 선수들은 출전만 하고, 자신이 맡은 바를 할 뿐 우승자들을 정하진 않는다. 🤸🏻‍♀️

 

그래서 나는 DTO 를 사용하기로 했다.

public class Game {
    public void judgeWinners() {
    List<Car> maxPositionCars = cars.getMaxPositionCars();
    this.winners = new Winners(maxPositionCars);
    }
}

public class Cars {
    public List<Car> getMaxPositionCars() {
       // 가장 멀리 나간 자동차들을 반환
    }
}

public class Winners {
    private final List<Car> cars;
    
    // 생략..
}

public record WinnersDto(List<String> nameOfWinners) {
    public WinnersDto(Game game) {
        this(game.getNameOfWinners());
    }
}

public class GameController {
	public void start() {
    	// 생략..
        outputView.displayWinners(game);
    }
}

Cars 는 리스트 형태로 Car 객체 자체를 반환한다. 게임은 그저 Cars 에게 제일 멀리 나간 차들에 대해 묻는다. 우승자를 판단하라는 책임은 지지 않도록 한다. 그리고 Game 은 이 객체들을 Winners 라는 객체로 돌돌 말아 저장한다.

이후 GameController 는 아무것도 꺼내지 않고 그저 game 을 전달해 내부에서 Winners 의 이름을 꺼내도록 한다. 이렇게 하면, 적어도 Winners 의 내부의 값을 바꿀 수 없기 때문에 저장된 우승자 정보를 조작할 위험성은 없다. 또한, GameController 에서도 우승자들의 이름을 노출하지 않고 바로 DTO 로 넘겼기 때문에 어디에서도 리스트 형태의 우승자들의 이름에 접근할 수 없게 됐다.

처음에는 단순 String 의 배열이기에 DTO 로 감쌀 필요가 있을까 싶었는데.. 안일했다. DTO 의 고마움을 뼈저리게 느꼈다.

시도 횟수를 감싸자

public class Game {
	private int attemptCount;
    
    public void play() {
        attemptCount--;
        attemptToMoveCars();
    }
    
    public boolean isRunning() {
        return attemptCount > 0;
    }
}

기존에는 위와 같이 Game 객체에 원시값으로 시도 횟수를 저장했다. 그러나 이후 미션에서 안내되지 않는 부분들을 내가 정의하는 과정에서 시도 횟수의 상한을 정해뒀기 때문에 비지니스 로직이 추가됐다. 그렇기에 이를 객체로 생성해 감싸줬다.

public class TotalRounds {

    private final int totalRounds;

    public boolean hasMoreRoundsThan(int currentRound) {
        return totalRounds >= currentRound;
    }
}

public class Game {
	public boolean isRunning() {
        return attemptCount > 0;
        return totalRounds.hasMoreRoundsThan(currentRound);
    }
}

이렇게 감싸니 앞으로 더 남은 라운드가 있는지 판단하는 책임도 Game 에서 TotalRounds 로 이동했다.

Game 클래스의 크기가 이전보다는 작아져 적절히 책임이 분배됐다고 생각했다.

자동차들의 상태를 감싸자

public class CarMovementResults {
    private final List<CarMovementResult> carMovementResults;

    private CarMovementResults(List<CarMovementResult> carMovementResults) {
        this.carMovementResults = carMovementResults;
    }
    public static CarMovementResults from(SequencedMap<String, Integer> statusOfCars) {
        List<CarMovementResult> movementResults = statusOfCars.sequencedKeySet().stream()
                .map(name -> new CarMovementResult(name, statusOfCars.get(name)))
                .collect(Collectors.toList());
        return new CarMovementResults(movementResults);
}

public class Cars {
     public SequencedMap<String, Integer> getStatus() {
            SequencedMap<String, Integer> carStatusMap = new LinkedHashMap<>();
            cars.forEach(car -> carStatusMap.put(car.getName(), car.getPosition()));
            return carStatusMap;
    }
}

기존의 코드.. 볼 필요도 없다.. 캡슐화를 지키겠답시고 Map 을 사용했었다. 그러나 보다시피 가독성이 극악이라 리팩토링할 생각으로 우선 구현부터 해뒀었다. 또한 지금 와서 보면, 앞서 우승자를 판별했던 기존의 로직과 같이 외부에서 이를 조작할 우려가 너무 많다. Map 에 접근해서 특정 값을 바꿔버리면 어떻게 할 수가 없다. 그래서 이에 대한 고민을 오늘 시작했다.

 

다른 경우들처럼 자동차의 상태를 정의하는 모델로 감쌀까에 대한 고민을 했다. 그러나, 이 경우에는 더 고민이 많았다. 이유는 다음과 같다.

🤔 1. DTO 랑 별 차이가 없지 않나?

뭐라고 정의해야 할지 고민이 됐다. DTO 인가, 모델인가?

정보를 전달하기 위한 객체니까 DTO 인가?

그렇다면 모델에서는 뷰를 의존하면 안되니 Controller 에서 정의를 해야 하는건가? 이렇게 설계 자체에 대한 고민을 했다. 

🤔 2. Car 과 별 차이가 없지 않나?

Car 과 같이 자동차의 상태에도 이름과 위치가 필요하다. 그렇다면 결국 같은 정보를 중복적으로 갖고 있는 꼴인데, Car 이 아닌 또 다른 객체를 정의할 이유가 있나?

 

내 고민의 결과는 모델로 정의해서 감싸는 게 맞다는 것이었다!

일단, 중복이라고 판단하지 않은 이유가 있다. 객체지향의 사실과 오해에는 다음과 같은 문장이 나온다.

모든 객체는 식별자를 가지며 식별자를 이용해 객체를 구별할 수 있다.
모든 객체가 식별자를 가진다는 것은 반대로 객체가 아닌 단순한 값은 식별자를 가지지 않는다는 것을 의미한다.

자동차의 상태를 정의하는 것은 식별자를 갖는다. 자동차의 상태를 저장하는 것은 각 라운드마다 자동차가 전진을 하던, 하지 않던 이뤄진다. 즉, 라운드 + 자동차의 이름이 결국에는 식별자로서의 의미를 갖고 동작한다. 그렇기에 이는 단순한 값 객체인 DTO 가 아닌 모델이라고 판단했다.

또한, 이와 같은 맥락에서 각 라운드마다 자동차의 상태를 나타내는 객체는 자동차 객체와는 엄연히 다르다.

스냅샷을 저장하는 것과 같은 맥락이다. 우리가 데이터베이스를 복사하려고 할 때 스냅샷을 뜬 것을 데이터베이스와 똑같다고 보지는 않는 것과 마찬가지라고 봤다.이는 절대 절대 값이 변하면 안되기 때문에 record 로 정의해줬다.

public record CarStatus(String name, int position, int round) {
}

💭 상상해보자 💭

코드 리뷰를 통해 이전 주차 과제에서는 엣지 케이스를 많이 고려하지 못했다는 것을 알게 됐다. 그래서 이번 주차에는 다양한 엣지 케이스를 고려해보고 싶었는데, 자유도가 높다보니 어디부터 어디까지 정해둬야 할지 잘 모르겠다는 생각을 했다. 그렇다면 내가 직접 하나부터 열까지 규정을 해보는 건 어떨까 싶었다.

# 자동차 경주 게임 입력값 규칙

안녕하세요! 자동차 경주 게임에 오신 여러분들을 환영합니다.

자동차 경주 게임 진행에 앞서, 게임의 입력값에 대한 규칙을 설명해 드리려고 합니다.

## 📝자동차 이름에 대하여

구분자(,) 를 기준으로 자동차의 이름을 입력해주시면 됩니다.

출전하는 자동차는 반드시 2대 이상이어야 합니다. 우승자의 자리를 두고 다퉈야 하니 두 대 이상이 당연히 출전해야겠죠?!

- ex) `토끼,` 와 같은 입력값은 한 대로 간주되어 잘못된 입력값으로 인해 게임이 종료되니 주의해주세요!

이름의 각 양쪽의 공백은 제거됩니다.

- ex) `토끼, 거북이` → 토끼와 거북이가 출전하는 것으로 입력됩니다. 거북이 앞의 공백이 제거됩니다.

자동차의 이름은 자유롭게 입력해주시면 됩니다! 단, 숫자와 한글, 알파벳만을 입력하실 수 있습니다.

- ex) `토a끼,거1북이` 는 가능합니다.
- ex) `토끼,**거북이` 는 불가능합니다.

구분자(,) 로 끝내거나 구분자(,) 만 존재하는 것은 불가능합니다!

- ex)`토끼,거북이,` 는 불가능합니다.
- ex) `,,,,` 는 불가능합니다.

자동차의 이름은 반드시 5자 이하여야 합니다! 그러나 이 때 이름 양쪽 끝 공백은 글자 수로 간주하지 않습니다.

- ex) `토끼깡총, 거북이` 는 가능합니다.
- ex) `토끼깡총, 거북이`          는 가능합니다.
- ex) `토끼깡총, 거   북이` 는 불가능합니다.
- ex) `토끼깡총, 거북이엉금엉금` 은 불가능합니다.

## 📝시도 횟수에 대하여

입력하신 시도 횟수만큼 게임을 진행하실 수 있습니다. 이는 `라운드` 라고 하겠습니다.

그러나 라운드는 10번 이하여야 합니다. 너무 오랜 시간 동안의 게임 진행은 게임 중독 위험이 있습니다! 😓

라운드는 반드시 0보다 큰 정수여야 합니다.

즉, 0이거나 음수, 소수일 수 없습니다. 게임을 -1 회만큼 진행할 수 있을까요? 0번 진행하는 건 게임이 아니겠죠! 2.3회 게임 진행 해보셨나요?

- ex) `0` , `-1` , `2.3` 은 불가능합니다.

당연히 숫자 이외의 값은 입력하실 수 없습니다.

- ex) `d` , `rabbit` 은 불가능합니다.

그럼 모두 입력값을 잘 입력해 재밌는 게임 시간 보내시길 바라겠습니다! 🙇🏻

그래서 나는 위와 같이 직접 게임의 안내자가 되었다고 생각하고 규칙 안내문을 작성해봤다.

이가 단순히 과제이거나 코딩의 세계라고 생각하지 않고, 사용자가 있으며 타인에게 이를 안내해야겠다고 생각하니 어떤 부분들을 고려해야 하는지 더 명확해져서 도움이 됐다. 이를 통해 엣지 케이스들을 더 다양하게 고려할 수 있었다!

---

오늘은 주로 유효성 검사와 객체를 감싸는 것에 대한 고려를 했다.

리팩토링을 한 뒤에 내부적으로는 구현이 바뀌었어도 테스트가 깨지지 않으면, 변경에 유연하게 설계했다는 생각이 들어 뿌듯하기도 했다! 그렇지만 오늘은 혼자 고민만 해서 그런지 이 방향이 맞는지도 모르겠고, 새롭게 들어오는 지식은 없어서 조금 힘이 빠지기도 했다 ㅠ.ㅠ~

 

내일은 MVC 구조를 조금 더 깊게 살펴보고, 역할에 어긋나는 부분이 있는지에 대한 생각을 해봐야겠다.

그리고 아직 GameController 의 전체적인 흐름이 눈에 들어오지는 않게 설계가 된 것 같아서 이 부분에 대해서도 다시 고려를 해봐야겠다!

 

내일도 최선을 다해보자~