[🚀 사이클2 - 미션 (블랙잭 베팅)] 카야 미션 제출합니다. by choiyoung69 · Pull Request #1121 · woowacourse/java-blackjack

choiyoung69 · 2026-03-14T06:23:29Z

체크 리스트

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

어떤 부분에 집중하여 리뷰해야 할까요?

안녕하세요 매트 😊
이번 PR에서는 기능 구현 자체보다 객체 설계와 책임 분리가 적절한 방향인지에 대해 특히 피드백을 받고 싶습니다 !
OOP 관점에서 리뷰해주시면 감사하겠습니다!

질문

1. 생성자 변경으로 인해 테스트 코드도 함께 수정되는 것이 자연스러운 건가요?

이번 단계에서 참가자의 이름과 베팅 금액이 모두 Gambler가 가지는 값이며 이후 변경되지 않는 상태라고 판단하여, setter 대신 생성자를 통해 final 필드로 주입하는 방식으로 변경했습니다.
다만 이 과정에서 Gambler의 생성자가 변경되었고, 그 결과 기존 테스트 코드에서도 생성자 호출부를 함께 수정해야 했습니다.
객체의 핵심 상태가 생성 시점에 결정되는 경우라면 생성자 주입이 더 자연스럽다고 생각했지만,
한편으로는 생성자 변경 때문에 테스트 코드를 계속 수정해야 하는 것이 실무에서도 일반적인 방식인지,
혹은 테스트 코드를 수정하지 않도록 구조를 설계하는 다른 방법이 있는지 궁금합니다.

2. 객체 생성 책임은 외부에서 하는 것이 좋은지, 내부에서 하는 것이 좋은 지 궁금합니다.

기존 구현에서는 String 형태의 이름을 넘기면 Participant 내부에서 Name 객체를 생성하는 구조였습니다.
예시

String → Participant 생성 → 내부에서 Name 객체 생성

하지만 이번에는 가능한 한 외부에서 Name 객체를 먼저 생성한 뒤 Gambler에 주입하는 방식으로 변경했습니다.
즉

String → Name 객체 생성 → Gambler 생성

이 방식이 객체의 책임을 더 분리할 수 있고 의존 관계도 명확해진다고 생각했는데,
실무나 객체지향 설계 관점에서도 외부에서 객체를 생성해 주입하는 방식이 더 일반적인 접근인지,
아니면 내부에서 필요한 객체를 생성하는 방식도 충분히 괜찮은 설계인지 궁금합니다.

hyeonic

안녕하세요 카야! 사이클 2도 빠르게 잘 구현해주셨네요 😃

간단히 코멘트 남겼으니 확인해주시고 추가적으로 궁금한 부분이 있다면 언제든 편하게 DM 남겨주세요~

hyeonic · 2026-03-15T08:15:15Z

src/main/java/domain/player/attribute/Money.java

+    public Money(String betAmountInput) {
+        this.betAmount = validateBetAmount(betAmountInput);
+    }


Long 타입으로 돈을 관리하면 어떤 문제가 발생할 수 있을까요?

hyeonic · 2026-03-15T08:17:26Z

