[🚀 사이클2 - 미션 (블랙잭 배팅)] 달수 미션 제출합니다.

[soohyun1904]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

1. 함수형 인터페이스를 활용한 컨트롤러-도메인 분리

기존에는 컨트롤러가 인덱스로 Players를 직접 순회하며 조작하고 있었습니다.

for (int i = 0; i < game.playerCount(); i++) {
    while (game.canPlayerHit(i)) { ... }
}

이를 HitDecision, TurnDisplay, BetDecision 같은 함수형 인터페이스로 바꿔서
턴 순회와 게임 로직을 Game 내부로 이동시켰습니다.

game.betPlayers(name -> InputView.readBetAmount(name));
game.playPlayerTurns(
    name -> Parser.parseDrawInput(readYesOrNo(name)).isHit(),
    OutputView::printPlayerHand
);

이 방향이 맞는지, 오히려 인터페이스가 늘어나면서 복잡해진 건 아닌지 피드백 부탁드립니다.

2. 출력 콜백의 도메인 결합 문제

hit할 때마다 중간 카드를 출력해야 하는 요구사항 때문에 TurnDisplay 콜백을 사용했습니다.
입력은 콜백으로, 출력은 결과 객체를 컨트롤러가 당겨가는 방식이 깔끔하다고 생각하지만, 턴 중간 출력은 당겨갈 수 없어서 콜백으로 처리했습니다.

다만 출력 형식이 바뀌면 콜백 시그니처도 바뀔 수 있다는 점이 걸립니다.
현재는 (String name, List<String> cardNames)만 넘기고 있는데, 이 정도면 괜찮은 건지, 더 좋은 방법이 있는지 의견 부탁드립니다.

3. 의존 관계 — "아는 것"의 기준

파라미터, 반환값, 필드, 내부 생성 등 메서드 시그니처에 타입이 등장하면 의존이 생기는 것으로 이해했습니다.

이 기준으로 Players에 있던 hitPlayer(int index, TrumpCard card) 같은 메서드를 제거하고 forEach(Consumer<Player>)로 바꿨습니다.
Players는 TrumpCard와 직접 협력할 이유가 없고 전달만 하는 중간자였기 때문입니다.

한편 BlackjackGame의 forEach 람다 안에서 player.hit(deck.deal())을 호출하는데, 이때 TrumpCard를 아는 건 람다를 작성한 Game이지 실행하는 Players가 아니라고 판단했습니다.
"직접 협력하면 알아도 되고, 전달만 하면 알 필요 없다"는 기준이 맞는지 피드백 부탁드립니다.

4. 기능 변경 시 테스트가 깨지는 범위

Hand의 isBust()를 Player가 위임하도록 리팩토링했는데, 그래도 Hand의 행위가 바뀌면 PlayerTest, DealerTest의 canHit() 테스트도 함께 깨집니다. 위임을 하더라도 하위 객체의 행위 자체가 바뀌면 상위 테스트도 영향을 받기 때문입니다.

하위 변경이 직접 의존하는 상위 테스트까지 깨뜨리는 게 자연스러운 건지, 아니면 상위 테스트가 안 깨지도록 설계할 수 있는 건지 궁금합니다.
어디까지 깨지는 게 정상이고 어디부터가 설계 문제의 신호인지 기준이 있을까요?

5. 상태 패턴(State Pattern) 적용

현재 hit 가능 여부를 canHit()의 if문으로 판단하고 있는데, 상태 패턴을 적용하면 Player의 상태(히팅 중, 스테이, 버스트, 블랙잭)에 따라 행위를 분리할 수 있다고 다음 단계에 적혀 있었습니다.
이 미션에 상태 패턴을 적용한다면 어떤 구조가 좋을지 방향을 잡고 싶어서 조언 부탁드립니다.

6. 상위 기능 변경으로 인한 하위 수정 범위

