[우아한테크코스 6기] 프리코스 3주차 로또 미션 후기

3주차가 마무리되었습니다. 2주차와 비교해보자면 처음 미션을 받고 요구사항을 읽어보았을 때 순간 만큼은 체감 난이도가 꽤 높다고 느껴졌던 미션이었습니다.

 

3주차 목표 

1. 객체 지향적으로 설계하기

이번 주차에는 지난 주차에서 고민했던 것들에 대한 답을 정하고 미션을 진행한만큼 객체지향적 개념들을 많이 신경써서 코드에 적용해보았습니다. 

 

2. 공통 피드백을 반드시 지키기

2주차 공통 피드백은 아래와 같습니다.

 

1. README 상세히 작성하기
2. 기능 목록 수시로 재검토 및 업데이트하기
3. 매직넘버 상수로 관리하기
4. 선언 순서 지키기 ( 상수 - 멤버변수 - 생성자 - 메소드 )
5. 변수 이름에 자료형 사용하지 않기
6. 한 함수는 "한 가지" 기능만 담당하도록 구현하기
7. 테스트를 작성하는 이유에 대해 생각해보기
8. 작은 단위 -> 큰단위 순으로 테스트 작성하기 

 

이번 미션을 진행하면서 항상 코드를 의심하고 점검하는 과정을 통해 피드백을 지키려고 노력했습니다. 

 

3주차에서 배운 점들 

1. Enum 활용하기

프로그래밍 요구사항에 추가적으로 Enum 을 활용해보라는 요구사항이 있었습니다. Enum을 어떻게 활용할 지 고민이 많았습니다.

 

• 위와 같이 전역적으로 재사용의 여지가 있는 상수들은 Enum으로 상수를 관리하도록 하긴 했으나, 이 하나로 Enum을 활용했다기에는 부족했습니다.

• 어떻게 Enum을 활용해야 할 지 고민하던 중, 로또의 통계를 산출하는 기능을 구현할 때 Enum을 적극적으로 활용할 수 있었습니다.

 

• 연관성이 있는 상수들을 enum으로 관리함과 동시에 위와 같이 로또 결과를 생성하는데 EnumMap으로 사용하였습니다.
• 1등부터 5등까지의 당첨 정보를 Enum으로 만들고, Key에 Enum을, Value에는 Integer를 넣은 EnumMap을 만들어 통계를 산출할 때 Key값을 스트림하여 일치하는 Key를 발견하면 Value를 하나 올리는 방식으로 통계를 산출하여 Enum을 저극적으로 활용할 수 있었습니다.
• Enum은 단순히 열거형 상수를 정의하는 용도로만 사용한다고 생각했는데, 비즈니스 로직에 Enum을 활용하니 Enum 사용하지 않았을 때와 비교했을 때 미션을 수월하게 진행할 수 있었습니다.

 

2. 객체를 객체스럽게 사용하기

캡슐화와, 단일 책임원칙에서 입각한 객체설계에 집중했습니다. 쉽게 말해 객체가 스스로 할 수 있는 일은 외부에서 수행하지 말고, 객체 스스로 할 수 있도록 구현하는 것입니다. 말로 설명하는데는 한계가 있어 예시를 하나 살펴보겠습니다.

public class Lotto {

    private final List<Integer> numbers;

 

위 클래스는 로또 1장에 대한 클래스입니다. 필드로는 로또 번호에 대한 정보를 Integer List numbers로 담고 있습니다.

이 클래스에 의해 만들어진 객체를 객체스럽게 사용하려면 어떻게 해야할까요?

 

먼저 캡슐화 측면에서 바라봅시다.

 

numbers 인스턴스 변수는 클라이언트에게 이 번호를 보여주어야 한다거나, 다른 모델을 생성할 때 이 번호를 필요로 한다거나 등등의 경우로 외부에 물론 전달할 수 있습니다. 하지만 이 번호 필드를 외부에서 조작하거나 외부에서 이 값을 비교하는 경우 이 객체의 캡슐화가 깨지게 됩니다. 

캡슐화 : 객체 내부의 속성이나 행위를 하나로 묶어 외부에서 직접 접근할 수 없게 하는 행위.

 

캡슐화를 지키기 위해서는 Tell, Do not Ask 원칙이 있습니다. 객체 내부의 데이터를 꺼내와서 처리하는 것이 아니라, 객체에게 처리할 행위를 요청하라는 행위입니다. 적용하지 않은 예시를 먼저 살펴보겠습니다.

 

<적용하지 않은 예시>

public class Lotto {