src/main/java/domain/player/Gambler.java

 public class Gambler extends Participant{
-    public Gambler(String name) {
-        super(name);
+
+    private final Money betAmount;
+
+    public Gambler(Name name, Hand hand, Money betAmount) {
+        super(name, hand);
+        this.betAmount = betAmount;
+    }
+
+    public Long getAmount() {
+        return betAmount.getBetAmount();
    }


요거 제가 이전 리뷰에서 놓치긴 했는데 컨벤션 맞추면 좋을 것 같네요!

hyeonic · 2026-03-15T08:17:43Z

src/main/java/domain/player/Gambler.java

-    public Gambler(String name) {
-        super(name);
+
+    private final Money betAmount;


Gambler가 Money를 가지도록 구성한 이유는 무엇인가요?

hyeonic · 2026-03-15T08:18:18Z

README.md

 ### 기능
-
-1. 입력 처리
-
- [x] 입력받은 문자열을 ‘,’를 기준으로 파싱한다.
- [x] 파싱한 이름을 검증한다.
-
+1. 게임 세팅
+- [x] 한 명의 딜러가 존재한다.
+  - [x] 딜러는 "Dealer"라는 이름으로 고정된다.
+
+- [x] 여러 명의 참가자가 존재한다.
+  - [x] 참가자는 최소 1명 이상이다.
+  - [x] 참가자는 이름을 가진다. 
+    - [x] 이름은 2 ~ 10자 사이이다.
+    - [x] 이름은 알파벳으로 이루어져 있다.
+  - [x] 참가자는 베팅 금액을 갖는다.
+    - [x] 입력 금액은 양수여야 한다.
+    - [x] 입력 금액은 100억을 넘지 않는다.
+  - [x] 참가자들의 이름은 중복일 수 없다

 2. 게임 진행
-
- [x] 딜러와 참가자들에게 각각 2 장의 카드를 랜덤하게 부여한다. 이때 딜러의 카드는 가장 처음 받은 카드 한 장만 보여준다.
- [x] 각 참가자들별로 bust가 나기 전까지 카드를 더 받는 Hit(y) 또는 그만 받는 Stand(n)를 선택한다.
- [x] ‘A에이스’는 현재 가지고 있는 카드의 합에 따라 자동으로 계산되어 적용된다.
-  - [x] 현재 가지고 있는 카드의 합 + 11의 값이 21 초과인 경우 1로 계산한다.
-  - [x] 현재 가지고 있는 카드의 합 + 11의 값이 21인 경우 11로 계산한다.
-  - [x] 현재 가지고 있는 카드의 합 + 11의 값이 21 미만이면 11로 계산한다.
- [x] 딜러가 처음 받은 2장의 합계가 16이하면 반드시 1장의 카드를 추가로 받아야 하고, 17점 이상이면 추가로 받을 수 없다. (1장 초과 받지 않음)
-
-
-
-3. 결과 처리
-
- [X] 덱은 한 덱(52장)으로 고정한다(이때 하드코딩하지 않는다)
+- [x] 딜러와 참가자는 손패(카드 목록)을 가질 수 있다.
+  - [x] 카드는 랜덤하게 부여된다.
+  - [x] 딜러와 참가자는 게임 시작 시 2장의 카드를 부여받는다.
+    - [x] 덱은 한 덱(52장)으로 고정한다
+  - [x] 카드는 점수를 가지고 있다.
+    - [x] 숫자 카드는 숫자만큼의 점수를 가진다.
+    - [x] ACE인 경우 1 또는 11의 값을 가진다
+    - [x] K, Q, J는 10점을 가진다.
+  - [x] 참가자들은 버스트나기 전까지 카드를 더 받는 Hit(y)할 수 있다.
+  - [x] 참가자들은 카드를 그만 받는 Stand(n)를 선택할 수 있다.
+    - [x] y/n 이외의 입력은 받을 수 없다
+  - [x] 딜러는 처음 2장의 합이 16이하면 1장의 카드를 추가로 받는다.
+
+3. 게임 점수 계산
 - [x] 딜러와 각 참가자들의 카드 합을 구한다.
+  - [x] ACE가 존재하지 않을 경우 모든 카드 점수를 합산한다.
+  - [x] ACE가 존재할 경우 11로 지정한 뒤 합산한 카드 점수가 21을 이상인 경우 1로 환산하여 계산한다
+
+  4. 게임 결과
 - [x] 참가자 승 : 딜러보다 합이 21에 더 가까운 경우 or 딜러가 버스트인 경우(참가자 버스트 X)
- [x] 참가자 무승부: 참가자와 딜러의 합이 같음(버스트 X)
+  - [x] 참가자가 21인 경우 : 베팅 금액의 1.5배를 받는다
+  - [x] 참가자가 21이 아닌 경우 : 베팅 금액만큼 받는다
+- [x] 참가자 무승부: 참가자와 딜러의 합이 같음
+  - [x] 기존 베팅 금액을 그대로 돌려받는다.
 - [x] 참가자 패 : 참가자 버스트 or 딜러보다 합이 적음(딜러가 버스트 X)
+  - [x] 베팅 금액을 잃는다.


요구사항을 꼼꼼하게 잘 정리하였네요 👍

hyeonic · 2026-03-15T08:27:01Z

src/test/java/domain/player/GamblerTest.java

+        Name name = new Name("coco");
+        Hand hand = new Hand();
+        Money money = new Money("10000");
+        Gambler gambler = new Gambler(name, hand, money);


이번 단계에서 참가자의 이름과 베팅 금액이 모두 Gambler가 가지는 값이며 이후 변경되지 않는 상태라고 판단하여, setter 대신 생성자를 통해 final 필드로 주입하는 방식으로 변경했습니다.
다만 이 과정에서 Gambler의 생성자가 변경되었고, 그 결과 기존 테스트 코드에서도 생성자 호출부를 함께 수정해야 했습니다.
객체의 핵심 상태가 생성 시점에 결정되는 경우라면 생성자 주입이 더 자연스럽다고 생각했지만,
한편으로는 생성자 변경 때문에 테스트 코드를 계속 수정해야 하는 것이 실무에서도 일반적인 방식인지,
혹은 테스트 코드를 수정하지 않도록 구조를 설계하는 다른 방법이 있는지 궁금합니다.

카야는 이번에 베팅 금액의 위치를 고려하다 Gambler가 해당 책임을 두는 것이 적합하다 판단한 것으로 이해하였는데요, 베팅 금액이라는 추가적인 비즈니스는 기존 로직에 유기적으로 연결하기 어려운 부분이 있는 것 같아요. 그렇기 때문에 생성자에 대한 수정도 불가피하게 이뤄진 것으로 이해가 되구요!

말씀 주신 것 처럼 어떠한 내부 필드가 추가되며 책임이 커지는 순간 이를 생성하기 위한 생성자도 영향을 받게 될텐데요, 그에 따른 테스트 수정은 불가피할 것 같아요. 그렇기 때문에 이러한 수정은 어느정도 허용하고 넘어가는 편입니다.

최소한의 수정을 구성하고 싶다면 기존 객체는 그대로 두고 신규 기능을 별도 객체로 독립 시킨 뒤 두 객체를 새롭게 관계를 맽도록 하면 수정을 최소화할 수 있지만 불필요한 객체 관계가 생길 수도 있어서 적절한 트레이드오프가 필요하지 않나 생각이 됩니다!

hyeonic · 2026-03-15T08:29:45Z

src/main/java/domain/player/Participant.java

+    public Participant(Name name, Hand hand) {
+        this.name = name;
+        this.hand = hand;
    }


객체 생성 책임은 외부에서 하는 것이 좋은지, 내부에서 하는 것이 좋은 지 궁금합니다.

저는 보통 Name이라는 객체를 외부에서 의존해도 괜찮은지에 대한 관점으로 판단하는 것 같아요. 단순한 String으로 전달하게 되면 Name 객체는 Participant 내에서만 소모될 수 있고 외부로 노출 시키지 않을 수 있기 때문에 의존성을 최소화할 수 있지 않을까 생각합니다.

hyeonic · 2026-03-15T08:31:16Z

src/main/java/domain/player/Participant.java

+    public boolean isBlackJack() {
+        return hand.getCardsSize() == 2 && getTotalScore() == BLACK_JACK_NUMBER;
+    }


제가 알기로 Blackjack은 한 단어라 isBlackjack, BLACKJACK_NUMBER가 맞지 않나 싶네요?! 요건 참고만 해주세요 ㅎㅎ

hyeonic · 2026-03-15T08:31:49Z

src/main/java/domain/game/GamblersGameResult.java

+        this.gamblersResult = gamblers.getGamblers()
                .stream()
-                .filter(result -> result == GameResult.LOSE)
-                .count();
+                .collect(Collectors.toMap(Gambler::getName, gambler -> {
+                    GameResult gameResult = GameResult.determine(dealerTotalScore, gambler.getTotalScore());
+                    if (gameResult == GameResult.WIN && gambler.isBlackJack()) {
+                        return gambler.getAmount() * 3 / 2;
+                    }
+                    if(gameResult == GameResult.WIN) return gambler.getAmount();
+                    if(gameResult == GameResult.LOSE) return -gambler.getAmount();
+                    return 0L;
+                }));
    }


반복된 If를 어떻게 줄일 수 있을까요?

choiyoung69 added 11 commits March 12, 2026 14:14

chore: dto 내부 패키지 생성 및 class 분리

87aee51

docs: readme.md에 기능목록 정리

393a2d2

feat: 베팅 금액 검증

522d292

feat: 금액 받아오는 dto 생성

5693e1b

test: 겜블러의 베팅 금액 검증 테스트 추가

680e615

feat: 베팅 금액을 gambler가 가지도록 기능 추가

32eeef4

feat: 금액을 string -> integer로 변환하는 검증 메서드 추가

5a63634

refactor: 객체를 생성할 때 다른 객체를 생성하지 않고 외부에서 주입받도록 수정

8f1e0eb

refactor: 출력 형식 금액으로 수정

e204224

docs: Readme.md 수정

bb050ef

feat: 1000원 단위 검증 추가

5b79b75

hyeonic requested changes Mar 15, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[🚀 사이클2 - 미션 (블랙잭 베팅)] 카야 미션 제출합니다.#1121

[🚀 사이클2 - 미션 (블랙잭 베팅)] 카야 미션 제출합니다.#1121
choiyoung69 wants to merge 11 commits intowoowacourse:choiyoung69from
choiyoung69:step2

choiyoung69 commented Mar 14, 2026 •

edited

Loading

Uh oh!

hyeonic left a comment

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

hyeonic Mar 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

choiyoung69 commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

체크 리스트

어떤 부분에 집중하여 리뷰해야 할까요?

질문

1. 생성자 변경으로 인해 테스트 코드도 함께 수정되는 것이 자연스러운 건가요?

2. 객체 생성 책임은 외부에서 하는 것이 좋은지, 내부에서 하는 것이 좋은 지 궁금합니다.

Uh oh!

hyeonic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

choiyoung69 commented Mar 14, 2026 •

edited

Loading