배팅 기능이 추가되면서 기존 MatchResult의 역할이 애매해졌습니다. 승패 판정은 여전히 필요하지만 출력에는 수익 금액만 나오고,
수익 계산을 위해서는 MatchResult + 배팅 금액이 함께 필요합니다.

기존 MatchResult를 수정해서 수익 계산까지 담당하게 할지, 별도의 수익 계산 객체를 만들어야 할지, 그리고 기존 matchResults()를 호출하던 컨트롤러와 View도 함께 바꿔야 하는데 이런 연쇄 수정을 최소화하려면 어떻게 설계하는 게 좋은지 궁금합니다.

저는 별도의 수익 계산 객체를 만들긴 했습니다.

7. 리팩토링 범위 관리

이번에 네이밍 변경 + 책임 분리 + 함수형 인터페이스 도입을 동시에 진행하다 보니 변경 범위가 넓어져서 한 커밋에 많은 파일이 바뀌었습니다. 하나를 고치면 연쇄적으로 다른 곳도 수정해야 했습니다.

돌이켜보면 "네이밍 먼저 → 책임 분리 → 인터페이스 도입" 순서로 나눴으면 좋았을 것 같은데, 이런 상황에서 커밋을 어떻게 나누는 게 좋은지 조언 부탁드립니다.

8. 이전 피드백 관련

전 사이클 피드백 중 반영하지 못한 부분이 있을 수 있어서, 리뷰 후 확인하여 반영하겠습니다.
추가로 사이클 1에서 Suit, Rank 관련 코멘트와 서비스 레이어 관련 질문에 대해 아직 답변을 받지 못해서 확인 부탁드립니다.

[Rok93]

달수 사이클2 미션도 훌륭하게 잘 진행해주셨네요. 👍👍
전체적으로 깔끔하게 구현해주셔서 코드 파악도 한결 더 쉬웠던 것 같아요. 😊

질문 주신 내용에대한 답변과 추가로 몇몇 코멘트 남겨두었으니 확인부탁드릴게요. 🙂
상태패턴의 경우 방향성을 먼저 질문하시기보다는, 간략하게라도 달수가 생각하는 방향성이나 혹은 방향성 설명이 어렵다면 코드로 작성한 뒤, 방향성을 질문해주시면 좋겠다고 생각했어요. 😉

[Rok93]

메서드로 분리하지 않아도 충분히 동일한 의도를 드러낼 수 있을 것 같아요. 😊

[Rok93]

get 같은 prefix를 단순 getter(별도 계산 없이, 단순히 값을 꺼내오는 메서드)로 착각하 수 있다고 생각해요. 🤔

이런 경우에는 dealer profit을 계산하는 행위를 드러낼 수 있도록 get보다는 calculate 같은 표현이 어떨까 싶어요. 😁

[Rok93]

자바 코드 컨벤션에서는 메서드 네이밍 규칙으로 동사 or 동사구를 사용하라고 가이드하고있어요.

[Rok93]

이 메서드는 사용하지 않는 것으로 보이네요. 👀
사용하지 않는 메서드는 과감히 제거해주세요. 😊

[Rok93]

TrumpCard.CARDS << 보다는 TrumpCard.ALL_CARD (혹은 CARDS)가 조금 더 상수 의미가 명확하지 않을까요? 🤔

[Rok93]

블랙잭 은 단순히 점수로만 판단할 수 있는건가요? 🤔

[soohyun1904]

카드 수는 참가자 로직에 추가했었는데, Hand에 있는게 맞는거 같네요

[Rok93]

불필요한 import문으로 보여요.
제거 부탁드릴게요. 😊

[Rok93]

현재 MatchResult에서 정적팩토리 메서드로 player와 delaer를 받고있는데요.
실제 블랙잭 게임도 승,패 판단을 dealer가 하니, 승패를 판단하는 역할을 dealer 객체에게 위임해보면 어떨까요?

[soohyun1904]