    private final List<Integer> numbers;
    ...
}

public class TestClass {

    public static void main(String[] args) {
        List<Integer> userNumbers = SixRandomLottoNumber.generate(); 
        List<Integer> winningNumbers = input.getNumbers();

        Lotto userLotto = new Lotto(userNumbers);
        Lotto winningLotto = new Lotto(winningNumbers);      

        Integer count = calculateMatchedCount(winningLotto.getNumbers(), userLotto.getNumbers());
    }
    
    private Integer calculateMatchedCount(List<Integer> winningNumbers, List<Integer> userNumbers) {
        Integer count = 0;

        // 비교하는 기능 구현 ...


        return count;
    }
}

 

• 코드를 보시면, Lotto 객체의 필드값을 꺼내와서 외부에서 일치하는 번호의 개수를 검사하는 것을 볼 수 있습니다.
• 이렇게 캡슐화가 깨지게 되면 외부에서 객체를 의존하게 되므로 응집도가 올라가고, 해당 객체가 책임져야 할 비즈니스 로직이 외부로 노출되어 있어 객체의 역할과 책임이 깨지게 됩니다.

 

그렇다면 이번에는 이 문제를 객체가 스스로 해결하도록 다시 적용해보겠습니다.

public class Lotto {

    private final List<Integer> numbers;

	... 
    
    public int countMatchedNumbers(final Lotto lotto) {
        return (int) numbers.stream()
            .filter(number -> lotto.contain(number))
            .count();
    }

    public boolean checkBonusNumberContain(final BonusNumber bonusNumber) {
        return this.contain(bonusNumber.number());
    }

    private boolean contain(final Integer number) {
        return numbers.contains(number);
    }
}

 

• 객체가 스스로 자신과 동일한 클래스의 객체를 비교하여 일치하는 숫자의 개수를 리턴하고 있습니다.
• 이와 같이 캡슐화를 지키게 되면 데이터를 처리하는 동작 방식을 외부에서 알 필요가 없다는 장점이 있습니다.
• 외부에서 동작방식을 알 필요가 없어졌기 때문에 외부에서는 이 객체에 대한 의존이 사라져 비즈니스 로직이 변경되는 경우에도 유지보수 측면에서 이점을 얻을 수 있게 되었습니다.

 

 getter를 지양하라는 메시지에 의아함이 있었는데, 이번에야 그 의미를 제대로 이해할 수 있었습니다. 

 

3. 전략 패턴 적용

이번 미션에서는 테스트 코드 작성을 용이하게 하기위해 난수 생성 클래스에 전략패턴을 적용했습니다. 

 

먼저 지난 미션에서의 난수 생성 클래스를 사용한 클래스를 테스트한 방식을 먼저 살펴보겠습니다.

 

class CarTest {

    private static final Integer START_POINT = 0;
    private static final Integer THRESHOLD = 4;

    private static MockedStatic<RandomNumberGenerator> randomNumberGeneratorMockedStatic;
    private Car car;

    @BeforeAll
    public static void beforeAll() {
        randomNumberGeneratorMockedStatic = mockStatic(RandomNumberGenerator.class);
    }
    
