🚀 4단계 - 로또(수동)

[Eundms]

LottoGame을 삭제하고 책임을 다시 나누고자 하는 과정이 어려웠습니다

[javajigi]

3단계까지 객체 설계를 잘해서인지 그리 큰 변화를 하지 않은 상태에서 4단계 미션 진행했네요. 👍
Money와 Purchase 객체 관련해 피드백 남겨 봤으니 한번 고민해 봤으면 좋겠습니다.

[javajigi]

Money와 Purchase의 책임과 역할이 명확하지 않고 둘의 역할이 애매한 측면이 있다.
이 두 개의 객체의 역할과 책임을 Money와 같은 객체 하나로 통합할 수는 없을까?
이 두 객체의 역할과 책임에 대해 정의해보고 AI 피드백을 받아 하나로 통합하는 것과 현재와 같은 구조로 구현하는 것에 대해 피드백을 받아 설계를 개선할 부분을 찾아본다.

[Eundms]

Money 와 Purchase의 책임과 역할

현재와 같은 구조를 유지

• 책임과 역할이 모호한 부분이 있다

• 아래와 같이 역할과 책임을 정의한다면?

  • Money: "얼마인가?" (금액, VO 역할)
  • Purchase: "무엇을 얼마나 샀는가?" (구매 행위, 도메인 객체)

Purchase

public class Purchase {

  private final Money budget;
  private final Money ticketPrice;
  private final int manualCount;
  private final int autoCount;
  }

구매 관련 비즈니스 로직 확장이 있는 경우 Purchase 객체 내에서 처리될 수 있다.

예를 들어,

1. 잔돈 (거스름돈) 기능이 추가되는 경우 아래와 같이 추가할 수 있다.

  public Money getChange() {
      return budget.subtract(getSpentAmount());
  }

2. 티켓을 얼마 주고 샀는지 복사해서 가지고 있기 때문에 티켓 가격이 변동되는 경우에 영향이 없습니다.

그렇다면, Money에 추가될 수 있는 비즈니스 로직

AI에게 물어봤습니다

로또 도메인에서

 // 1000원 단위 검증 (로또는 1000원 단위)
  public void validateUnit(int unit) {
      if (this.amount.remainder(BigDecimal.valueOf(unit)) != BigDecimal.ZERO) {
          throw new IllegalArgumentException("1000원 단위로 입력하세요");
      }
  }

일반 커머스 도메인에서
할인 적용,세금 계산, 통화 변환, 결제 가능 여부

어려웠던 점

Money 객체에서

1. BigDecimal wrapper 느낌

  public Money add(Money m) { return new Money(amount.add(m.amount)); }
  public Money multiply(int n) { return new Money(amount.multiply(...)); }

• Money만의 도메인 로직 없이 BigDecimal 연산을 감싸기만 함

2. 반환 타입 일관성

  add(Money) → Money      // ✅ 일관
  multiply(int) → Money   // ✅ 일관
  calculateRatio(Money) → BigDecimal  // ❌ Money 아님
  countUnits(Money) → int             // ❌ Money 아님

• "금액 / 금액"의 결과는 금액이 아니라 비율/개수

3. 도메인 로직의 위치

  // Money에 있어야 하나?
  budget.canAfford(ticketPrice)

  // Purchase에 있어야 하나?
  if (budget.isLessThan(ticketPrice)) { ... }

• canAfford는 "구매 가능 여부"라는 도메인 판단 → Purchase 책임
• isLessThan은 "금액 비교"라는 범용 연산 → Money 책임

4. 결론

Money	Purchase
금액 표현 (VO)	구매 행위 (도메인 객체)
범용 연산/비교	도메인 판단/검증
isLessThan, countUnits	"예산이 충분한가?"

[javajigi]

AI와 다음에 대해서도 논의해 보면 좋겠네요.
Money는 단순히 값을 가지고, Purchase가 Money 값에 대한 행위를 다룬다면 Money 값 객체를 너무 수동적인 존재로 바라보는 느낌이 드는데요.
Money 값 객체를 좀 더 능동적인 객체로 바라본다면 Purchase의 행위를 담당하는 부분까지 Money가 담당하도록 구현하는 것은 어떨까에 대해서 AI 대화를 통해 피드백을 받아볼 것을 추천해 봅니다.

[Eundms]

2가지 이유 때문에 아무래도 이전 Money 객체에서의 수익률 메서드가 어색했던 것 같습니다.

• Money는 "금액"일 뿐인데, "로또 수익률"이라는 도메인 개념을 알아야 함
• Purchase가 Money에게 물어보고 판단하는 수동적 구조

따라서, 아래와 같이 Purchase 하나만 남기도록 하였습니다.
Purchase: "나는 로또 구매야. 얼마 썼고(지출), 몇 장 샀는지(수량) 알아. 당첨금을 알려주면 수익률도 계산해줄게"

[javajigi]

entry에서 값을 꺼내고 있다.
entry에 메시지를 보내 로직을 구현하는 것은 어떨까?

[javajigi]

Money와 Purchase에 대한 의견 잘 들었습니다. 👍
이에 대한 제 생각과 추가로 학습해 봤으면 하는 내용에 대해 피드백 남겨봤어요.
객체의 역할에 대해 고민해 보는 시간을 가져봤으면 좋겠습니다.

1. https://vimeo.com/1137582691 영상을 통해 객체의 역할과 이름 짓기에 대해 추가 학습
2. 피드백 남긴 바와 같이 AI를 통해 피드백 받아보기
3. 느끼는 바가 있다면 리팩터링해보기

위와 같은 순서로 추가 학습해볼 것을 추천해요.
이 학습이 금방 되는 것은 아니잖아요?
그렇기 때문에 이 학습을 하면서 수강신청 미션 1단계 - 레거시 코드 리팩터링 미션을 진행하면서 무엇인가 본인만의 객체에 대한 철학을 정리해 볼 것을 추천합니다.

[javajigi]

바로 merge하려다 혹시라도 추가 연습해보고 싶은 부분이 있을 수 있어 request changes로 남겨봅니다.
혹시라도 추가 리팩터링해보고 싶은 부분 있으면 도전해 보시고요.
없으면 바로 리뷰 요청해도 됩니다.

아니면 로또 미션은 진행 상태로 두고 "수강신청 - 레거시 코드 리팩터링" 미션 진행하다 일정 시간이 지난 후 다시 리팩터링 도전해 보는 것도 좋은 연습 방법일 수 있습니다. AI와 함께 로또 미션의 객체 설계에 대한 피드백을 받아보는 것도 좋은 방법일 것 같아요.