승패 판정을 Dealer에 두는 것도 고민했는데, Dealer 자신도 판정 대상이라 자기가 판정하는 게 어색하다고 느꼈습니다.
판정은 게임 규칙이라고 생각해서 BlackjackRule로 분리했습니다.
혹시 고치는게 좋을까요?

[Rok93]

배당 배수에 대한 enum 을 별도로 만드셨군요? 👍👍

이 수익을 계산하는 로직을보다보니, 사실상 블랙잭 승리 케이스만 제외하면 기존의 GameResult와 1:1로 매칭되는 것 같지 않나요?

별도 enum class를 만들 필요 없이, GameResult에 각 enum 요소에 배당률을 둔 후, 기존처럼 게임 승패를 판단하여 반환하는 승,무,패를 가지고 배당률(?)을 판단할 수 있지 않았을까 싶어요.

---

지금의 방식이 나쁘다는 얘기는아니고 이렇게도 생각해볼 수 있지 않을까...? 하는 관점 공유차원으로 남긴 코멘트에요.
꼭 반영해달라는 얘기는 아니니 참고만해주세요. 🙂

[Rok93]

PR로 남긴 질문에 대한 답변은 여기에 남겨볼게요.

1. 함수형 인터페이스를 활용한 컨트롤러-도메인 분리
   기존에는 컨트롤러가 인덱스로 Players를 직접 순회하며 조작하고 있었습니다.

이를 HitDecision, TurnDisplay, BetDecision 같은 함수형 인터페이스로 바꿔서
턴 순회와 게임 로직을 Game 내부로 이동시켰습니다.

이 방향이 맞는지, 오히려 인터페이스가 늘어나면서 복잡해진 건 아닌지 피드백 부탁드립니다.

---

컨트롤러가 Players를 직접 순회하며 게임 진행을 조작하던 구조보다, 턴 진행 자체를 Game이 책임지도록 옮긴 방향은 더 자연스럽다고 봅니다. 특히 “누가 카드를 더 받을 수 있는지”, “턴을 언제 종료하는지” 같은 규칙은 도메인에 가까운 책임이라 컨트롤러에 남아 있으면 관련 판단 코드가 여러 클래스에 흩어질 수 있어요. (추후 유지보수가 어려워지겠죠 🥲)

다만 HitDecision, TurnDisplay, BetDecision처럼 인터페이스가 늘어난 만큼 추상화 비용도 분명히 생기는데, 그래서 이 구조가 설득력을 가지려면, 단순히 컨트롤러 코드를 도메인 객체로 밀어 넣은 것이 아니라 “입력 결정”과 “게임 규칙”을 분리했다는 점이 드러나야 한다고 생각해요.
지금처럼 외부에서는 결정만 넘기고, 실제 진행은 Game이 담당한다면 방향 자체는 괜찮다고 생각해요!

[Rok93]

2. 출력 콜백의 도메인 결합 문제
   hit할 때마다 중간 카드를 출력해야 하는 요구사항 때문에 TurnDisplay 콜백을 사용했습니다.
   입력은 콜백으로, 출력은 결과 객체를 컨트롤러가 당겨가는 방식이 깔끔하다고 생각하지만, 턴 중간 출력은 당겨갈 수 없어서 콜백으로 처리했습니다.

다만 출력 형식이 바뀌면 콜백 시그니처도 바뀔 수 있다는 점이 걸립니다.
현재는 (String name, List cardNames)만 넘기고 있는데, 이 정도면 괜찮은 건지, 더 좋은 방법이 있는지 의견 부탁드립니다.

---

중간 출력이 필요한 요구사항 때문에 TurnDisplay 같은 콜백 자체는 합리적인 선택이라 생각해요.
다만 말씀하신 것처럼 현재처럼 출력 친화적인 값들을 직접 시그니처에 노출하면, 출력 형식 변경 시 도메인 메서드와 콜백 인터페이스가 같이 흔들릴 수 있어 보여요.
지금 요구사항 범위에서는 name, cardNames 정도만 넘기는 것도 충분히 단순한 선택이지만, 이후 표시할 정보가 늘어날 가능성이 있다면 턴 상태를 담는 별도 객체로 한 번 감싸 두는 방향이 더 변경에 유연할 것 같아요. 😊

[Rok93]

3. 의존 관계 — "아는 것"의 기준
   파라미터, 반환값, 필드, 내부 생성 등 메서드 시그니처에 타입이 등장하면 의존이 생기는 것으로 이해했습니다.

이 기준으로 Players에 있던 hitPlayer(int index, TrumpCard card) 같은 메서드를 제거하고 forEach(Consumer)로 바꿨습니다.
Players는 TrumpCard와 직접 협력할 이유가 없고 전달만 하는 중간자였기 때문입니다.

한편 BlackjackGame의 forEach 람다 안에서 player.hit(deck.deal())을 호출하는데, 이때 TrumpCard를 아는 건 람다를 작성한 Game이지 실행하는 Players가 아니라고 판단했습니다.
"직접 협력하면 알아도 되고, 전달만 하면 알 필요 없다"는 기준이 맞는지 피드백 부탁드립니다.

---

Players가 TrumpCard를 직접 해석하거나 판단하지 않고 단순 전달만 하는 구조였다면, 해당 타입 의존을 제거한 방향은 타당해 보여요.
player.hit(deck.deal())에서 실제로 TrumpCard와 협력하는 주체는 BlackjackGame과 Player이므로, Players가 그 타입을 몰라도 된다는 판단에도 동의합니다만 forEach(Consumer)로 바꾸면서 타입 의존은 줄었지만 컬렉션의 행위를 외부에서 조합하게 된 면도 있어, 일급 컬렉션의 책임까지 같이 약해지지 않았는지는 함께 생각해보면 좋을 것 같아요. 🙂

[Rok93]

4. 기능 변경 시 테스트가 깨지는 범위
   Hand의 isBust()를 Player가 위임하도록 리팩토링했는데, 그래도 Hand의 행위가 바뀌면 PlayerTest, DealerTest의 canHit() 테스트도 함께 깨집니다. 위임을 하더라도 하위 객체의 행위 자체가 바뀌면 상위 테스트도 영향을 받기 때문입니다.

하위 변경이 직접 의존하는 상위 테스트까지 깨뜨리는 게 자연스러운 건지, 아니면 상위 테스트가 안 깨지도록 설계할 수 있는 건지 궁금합니다.
어디까지 깨지는 게 정상이고 어디부터가 설계 문제의 신호인지 기준이 있을까요?

---

생각 정리중

[Rok93]

5. 상태 패턴(State Pattern) 적용
   현재 hit 가능 여부를 canHit()의 if문으로 판단하고 있는데, 상태 패턴을 적용하면 Player의 상태(히팅 중, 스테이, 버스트, 블랙잭)에 따라 행위를 분리할 수 있다고 다음 단계에 적혀 있었습니다.
   이 미션에 상태 패턴을 적용한다면 어떤 구조가 좋을지 방향을 잡고 싶어서 조언 부탁드립니다.

---

상태 패턴 자체가 블랙잭 미션의 필수 요구사항은 아닌 것으로 알고있고,
다음 단계에 적혀 있었습니다 << 다음 단계가 무엇을 말씀하시는 건지 조금 헷갈리는데요.
블랙잭 미션이 사이클2까지 있어보여서, 다음 단계의 의미를 잘 모르겠어요. 🤔

추가적으로 상태패턴을 도입하는 것 까지는 달수가 해보고싶다면 추가로 진행해봐도 좋다고 생각합니다...만!
질문이 조금 잘못됐다고 생각해요.
방향을 제가 먼저 설계를 해드리는게 좋은 방향은 아니라고 생각합니다.

적어도 달수가 생각하는 상태 패턴 도입 방향(or 코드)을 고민에 반영해보신 뒤, 피드백을 요청하신다면 그에대해서 제가 방향을 같이 확인해볼 수 있겠지만, 처음부터 제가 방향을 제시해주는 방식은 우테코 취지에도 조금 벗어났다고 생각해요. 🙄