    @DisplayName("랜덤 숫자가 임계치 이상인 경우 자동차는 전진한다.")
    @Test
    void updatePosition_moving_required_test() throws Exception {
        Car car = new Car(new CarName("Car1"));
        given(RandomNumberGenerator.pickNumber()).willReturn(THRESHOLD);

        Integer originalPosition = car.getCarPosition().position();

        for (int i = 1; i <= 1000; i++) {
            car.updatePosition();
            Integer newPosition = car.getCarPosition().position();
            assertTrue(newPosition == (originalPosition + i));
        }
    }
}

 

지난 미션에서는 난수를 생성하는 메소드를 정적팩토리메소드로 관리하고, 이를 테스트하기 위해 MockedStatic 테스트 도구를 사용했는데요. 물론 이 방법도 나쁜 방법이라고 할 수는 없지만,  모의 객체를 만들고 동작을 통제하는 방식은 테스트하기에 유연하지는 않습니다. 

 

따라서 이번 미션에서는 프로덕션 코드를 확장한 전략패턴을 사용하여 테스트를 용이하게 해보았습니다. 코드로 살펴봅시다.

 

public interface LottoNumberGenerator {

    List<Integer> pickNumbers();
}

• 전략 패턴을 적용하기 위해 난수를 생성하는 기능을 가진 클래스를 인터페이스로 두고,

public class RandomLottoNumberGenerator implements LottoNumberGenerator {

    @Override
    public List<Integer> pickNumbers() {
        List<Integer> numbers = Randoms.pickUniqueNumbersInRange(
                LOTTO_MIN_NUMBER.getValue(),
                LOTTO_MAX_NUMBER.getValue(),
                LOTTO_SIZE.getValue());

        return numbers;
    }
}

private Lotteries initLotteries(final TicketCount ticketCount) {
    return Lotteries.createLotteries(ticketCount, new RandomLottoNumberGenerator());
}

• 위 인터페이스를 구현한 클래스를 생성하고, 다형성을 이용하여 RandomNumberGenerator의 pickNumbers를 사용하도록 작성하였습니다.  
• 이렇게 프로덕션 코드를 확장하게 되면 테스트 용이성 뿐만 아니라, 비즈니스 로직이 바뀌었을 때 유연하게 갈아끼울 수 있다는 장점도 있습니다.

 

테스트 코드를 보겠습니다.

class LotteriesTest {

    LottoNumberGenerator numberGenerator;
    Lotteries lotteries;

    @BeforeEach
    void init() {
        numberGenerator = new LottoNumberGenerator() {
            @Override
            public List<Integer> pickNumbers() {
                return List.of(1, 2, 3, 4, 5, 6);
            }
        };
        TicketCount ticketCount = new TicketCount(3);
        lotteries = Lotteries.createLotteries(ticketCount, numberGenerator);
    }

    @DisplayName("플레이어의 로또번호 생성자 테스트")
    @Test
    void createLotteries_test() {
        // given
        TicketCount ticketCount = new TicketCount(3);

        // when
        Lotteries lotteries = Lotteries.createLotteries(ticketCount, numberGenerator);

        // then
        int expectedSize = ticketCount.count();
        int actualSize = lotteries.getLotteries().size();
        assertEquals(expectedSize, actualSize);

        lotteries.getLotteries().forEach(lotto -> {
            List<Integer> numbers = lotto.getNumbers();
            assertTrue(numbers.containsAll(numberGenerator.pickNumbers()));
        });
    }

 

• LottoNumberGenerator를 구현한 클래스를 생성해주고 pickNumbers메소드를 오버라이딩함으로써, 동작을 제어할 수 있게 되었습니다.
• 이처럼 전략 패턴을 사용하는 것은 테스트를 위해 프로덕션 코드를 ‘수정’하는 것이 아닌 ‘확장’하는 것이었기 때문에 테스트를 용이하게 할 때 좋은 방법이었습니다.
• 뿐만 아니라, 모의 객체를 사용하는 것보다 제어한 동작을 구현한 메소드의 내용을 통해 명시적으로 확인할 수 있기 때문에 테스트가 더욱 명확해졌다고 볼 수 있습니다.

 

4. 생성자 대신 정적 팩토리 메소드 적용

public class Lotto {

    private final List<Integer> numbers;

    public Lotto(final List<Integer> numbers) {
        validateLottoNumbers(numbers);
        this.numbers = numbers;
    }

    public static Lotto createWinningLotto(final List<Integer> winningNumbers) {
        return new Lotto(winningNumbers);
    }

    public static Lotto createLotto(final LottoNumberGenerator lottoNumberGenerator) {
        return new Lotto(createNumbersWithGenerator(lottoNumberGenerator));
    }

• 요구사항에 따라 Lotto 클래스의 생성자를 public으로 열어주는 것을 제외하고는 팩토리 메소드를 사용하여 생성자를 대신하였습니다.

public class Lotteries {

    private final List<Lotto> lotteries;

    private Lotteries(final List<Lotto> lotteries) {
        this.lotteries = lotteries;
    }

    public static Lotteries createLotteries(final TicketCount ticketCount,
                                            final LottoNumberGenerator lottoNumberGenerator) {
        List<Lotto> lotteries = IntStream.range(0, ticketCount.count())
                .mapToObj(eachTicket -> Lotto.createLotto(lottoNumberGenerator))
                .toList();

        return new Lotteries(lotteries);
    }

 

public class Statistic {

    private static final Integer DEFAULT_COUNT = 0;
    private static final Integer FIVE_COUNT = 5;
    private static final Integer COUNT = 1;

    private final Map<LottoRank, Integer> result;

    private Statistic(final Map<LottoRank, Integer> result) {
        this.result = result;
    }

    public static Statistic createStatistic(final List<Integer> matchedNumberCount,
                                            final List<Boolean> containBonusNumber) {
        return new Statistic(compileStatistic(matchedNumberCount, containBonusNumber));
    }

 

public class ProfitRate {

    private static final Integer PERCENTAGE = 100;

    private final Double rate;

    private ProfitRate(final Double rate) {
        this.rate = rate;
    }

    public static ProfitRate createProfitRate(final Map<LottoRank, Integer> result, final BuyAmount buyAmount) {
        return new ProfitRate(calculateProfitRate(result, buyAmount));
    }

• 무엇보다 로또 클래스의 경우 메소드에 명확한 네이밍을 설정하여 이름을 가진 생성자를 만듦으로써 코드의 가독성을 더욱 증가시킬 수 있었습니다.
• 당첨번호의 로또를 생성하는 생성자와 플레이어의 로또 번호를 생성하는 생성자를 인자를 다르게 하여 당첨번호에 대한 로또 클래스와, 플레이어의 로또에 대한 클래스를 분리하지 않고 로또 번호를 생성하는 방식만 변경하여 클래스를 재사용할 수 있었습니다.
• 정적 팩토리 메소드 생성자를 통해 클래스의 재사용을 통해 불필요한 코드의 중복을 막고, 난수 생성 클래스에 의해 생성된 당첨번호 또한 검증을 적용할 수 있었기 때문에 코드에서 발생할 수 있는 버그와 오류의 가능성을 줄일 수 있었습니다.

이 외에도 이번 미션에서는 검증에서 발생하는 예외들을 구체적으로 처리하고, final 키워드와 UnmodifiableXXX 메소드를 사용하고, 하나의 함수가 하나의 역할을 하도록 구현하는 등 깔끔하고 구체적이면서, 정돈된 느낌을 줄 수 있는 코드를 작성하려고 많이 노력했던 미션이었습니다.

---

3주차 전체 소감

좋은 코드, 객체지향적인 코드를 작성하기 위해 많이 고민했던 한 주였습니다. 그만큼 이번 미션은 배워가는 점들이 더욱 많았던 미션이었습니다. 미션을 진행할 때는 다소 어려웠다고 체감했었는데, 리펙토링 과정까지 끝내고 제출문을 쓰는 시점에서 이번 미션을 돌아보았을 때는 1,2주차 미션과 비슷한 난이도라고 느껴졌습니다. 그만큼 이번 미션을 완성해 나아가는 과정에서 1, 2주차와 비교하였을 때 코드를 보는 시야가 많이 넓어졌고, 객체지향적인 개념들이 조금씩이나마 정립되었던 한 주였습니다. 다음 주면 벌써 마지막 미션인데 마지막까지 열심히 해서 결실을 잘 맺었으면 좋겠습니다.

---

미션 링크

미션에 대한 제 코드가 궁금하시다면 아래 링크를 참고해주세요.

GitHub - Dongwoongkim/java-lotto-6