Step4 : 로또(수동)

[Mo-bile]

안녕하세요?
피드백 요청드립니다 👍

객체가 잘 나누어져서인지 수동입력의 변경 여파가 로또 자동생성 및 당첨 계산, 수익률 계산에 코드수정이 거의 없어서 뿌듯했습니다.
크게는 LottoGame 외 별도의 LottoBuy라는 흐름을 새롭게 만들었는데 이렇게 로또 입력과, 계산 크게 두개 비즈니스 흐름을 만들었습니다.
이렇게 접근해도 되는건지 고민을 하다가 시도했습니다.

잘 부탁드리겠습니다.
감사합니다 👍

[javajigi]

객체가 잘 나누어져서인지 수동입력의 변경 여파가 로또 자동생성 및 당첨 계산, 수익률 계산에 코드수정이 거의 없어서 뿌듯했습니다. 이 부분을 제대로 느꼈군요. 👍
객체 설계를 잘 했을 때, 유지보수하기 좋은 코드를 구현했을 때 이 같은 느낌을 받을 수 있습니다.
객체의 의존관계를 끊고, 독립적으로 구현했을 경우 얻을 수 있는 효과입니다.
로또 생성과 관련해 다른 접근 방식으로 고민해 봤으면 하는 바람으로 피드백 남겨요.

피드백 반영하면서 시간날 때 '수강신청' 미션의 1단계 - 레거시 코드 리팩터링를 병행해 볼 것을 추천합니다.

[Mo-bile]

안녕하세요?
요청 주신 바 대로 인터페이스로 이용해보았습니다.

LottoBuy 의 생성자 부분을 분리해서 각 인터페이스의 메서드로 분리하였습니다.
그리고 각 구현체(자동, 수동, 혼합)으로 구현하여 각자의 방식으로 생성하였습니다.
저에게 의도하신 방식이 이 방식인지 조금 고민이 남아요

감사합니다!

[javajigi]

인터페이스 구현과 관련한 피드백 하나 남겼으니 도전해 보면 좋겠습니다.
로또 마지막 단계인만큼 이 연습을 하면서 "수강신청 - 레거시 코드 리팩터링" 미션의 "1단계 - 레거시 코드 리팩터링" 미션 병행할 것을 추천합니다.
미션을 병행하는 만큼 이 피드백 반영에 조급해 하지 말고 충분히 여유를 가지고 고민해 봤으면 좋겠습니다.

[javajigi]

인터페이스 기반으로 구현하면서 오히려 복잡도가 높아진 느낌이 든다.
인터페이스 기반으로 구현했을 때의 테스트 예시이다.
아래와 같이 구현하기 위해 도전해 보는 것은 어떨까?

아래 예시에서 LottoBundleGenerator는 LottoCombineGenerator와 같은 역할
Lottos는 LottoTickets와 같음

class LottoBundleGeneratorTest {
    @Test
    void generate() {
        Money money = new Money(5_000);
        List<String> values = List.of(
                "1,2,3,4,5,6",
                "2,3,4,5,6,7",
                "3,4,5,6,7,8"
        );
        LottoGenerator lottoGenerator = new LottoBundleGenerator(money, values);
        Lottos lottos = lottoGenerator.generate();
        assertThat(lottos.size()).isEqualTo(money.countOfBuyingLotto());
        System.out.println(lottos);
    }
}