[Rok93]

6. 상위 기능 변경으로 인한 하위 수정 범위
   배팅 기능이 추가되면서 기존 MatchResult의 역할이 애매해졌습니다. 승패 판정은 여전히 필요하지만 출력에는 수익 금액만 나오고,
   수익 계산을 위해서는 MatchResult + 배팅 금액이 함께 필요합니다.

기존 MatchResult를 수정해서 수익 계산까지 담당하게 할지, 별도의 수익 계산 객체를 만들어야 할지, 그리고 기존 matchResults()를 호출하던 컨트롤러와 View도 함께 바꿔야 하는데 이런 연쇄 수정을 최소화하려면 어떻게 설계하는 게 좋은지 궁금합니다.

저는 별도의 수익 계산 객체를 만들긴 했습니다.

---

관련 코멘트는 해당 코멘트에서 남겨두었는데요.

저는 승패결과와 배당률(?)이 1:1로 매칭된다고 생각해서 배당률이라는 개념을 별도 enum이 아니라 승패결과의 상태로 두었을 것 같아요. 🙂

달수가 진행하신 방향도 생각해보면 Payoff가 실질적으로 WIN,DRAW, LOSE를 각 요소로 갖고있기 때문에 생각해보면 기존의 MatchResult와 유사해보이지 않나요? 😊

저는 기존 MatchResult를 수정하더라도 계산을 담당하게하지는 않을 것 같아요.

기존 MatchResult를 수정해서 수익 계산까지 담당하게 할지, 별도의 수익 계산 객체를 만들어야 할지, 그리고 기존 matchResults()를 호출하던 컨트롤러와 View도 함께 바꿔야 하는데 이런 연쇄 수정을 최소화하려면 어떻게 설계하는 게 좋은지 궁금합니다.

수익 계산 객체를 만들 수도 있을 것 같고 계산은 별도로 수익을 계산하는 역할을하는 객체를 둘 것 같기는합니다. 🤔

저라면 GameResult를 Map<Player, MatchResult>의 일급컬렉션으로 두고
이 일급 컬렉션 객체에게 수익을 계산하는 역할을 위임했을 것 같아요. 🤔

[Rok93]

7. 리팩토링 범위 관리
   이번에 네이밍 변경 + 책임 분리 + 함수형 인터페이스 도입을 동시에 진행하다 보니 변경 범위가 넓어져서 한 커밋에 많은 파일이 바뀌었습니다. 하나를 고치면 연쇄적으로 다른 곳도 수정해야 했습니다.

돌이켜보면 "네이밍 먼저 → 책임 분리 → 인터페이스 도입" 순서로 나눴으면 좋았을 것 같은데, 이런 상황에서 커밋을 어떻게 나누는 게 좋은지 조언 부탁드립니다.

---

커밋 단위를 의식적으로 보는 편이라, 조금 유동적인 것 같아요.

메인 작업을 중점적으로 커밋단위로 볼 것 같고, 네이밍 변경, 리팩터링 작업은 일단 분리하는 방향으로 작업하되
메인 작업자체의 커밋단위가 작다면 네이밍 변경, 리팩터링

사실 생각해보면 네이밍 변경, 리팩터링의 경우에도 크게 변경되는 것이 아니라면 메인작업과 함께 진행해버리기는 합니다. 🤔
말씀하신 것처럼 커밋단위를 쪼갰을 때, 저 방식이 의미가있으려면 리뷰어도 커밋 단위로 코드를 살펴보는 경우에는 의미가있을 것 같으나, PR 단위로 보는 경우에는 커밋 순서가 큰 의미가없을 것 같네요. 😅

어쨋거나 커밋 단위는 작게 유지하는 것이 장점이 크다고 생각하기 때문에
핵심은 커밋단위를 작게 유지하는 것이 중요하다고 생각해요. 😊

[Rok93]

8. 이전 피드백 관련
   전 사이클 피드백 중 반영하지 못한 부분이 있을 수 있어서, 리뷰 후 확인하여 반영하겠습니다.
   추가로 사이클 1에서 Suit, Rank 관련 코멘트와 서비스 레이어 관련 질문에 대해 아직 답변을 받지 못해서 확인 부탁드립니다.

---

DM으로 이전 피드백이 어딜부분을 말씀하신건지 문의드렸었는데요..!

아마도 아래 2개 코멘트에 대해서 답변을 안드린 것 같아요.

1. Suit, Rank 관련 코멘트
2. 서비스 레이어 관련 질문

각 질문이 어디를 말씀하신 것인지, 링크 공유해주시면 좋을 것 같아요. 🥲
코멘트에 묻혀서 찾기가 쉽지 않네요.

(업데이트)

1. Suit, Rank 관련 코멘트

찾으신 것처럼 저는 지금의 경우 리소스를 찾지 못했을 때는 NoSuchElementException 을 예외로 던져주는게 조금 더 적절하다고 생각했어요.

try-catch로 감싼 방식을 예시로 들어주셨는데...!

전 단순히 아래와 같이 IllegalArgumentExceptuon 대신에 NoSuchElementException을 던지면 된다고 생각했어요. 😊

           return Optional.ofNullable(SUIT_MAP.get(koreanName))
                .orElseThrow(() -> new NoSuchElementException("존재하지 않는 카드입니다. cardName:" + koreanName));

한 가지 궁금한 점이 생겨서 질문드립니다. 『이펙티브 자바』 예외 파트와 관련 자료를 찾아보니, of 메서드의 호출자 입장에서는 유효하지 않은 인수를 전달한 것으로 볼 수 있어 IllegalArgumentException이 더 적절해 보입니다.
혹시 이번 상황에서 더 적절하다고 생각하신 표준 예외가 있으신가요? 판단하신 구체적인 배경이나 프로젝트 컨벤션이 있을지 로키님의 생각이 궁금합니다..

저도 이 코드를 다시 유심히 살펴보며 생각해보니 말씀하신 해석에 저도 동의하는 것 같아요!
of 메서드 호출 시점의 문제를 보면, 존재하지 않는 값을 조회했다기보다 유효하지 않은 인자를 전달한 상황이라 IllegalArgumentException이 더 적절해 보이는게 맞는 것 같아요.
제가 남긴 코멘트는 “표준 예외를 한 번 더 검토해보면 좋겠다”는 취지였는데, 다시 살펴보니 이번 케이스에서는 IllegalArgumentException으로 유지하는 판단이 타당하다고 생각합니다. 👍👍

판단하신 구체적인 배경이나 프로젝트 컨벤션 은 제가 알기로는 이런 정의가 생각보다 명확하지는 않은 것 같아요.
이번 판단은 개인적으로 이런 케이스가 영속화 계층에서 찾아오는 경우가 많다보니 습관적으로 NoSuchElementException을 먼저 떠올렸던 것 같아요. 🤔

2. 서비스 레이어 관련 질문

서비스를 “흐름 제어 레이어”로 보고, BlackjackGame은 상태와 규칙을 함께 가지므로 도메인으로 판단했다는 설명은 충분히 납득됐고 또 현재 구조에서 서비스가 단순 패스스루가 될 수 있으니 두지 않겠다는 판단도 합리적이라 생각해요.

다만 서비스/도메인 구분 기준을 단순히 상태 유무보다 유스케이스 조율인지, 도메인 자체 표현인지로 가져가면 더 단단한 설명이 될 것 같고, 그런 의미에서 BlackjackGame은 도메인 쪽에 더 가까워 보입니다. 패키지 위치도 그 의도에 맞게 정리되는게 좋다고 생각했어요. 🙂 (수정해주신 것도 확인했습니다. 🙏)