숫자 야구 게임 Lv2 Lv3 회고

GameManager 설계 고민과 해결

계산기 과제 Level 2, Level3에서는 GameManager 클래스가 게임의 전반적인 흐름을 제어하고 사용자 입력에 따라 게임을 시작하거나 기록을 조회하는 역할을 한다. 이 과정에서 몇 가지 설계 고민이 있었고, 그에 대한 해결책을 마련하였다. 이번 포스트에서는 이 고민과 해결책에 대해 자세히 살펴보겠다.

 

 

 

 

 

고민 1: GameManager 생성 시 BaseballGame 인스턴스 초기화

public class BaseballGame {

    private final NumberGenerator numberGenerator;
    private final Referee referee;

    public BaseballGame(final NumberGenerator numberGenerator, final Referee referee) {
        this.numberGenerator = numberGenerator;
        this.referee = referee;
    }
}

GameManager 클래스를 생성할 때 바로 BaseballGame 객체를 생성하는 것에 어색함을 느꼈다. 게임을 시작하지 않을 수도 있는데, 생성자에서 불필요하게 게임 객체를 생성하는 것은 과도한 초기화가 아닐까 하는 우려가 있었다.

 

 

 

 

 

해결

문제를 간단하게 접근하기로 결정하였다. 실제로 제공하는 선택지가 1. 게임 시작하기, 2. 게임 기록 보기, 3. 종료하기 외에는 없기 때문에 게임을 시작하지 않을 이유가 없다고 판단하였다. 따라서, GameManager를 생성할 때 BaseballGame 객체를 미리 생성해 두어도 큰 문제가 없다고 판단하였다. 

 

 

 

 

 

고민 2: Lv3 게임 통계 관리 방식

총 게임 횟수와 각 게임의 시도 횟수를 관리하는 방법에 대한 고민이 있었다. BaseballGame 클래스에서 이 데이터를 필드로 관리할지, 아니면 별도의 객체를 만들어 관리할지 결정해야 했다.

 

 

 

 

 

해결

이 고민에 대한 해결책으로는 게임 통계를 별도의 객체로 관리하기로 결정하였다. BaseballGame에서 게임 통계 필드를 직접 관리하면, 매번 게임을 초기화할 때 복잡하고 보기 불편한 코드가 생길 것을 우려하였다. 따라서, GameStats라는 별도의 객체를 만들어 게임 통계를 관리하도록 하였다.

 

 

장점으로는,

• 독립적인 관리: GameStats 객체가 게임 통계를 독립적으로 관리하기 때문에, BaseballGame의 초기화 과정에서 통계가 리셋되는 것을 방지할 수 있다.
• 유연한 확장: 향후에 게임 통계나 다른 관련 데이터를 추가해야 할 경우, GameStats 클래스를 확장하는 것만으로 해결할 수 있다.
• 책임 분리: BaseballGame 클래스의 책임이 줄어들고, 게임 통계와 관련된 로직이 GameStats로 명확히 분리되므로 코드 유지보수가 쉬워진다.