Skip to content

Conversation

@qwer920414-ctrl
Copy link

안녕하세요,
이번에 step3에서 업데이트를 하지않고 그대로 진행해버려서 커밋이 꼬여 마지막에 식겁했네요ㅠ

step4 진행에 앞서 Money 클래스 가지고 LottoGame을 진행하기 어려울거 같아, LottoPurchase 클래스를 새로 만들었습니다.
그 후로 LottoPurchase 클래스를 개선하며 로직을 진행하였습니다.
확인 부탁드리고 피드백 주시면 확인해보겠습니다.

감사합니다!

Copy link
Contributor

@javajigi javajigi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4단계는 확실히 다른 객체에 영향을 최소화하면서 깔끔하게 구현 잘 했네요. 👍
같은 기능을 구현하면서 인터페이스 기반으로 구현했을 때의 차이점을 느껴보기 위한 피드백 남겼으니 한번 도전해 보면 어떨까요?

import java.util.List;
import java.util.stream.Collectors;

public class LottoPurchase {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이 객체가 수동/자동 로또 생성을 담당하고 있다.
이 부분은 인터페이스 기반으로 변경해 보는 리팩터링 도전해 보면 어떨까?

3단계에서 4단계로 요구사항이 변경될 때 로또를 생성하는 부분의 요구사항만 변경됐다.
로또를 생성하는 부분을 다음과 같은 구조의 인터페이스로 분리해 보는 연습을 해보면 어떨까?
이와 같이 인터페이스로 구현했을 때의 잇점에 대해 고민해 보는 시간을 가져본다.

public interface LottosGenerator {
    Lottos generate();
}

Comment on lines 30 to 45
if (matchCount == 6) {
return FIRST;
}
if (matchCount == 5 && matchBonus) {
return SECOND;
}
if (matchCount == 5) {
return THIRD;
}
if (matchCount == 4) {
return FOURTH;
}
if (matchCount == 3) {
return FIFTH;
}
return rank;
return NONE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

기존과 같이 stream api를 통해 구현해 보는 것을 도전해 보면 어떨까?

@qwer920414-ctrl
Copy link
Author

qwer920414-ctrl commented Dec 8, 2025

피드백 주신 부분 적용해보았습니다.

먼저 다시 stream를 통해서 rank를 구하도록 수정해보았습니다.
2등 3등을 구별하지 못했던 이슈가 있어서 if문으로 수정했다가, isMath()로 메소드 분리를 하고, 전체적인 흐름은 stream으로 구현하였습니다.

그리고 LottosGenerator를 도입하였습니다.
자동 생성인 autuLottoGenerator와 수동 생성인 manualLottoGenerator를 구현하여 적용해보았습니다.
자동에 필요한 count, 수동에 필요한 List를 받도록 하는 purchase()를 만들어서 각각 개발해보았는데 이런 방법이 괜찮을까요?
그리고 두 구현체를 합치는걸 고민하다가 찾아보니 구현체를 묶는 역할을 하는 구현체를 만드는 방법이 있는거 같아서 적용해보았네요

가장 고민이 되는 부분은 LottoPurchase의 역할인데요,
LottoPurchase는 구매 정보만 가지게 하고, LottoPurchase를 받아서 Lottos를 생성하는 객체를 만들까였습니다.
저의 로직 상 LottoGame이 LottoPurchase를 받아 게임이 진행되어서 그 부분은 수정하지 않는걸 생각하고 접근했습니다.
계속 고민할수록 처음 설계를 잘 잡아야 수월하게 수정이 가능하다는걸 느끼게 되는거 같아요

피드백 주시면 확인해보겠습니다.
감사합니다!

  • 회사에 큰 이슈가 있어, 이번주 라이브때 질문드리고 싶은게 있습니다ㅠ

Copy link
Contributor

@javajigi javajigi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

인터페이스 분리하고 인터페이스 구현체를 연결하는 컴포지트 구현까지 💯
바로 머지하려다 LottoPurchase에 대한 질문도 있어 마지막 피드백 남겨 봅니다.
"수강신청 - 레거시 코드 리팩터링" 미션 진행하면서 시간날 때 피드백 반영해 보세요.


import java.util.List;

public class CompositeLottoGenerator implements LottoGenerator {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

두 개의 Lotto를 합치는 객체까지 추가 👍
LottoPurchase의 purchse 메서드 내부를 CompositeLottoGenerator 에서 아래와 같이 구현해도 되지 않을까?

이와 같이 인터페이스를 구현하고, 구현체가 서로 연결되어 있는 경우 아래와 같은 구현체를 통해 구현체를 통합할 수 있음.
보통 디자인 패턴에서 컴포지트 패턴으로 알려져 있음.
아래와 같은 객체 추가에 따른 효과를 느껴 봤으면 하는 바람으로 피드백 남겨봄.

public class LottosBundleGenerator implements LottosGenerator {
    private final List<LottosGenerator> lottosGenerators;

    public LottosBundleGenerator(Money money, List<String> manualLottoText) {
        this(toLottosGenerators(money, manualLottoText));
    }

    private static List<LottosGenerator> toLottosGenerators(Money money, List<String> manualLottoText) {
        // manualLottoText 활용해 ManualLottosGenerator 생성
        // money에서 수동으로 구매한 로또 수 만큼 차감한 후 AutoLottosGenerator 생성
    }

    public LottosBundleGenerator(List<LottosGenerator> lottosGenerators) {
        this.lottosGenerators = lottosGenerators;
    }

    @Override
    public Lottos generate() {
        // List<LottosGenerator> 반복문 돌며 로또 생성
        return  로또를 합쳐서 반환;
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants