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

alstj2384 · 2026-03-12T14:44:32Z

사이클 2 블랙잭 미션 제출합니다! 🙋🏻‍♂️

저번 미션에서는 제출이 늦었지만, 이번에는 가이드에 따라 기능 구현 완료 시점에 맞춰 바로 제출합니다!

사이클 1에서 주신 피드백을 모두 반영하고 싶었으나, 우선순위를 신규 기능 구현(제출 기간 고려)에 두어 아직 반영하지 못한 부분이 많습니다. 😢
리뷰어님이 많은 리뷰이를 관리하시느라 이전 피드백을 기억하시기 어려울 수 있으니, 지난 피드백 중북 여부와 상관없이 편하게 피드백 남겨주세요! 😃
지난 피드백과 종합하여 반영하겠습니다!

체크 리스트

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

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

금액 처리에 대하여

[현재 상황]
사용자의 자산과 관련된 금액 데이터는 엄격해야 한다고 들어서, 이번 미션에서는 이 부분을 신경써보고 싶었습니다. 현재는 단판이지만, 여러 라운드가 진행되는 상황과 금액 제한 없는 배팅이 가능하도록 혼자만의 규칙을 세워 고민했습니다.

[고민 지점]
블랙잭 승리 시 배당률(1.5배)로 인해 소수점이 발생할 수 있는 상황에서, 두 가지 방향을 검토했습니다.

도메인 정책으로 제약(짝수만 배팅): 배팅 금액을 짝수로 제한하면 소수점 계산 문제를 원천 봉쇄할 수 있었습니다. 하지만 "내부 구현의 편의를 위해 도메인 로직(배팅 자유도)를 제한하는 것은 옳지 않다"고 생각이 들어 철회했습니다.
자료형 선택: 제한 없는 금액과 정밀한 계산을 위해 BigInteger와 BigDecimal을 고려했습니다:

BigInteger: 소수점 자리만큼 미리 곱하여 정수 연산으로 처리
BigDecimal: API에서 제공하는 소수점 연산 기능을 직접 활용

[최종 결정: BigDecimal]
두 방식 모두 구현해 본 결과, BigDecimal이 더 명확하게 관리할 수 있다고 판단하여 선택했습니다.

Player와 BetMoney 설계

[현재 상황]
현재 BlackjackGame이 List<String>으로 이름을 한 번에 받아 플레이어를 생성하는 구조다 보니, 이름 입력 후 배팅 금액을 추가로 받는 과정에서 설계를 세 가지 방향으로 고민했습니다.

1번: Player에서 BetMoney 필드를 final로 관리 & BetMoney 가변

Class Player{
    private final BetMoney betMoney // betMoney 가변
    public void setBetMoney(int value){
        betMoney.setValue(value);
    }
}

장점 : 기존 생성 방식 유지 가능
단점: BetMoney가 가변으로, 방어적 복사 필요 및 잠재적 버그 위험 존재, 결국 setter가 필요함.

2번: Player에서 BetMoney final없이 관리 & BetMoney 불변

Class Player{
    private BetMoney betMoney // betMoney 불변
    public void setBetMoney(int value){
        betMoney = BetMoney.of(value);
    }
}

장점 : 기존 생성 방식 유지 가능, BetMoney 불변으로 관리 가능
단점: Setter 사용 필요, 객체 생성 후 상태가 변하므로 잠재적 버그 위험 존재

3번: Player에서 BetMoney 필드를 final로 관리 & BetMoney 불변

Class Player{
    private final BetMoney betMoney // betMoney 불변
    public Player(... , int value){
        betMoney = BetMoney.of(value);
    }
    // setter 없음
}

장점 : 모두 불변으로, 잠재적 버그 위험에서 상대적으로 안전함.
단점: 현재 생성 로직 전면 수정 필요 및 View에서 이름/금액을 모두 한 번에 넘겨야 함

저는 우선 빠른 구현을 위해 2번을 선택했습니다.
금액 데이터(BetMoney) 자체는 불변하게 보호할 수 있었으나, 여전히 Player의 Setter를 통해 상태가 변경될 수 있다는 점이 마음에 걸렸습니다.

그래서 구조적 안전성을 위해 3번으로 리팩토링을 수행할까 합니다. (아직 못 했습니다!)
다만 3번 도입 시 발생하는 중복 검증에 대해 고민해 보았고, 다음과 같은 결론을 내렸습니다.

[상황] View에서 이름과 금액을 모아 도메인으로 넘겨야 하므로 View 단의 1차 검증(이름 중복, 길이, 음수 여부 등)과 도메인의 2차 검증이 겹치게 됩니다.
[사고] 처음에는 정책 노출과 검증 중복이 비효율적이라고 생각했으나, 웹 사이트의 회원가입 절차를 떠올리자 생각이 바뀌었습니다. 회원가입 시 아이디 길이, 중복, 비밀번호 길이 등의 정책이 노출되고 1차적으로 검증하는 것 처럼, View에서의 정책 노출과 검증도 비슷하다는 생각이 들었습니다.
[결론] 이름 중복이나 배팅 금액의 음수 제한같은 정책은 사용자도 알아야 할 규칙이므로, View에서 이를 표현하고 검증하는 것은 자연스러운 구조라고 판단했습니다!

결국 다음과 같은 구조를 갖게됩니다:

플레이어 이름 입력 & View에서 중복 및 길이 검증 (아직 Players 생성 x)
플레이어 배팅 금액 입력 & View에서 금액 검증
배팅 모두 입력 시 Players를 일괄적으로 생성(도메인 검증 수행)

[질문]
위와 같은 상황(입력 시기가 다른 데이터를 처리할 때)에 더 적절한 방법이 있을까요?
3번으로 리팩토링을 수행하기로 결정한 이유와 사고 과정은 타당하다고 생각하시나요?

도메인과 입출력의 분리에 대해서 (03.13 20:15 추가)

[질문]
"입력 방식의 추가로 도메인이 수정되는 상황"에 대해 크루와 토론을 통해 "입력 방식이 도메인에 영향을 주는 구조는 적절하지 않다" 라는 결론에 도달했습니다.
도메인은 외부의 입력 방식과 무관하게 본질적인 형태를 유지하고, Controller나 View 같은 외부 계층에서 도메인이 원하는 형태로 데이터를 가공해서 넘겨줘야 한다는 의견인데요!
이런 방향성은 적절할까요? 현업에서도 이런 구조로 개발이 진행되는지 궁금합니다!

Gomding

안녕하세요 제제!
사이클2 빠르게 진행해주셨네요 🙇
코멘트 남겼으니 확인부탁드려요~
이전 PR 에 머지하면서 남겼던 코멘트는 이번에 고려하지 않으신것 같은데
함께 반영해주세요

추가로 궁금한 점 있으면 DM 이나 코멘트 남겨주세요!

README.md

src/main/java/BlackjackController.java

src/main/java/domain/card/Hand.java

src/main/java/domain/Score.java

src/main/java/domain/participant/Player.java

src/main/java/domain/participant/Participant.java

src/main/java/domain/BlackjackGame.java

src/main/java/view/ResultView.java

README.md

alstj2384

안녕하세요 찰리!

오늘 "상태 패턴"에 알게 되어 학습 후 적용하여 리팩토링 해보았습니다.(아직 많이 어렵습니다....)
그 외에도 흐름 제어를 담당하던 BlackjackGame을 삭제한 후, Controller에서 도메인을 활용하여 흐름을 제어하도록 수정했습니다!

src/main/java/domain/participant/BetMoney.java

src/main/java/domain/card/Hand.java

src/main/java/domain/participant/Player.java

src/main/java/domain/BlackjackGame.java

src/main/java/domain/Rank.java

src/main/java/domain/state/State.java

Gomding

안녕하세요 제제!
상태 패턴 도입해주셨네요 😄
몇가지 의견 남겼으니 확인해주세요~

궁금한 점 있으면 언제든 DM 이나 코멘트 남겨주세요!

src/main/java/BlackjackController.java

src/main/java/domain/Rank.java

src/main/java/domain/card/Hand.java

src/main/java/domain/participant/BetMoney.java

src/main/java/domain/state/State.java

src/main/java/domain/state/Bust.java

src/main/java/domain/BlackjackGame.java

src/main/java/domain/state/State.java

src/main/java/domain/state/Hit.java

alstj2384

안녕하세요 찰리!
피드백 반영하여 제출합니다 😊

src/main/java/domain/state/State.java

Gomding

안녕하세요 제제!
고민과 함께 적절하게 수정해주셨네요~
추가로 몇가지 코멘트 남겼는데 확인해주세요!
다음 요청에는 머지해도 될 것 같아요 :)

궁금한 점 있으면 언제든 DM 이나 코멘트 남겨주세요 🙇

src/main/java/view/ResultView.java

src/main/java/domain/state/State.java

src/main/java/domain/state/Bust.java

src/main/java/domain/state/Running.java

src/main/java/domain/state/Hit.java

src/main/java/domain/participant/BetMoney.java

src/main/java/view/ResultView.java

src/main/java/domain/state/Hit.java

src/main/java/domain/Result.java

alstj2384

피드백 반영하여 제출합니다! 😊

src/main/java/domain/state/State.java

src/main/java/domain/state/Hit.java

src/main/java/domain/state/Running.java

src/main/java/view/ResultView.java

Gomding

안녕하세요 제제!
고민과 함께 잘 반영해주셨네요~
머지할 예정이라고 했지만..
몇가지만 함께 점검해보면 좋겠어서 RC 드립니다 😓

궁금한 점 있으면 DM 이나 코멘트 남겨주세요! 🙏

src/main/java/domain/card/Hand.java

Gomding · 2026-03-22T05:48:20Z

src/main/java/domain/card/Hand.java

-        this.cards = List.copyOf(hand.getCards());
+    public static Hand of(List<Card> cards) {
+        return new Hand(cards);
    }


해당 정적 팩토리 메서드는 어떤 의도로 만드신건가요?

아래 생성자와 어떤 차이가 있을까요?

private Hand(List<Card> cards) { this.cards = cards; }

이 부분은 어떻게 하는 게 적절할지 고민입니다.

Hand 객체 생성 방법이 "Hand의 복사본을 반환하는 정적 팩토리 메서드"와 "new를 이용한 생성" 두 가지가 혼재되면 사용자 입장에서 "뭘 사용해야 하지?" 하고 헷갈릴 수도 있을 거 같았습니다.

그래서 정적 팩토리 메서드가 포함되는 클래스의 생성자는 모두 정적 팩토리 메서드를 사용하도록 구현했는데요.

따로 특수한 목적이 있는 생성자만 정적 팩토리 메서드를 이용하고,
예시로 주신 것 처럼 기본적인 생성은 new를 이용한 생성을 하도록 하는 게 적절할까요?
찰리의 의견이 궁금합니다 🤔�

고민을 적절하게 해주셨네요!
팀의 컨벤션, 취향에 따라 달라질 규칙으로 보이네요 ㅎㅎ
일단 저는 기본적인 필드를 받아서 생성하는 것이라면 new 를 이용한 생성자를 사용하는게 명확하다고 생각해요!

그런데 new 생성자를 private 으로 닫아두신것을 이제 봤네요 😓
만약 private 으로 닫아두셨다면 저는 제제의 구현대로 정적 팩토리만 제공한다! 라는 방향도 동의합니다

혼란을 드려서 죄송해요 🥲🥲🥲

Gomding · 2026-03-22T06:15:52Z

src/main/java/domain/participant/Dealer.java

-    public boolean decideHitStand(Score boundary) {
-        return getTotalSum().isLessThanOrEqualTo(boundary);
+    public boolean isHittable() {
+        return state.hand().totalSum().isLessThanOrEqualTo(Score.DEALER_HIT_STAND_BOUNDARY);


state 에서 hand 를 꺼내서 총점을 계산하는것이 옳을까요!
디미터 법칙, Tell Dont Ask 원칙으로 고민해보시죠 😄

반영해서 리팩토링 했습니다!

한 가지 궁금한 점이 있는데, 리팩토링 과정에서 내부 클래스의 메서드 결과를 그대로 내보내는 경우가 생기는데, 이럴 때마다 설계가 잘못된건가? 라는 생각이 듭니다. 물론 해당 클래스에서 수행할 수 있는 로직이 포함된다면 그 자체로 의미가 있겠지만, 그렇지 않은 경우(래핑만 하는 경우)에 찝찝한 느낌이 드는데요.

클래스의 결괏값을 래핑만 하는 경우는 어쩔 수 없이 일어나는 걸까요?
혹은 설계가 잘못되었는지 검사해 볼만한 트리거로 사용해 볼만 할까요?
물론 정도에 차이가 있겠지만, 찝찝한 느낌이 드는 경우 어떻게 생각해 보면 좋을지 궁금해요.

고민을 해볼 수 있는 부분이네요 ㅎㅎ
설계에 대해 점검을 해볼 수 있는 느낌이라 생각해요!
다만 디미터 법칙의 탄생 배경에 대해서는 이미 알고 계실거라 생각해요 :)
세부적인 것에 대한 의존을 없애고 협력하는 객체하고만 대화를 하는것이죠

세부적인 것을 알게되면 어떤 단점이 있는지는 제제도 알고 계시겠죠? 😄

src/main/java/ui/BlackjackController.java

Gomding · 2026-03-22T06:20:31Z

src/main/java/domain/participant/Participant.java

-            throw new IllegalArgumentException(Card.FIELD_CAN_NOT_BE_NULL);
-        }
-    }
+    protected State state;


단순 질문인데
state 는 final 로 재 할당이 불가능하도록 하는것은 고려해보셨을지 궁금해요!
불변도 고려해보셨을까 궁금하여..
제제의 선택이유가 궁금합니다 😄

불변으로 하는 방법은 고민을 해보진 못했습니다. 😭

객체를 반환하는 상태 패턴에서 final을 사용하지 않는 게 구조적으로 가능한가? 라는 궁금증이 들어요.

Participant가 아니더라도 State를 사용하는 입장에선 변화되는 State 상태를 적용하기 위해선 final이 없어야 할 거 같은데, 혹시 더 적절한 방법이 있을지 궁금합니다.

구조적으로 가능은 하지만 구현 복잡도가 높아지는 단점이 있을 거에요
상태가 변경될때마다 모든 Participant 까지 새롭게 반환해야하니까요 😅

제 기준에서는 오버엔지니어링 하지않고 적절하게 구현해주셨다고 생각하여
해당 부분도 고민해보셨는지 궁금했어요!

Gomding · 2026-03-22T06:35:02Z

src/main/java/ui/BlackjackController.java

+    private void hitByDecision(Deck deck, Player player) {
+        if (inputView.readHitStand(player)) {
+            player.draw(deck.draw());
+            return;
+        }
+        player.stay();
+    }


히트냐 스탠드냐에 따라 어떤것이 호출될지는 도메인 쪽에 맡겨봐도 되겠네요

boolean isHit = inputView.readHitStand(player); 도메인 객체 호출(isHit);

src/main/java/ui/BlackjackController.java

Gomding · 2026-03-22T06:43:17Z

src/main/java/ui/BlackjackController.java

+        List<PlayerResult> playerResults = blackjackGame.collectPlayerResults();
+
+        List<Profit> profits = blackjackGame.calculatePlayerProfits(playerResults);


승패 결과와 이익을 분리해서 계산하는 메서드를 호출하는군요
둘은 크게 보면 블랙잭의 게임 결과라고 생각해요

현재 해당 메서드 둘은 순서대로 호출하는것이 전제조건으로 만들어진 것 같아요
그렇다면 호출 순서 혹은 시간 흐름에 결합이 생긴것인데
이런 결합이 있는거라면 blackjackGame 내부에서 흐름을 만들어주는것이 좋다고 생각해요
제제는 어떻게 생각하시나요?

동의합니다. 메서드간 결합도가 생겼었네요.
내부 흐름으로 관리하며 말씀대로 "결과"라는 하나의 큰 흐름에서 하나의 메서드로 처리해도 어색하지 않겠다는 생각도 들었습니다.

현재 이를 반영하여 리팩토링 수행했습니다!

외부에 순서가 호출 순서가 생기는 어쩔 수 없는 경우가 있긴한데
그런 케이스가 있다면 의심해보는게 좋습니다! ㅎㅎ
내부에서 하나의 흐름으로 가져가야할 것이 외부에 노출된 것은 아닌가? 하는 의심이요

Gomding · 2026-03-22T06:44:22Z

src/main/java/ui/BlackjackController.java

+        resultView.printCardsWithResult(ParticipantResultDto.toDto(players, dealer));
+        resultView.printProfits(ProfitsDto.toDto(profits, dealerProfit));


위 코멘트와 동일한 의도로
결국 승패결과와 이익은 게임 결과 라는 큰 개념으로 함께 응답해도 되는 것이라 생각해요 🤔

src/main/java/ui/BlackjackController.java

alstj2384

안녕하세요 찰리!
피드백 반영하여 제출합니다 😊

alstj2384 · 2026-03-23T02:18:07Z

src/main/java/domain/card/Hand.java

-        this.cards = List.copyOf(hand.getCards());
+    public static Hand of(List<Card> cards) {
+        return new Hand(cards);
    }


이 부분은 어떻게 하는 게 적절할지 고민입니다.

Hand 객체 생성 방법이 "Hand의 복사본을 반환하는 정적 팩토리 메서드"와 "new를 이용한 생성" 두 가지가 혼재되면 사용자 입장에서 "뭘 사용해야 하지?" 하고 헷갈릴 수도 있을 거 같았습니다.

그래서 정적 팩토리 메서드가 포함되는 클래스의 생성자는 모두 정적 팩토리 메서드를 사용하도록 구현했는데요.

따로 특수한 목적이 있는 생성자만 정적 팩토리 메서드를 이용하고,
예시로 주신 것 처럼 기본적인 생성은 new를 이용한 생성을 하도록 하는 게 적절할까요?
찰리의 의견이 궁금합니다 🤔�

alstj2384 · 2026-03-23T02:25:18Z

src/main/java/domain/participant/Participant.java

-            throw new IllegalArgumentException(Card.FIELD_CAN_NOT_BE_NULL);
-        }
-    }
+    protected State state;


불변으로 하는 방법은 고민을 해보진 못했습니다. 😭

객체를 반환하는 상태 패턴에서 final을 사용하지 않는 게 구조적으로 가능한가? 라는 궁금증이 들어요.

Participant가 아니더라도 State를 사용하는 입장에선 변화되는 State 상태를 적용하기 위해선 final이 없어야 할 거 같은데, 혹시 더 적절한 방법이 있을지 궁금합니다.

alstj2384 · 2026-03-23T02:35:31Z

src/main/java/domain/participant/Dealer.java

-    public boolean decideHitStand(Score boundary) {
-        return getTotalSum().isLessThanOrEqualTo(boundary);
+    public boolean isHittable() {
+        return state.hand().totalSum().isLessThanOrEqualTo(Score.DEALER_HIT_STAND_BOUNDARY);


반영해서 리팩토링 했습니다!

한 가지 궁금한 점이 있는데, 리팩토링 과정에서 내부 클래스의 메서드 결과를 그대로 내보내는 경우가 생기는데, 이럴 때마다 설계가 잘못된건가? 라는 생각이 듭니다. 물론 해당 클래스에서 수행할 수 있는 로직이 포함된다면 그 자체로 의미가 있겠지만, 그렇지 않은 경우(래핑만 하는 경우)에 찝찝한 느낌이 드는데요.

클래스의 결괏값을 래핑만 하는 경우는 어쩔 수 없이 일어나는 걸까요?
혹은 설계가 잘못되었는지 검사해 볼만한 트리거로 사용해 볼만 할까요?
물론 정도에 차이가 있겠지만, 찝찝한 느낌이 드는 경우 어떻게 생각해 보면 좋을지 궁금해요.

src/main/java/domain/card/Hand.java

src/main/java/ui/BlackjackController.java

alstj2384 · 2026-03-23T03:30:19Z

src/main/java/ui/BlackjackController.java

+        List<PlayerResult> playerResults = blackjackGame.collectPlayerResults();
+
+        List<Profit> profits = blackjackGame.calculatePlayerProfits(playerResults);


동의합니다. 메서드간 결합도가 생겼었네요.
내부 흐름으로 관리하며 말씀대로 "결과"라는 하나의 큰 흐름에서 하나의 메서드로 처리해도 어색하지 않겠다는 생각도 들었습니다.

현재 이를 반영하여 리팩토링 수행했습니다!

src/main/java/ui/BlackjackController.java

Gomding

안녕하세요 제제!
치열한 고민과 함께 미션 진행하느라 고생하셨어요 🎉
미션은 이만 머지하겠습니다!

앞으로 우테코 생활도 다음 미션도 화이팅입니다 💪

Gomding · 2026-03-23T12:46:28Z

src/main/java/domain/card/Hand.java

-        this.cards = List.copyOf(hand.getCards());
+    public static Hand of(List<Card> cards) {
+        return new Hand(cards);
    }


고민을 적절하게 해주셨네요!
팀의 컨벤션, 취향에 따라 달라질 규칙으로 보이네요 ㅎㅎ
일단 저는 기본적인 필드를 받아서 생성하는 것이라면 new 를 이용한 생성자를 사용하는게 명확하다고 생각해요!

그런데 new 생성자를 private 으로 닫아두신것을 이제 봤네요 😓
만약 private 으로 닫아두셨다면 저는 제제의 구현대로 정적 팩토리만 제공한다! 라는 방향도 동의합니다

혼란을 드려서 죄송해요 🥲🥲🥲

Gomding · 2026-03-23T12:51:13Z

src/main/java/domain/participant/Dealer.java

-    public boolean decideHitStand(Score boundary) {
-        return getTotalSum().isLessThanOrEqualTo(boundary);
+    public boolean isHittable() {
+        return state.hand().totalSum().isLessThanOrEqualTo(Score.DEALER_HIT_STAND_BOUNDARY);


고민을 해볼 수 있는 부분이네요 ㅎㅎ
설계에 대해 점검을 해볼 수 있는 느낌이라 생각해요!
다만 디미터 법칙의 탄생 배경에 대해서는 이미 알고 계실거라 생각해요 :)
세부적인 것에 대한 의존을 없애고 협력하는 객체하고만 대화를 하는것이죠

세부적인 것을 알게되면 어떤 단점이 있는지는 제제도 알고 계시겠죠? 😄

Gomding · 2026-03-23T12:53:44Z

src/main/java/domain/participant/Participant.java

-            throw new IllegalArgumentException(Card.FIELD_CAN_NOT_BE_NULL);
-        }
-    }
+    protected State state;


구조적으로 가능은 하지만 구현 복잡도가 높아지는 단점이 있을 거에요
상태가 변경될때마다 모든 Participant 까지 새롭게 반환해야하니까요 😅

제 기준에서는 오버엔지니어링 하지않고 적절하게 구현해주셨다고 생각하여
해당 부분도 고민해보셨는지 궁금했어요!

Gomding · 2026-03-23T12:55:35Z

src/main/java/ui/BlackjackController.java

+        List<PlayerResult> playerResults = blackjackGame.collectPlayerResults();
+
+        List<Profit> profits = blackjackGame.calculatePlayerProfits(playerResults);


외부에 순서가 호출 순서가 생기는 어쩔 수 없는 경우가 있긴한데
그런 케이스가 있다면 의심해보는게 좋습니다! ㅎㅎ
내부에서 하나의 흐름으로 가져가야할 것이 외부에 노출된 것은 아닌가? 하는 의심이요

alstj2384 added 12 commits March 12, 2026 11:54

docs: README 추가된 기능 업데이트

6a1b873

feat(BetMoney): BetMoney 기능 추가 및 테스트 추가

60f7900

refactor(Participant): 결과(블랙잭, 버스트) 확인 테스트 및 기능 추가

f7bada6

test(Player): 무승부 테스트 추가

5136894

refactor(Participant): 결과 집계 로직 및 테스트 추가

ad3854c

refactor: 계산 결과 출력 로직 작성

d610ad2

feat: 배팅 금액을 입력받는 기능 추가

1814846

fix: 중복 닉네임 검사 시 공백을 나중에 제거하여 중복이 발생할 수 있는 문제 수정

ad3283b

refactor: 사용하지 않는 Result 클래스와 테스트 제거

246a3da

refactor(Participant): getResult 내부 메서드 추출

b5cbf2f

refactor: 패키지 구조 변경

cca26a5

fix: 결과 출력 시 함께 소수점이 표기되는 문제 수정

65d8cc8

Gomding requested changes Mar 13, 2026

View reviewed changes

alstj2384 added 17 commits March 14, 2026 10:46

refactor(Score): Score를 record로 변경 및 미사용 메서드 제거

7d128f9

refactor(Score): 자주 쓰이는 Score 값을 상수로 선언하여 재사용하도록 변경

3b96e03

refactor(Player): 사용되지 않는 생성자 제거

e755fd2

refactor(Dealer): 딜러의 히트스탠드 판별 메서드 이름을 의도가 드러나도록 변경

0c5576b

refactor(Rank): 메서드 및 매개변수 네이밍을 명확하게 수정

08742df

refactor(BlackjackController): Controller에서 BlackjackGame을 갖지 않도록 수정

ad2e4ac

refactor: Player만 갖는 속성이 Participant에 존재하여 Dealer가 불필요한 정보를 갖던 구조 수정

fe07531

refactor(Name): 이름 길이 예외 메시지에 상수를 이용하여 표현하도록 수정

7d82e85

refactor(Player): 생성자를 정적 팩토리 메서드를 사용하여 생성 의도를 명확히 알 수 있도록 변경

276bf95

refactor(Dealer): 생성자를 정적 팩토리 메서드로 사용하도록 변경

794b976

refactor(Name): 생성자를 정적 팩토리 메서드를 사용하도록 변경

5658561

refactor(Hand): 생성자를 정적 팩토리 메서드를 사용하도록 변경

209f013

refactor(Deck): 생성자를 정적 팩토리 메서드를 사용하도록 변경

7aeb199

refactor(Deck): Deck 구현체를 ArrayDeque로 변경

7acbcba

refactor: 모든 종류의 카드를 미리 생성하여 재활용하도록 수정

7e6d2e0

refactor(BetMoney): 생성 메서드 이름을 of -> valueOf로 변경

1996e57

refactor: 공통적으로 사용되는 예외 메세지를 CommonExceptionMessage로 위치 변경

273d637

alstj2384 added 4 commits March 16, 2026 14:31

refactor(Hand): copyOf시 가변 컬렉션을 반환하도록 수정

0b20c9a

refactor: BlackjackGame 제거 및 컨트롤러가 흐름을 수행하도록 변경

e2bd26a

refactor(State): 승패 판정을 상태가 판단하도록 수정

e828796

refactor: 상태 패턴을 적용하여 리팩토링

8b73ed1

alstj2384 commented Mar 16, 2026

View reviewed changes

Gomding requested changes Mar 17, 2026

View reviewed changes

alstj2384 added 3 commits March 18, 2026 21:29

refactor: 각 상태에서 할 수 없는 행동 수행 시 예외가 발생하도록 수정

71b8745

refactor: 블랙잭, 버스트, 스테이 상태의 공통된 예외 및 로직을 Finished 추상 클래스로 묶어 처리하도록 변경

c305679

refactor: 상태 상속 계층 추가

2c7aea4

alstj2384 commented Mar 18, 2026

View reviewed changes

src/main/java/domain/state/State.java Show resolved Hide resolved

Gomding requested changes Mar 19, 2026

View reviewed changes

alstj2384 added 9 commits March 20, 2026 15:31

refactor: Score 클래스의 sub 메서드 네이밍을 subtract로 변경

4ad5596

refactor: Result 도메인의 odd 변수 이름을 odds로 변경

baf4b0a

refactor: Hit 상태 변환 시 매개변수 hand를 복사한 후 할당하도록 변경

e214037

refactor: jedge에서 적절한 예외클래스를 사용하도록 변경

a0b6b25

refactor: printDealerHitStand의 매개변수 이름을 value -> hit로 명확하게 변경

21e5c1a

refactor: dto를 도입하여 view에서 도메인을 의존하지 않도록 변경

8b5fc46

refactor: BlackjackGame에서 실행 흐름을 관리하도록 변경

b170534

refactor: BetMoney의 sub를 subtract로 명확하게 변경

248fd1b

refactor: BetMoney의 메서드 이름이 제대로 바뀌지 않았던 부분 수정

b62fb74

alstj2384 commented Mar 22, 2026

View reviewed changes

Gomding requested changes Mar 22, 2026

View reviewed changes

alstj2384 added 5 commits March 22, 2026 19:39

refactor: 중복된 의미의 상수를 하나로 관리하도록 변경

523e632

refactor: Inputview에서 도메인을 의존하지 않도록 수정

4aa02f0

refactor: 이름과 배팅 금액 입력 종합을 view에서 하도록 변경

feeeffc

refactor: hitStand 단계를 BlackjackGame 내부에서 수행하도록 변경

a6d43cc

refactor: 디미터의 법칙을 준수하도록 변경

8caff45

alstj2384 commented Mar 23, 2026

View reviewed changes

Gomding approved these changes Mar 23, 2026

View reviewed changes

Gomding merged commit d5d09cc into woowacourse:alstj2384 Mar 23, 2026

		List<PlayerResult> playerResults = blackjackGame.collectPlayerResults();

		List<Profit> profits = blackjackGame.calculatePlayerProfits(playerResults);

		resultView.printCardsWithResult(ParticipantResultDto.toDto(players, dealer));
		resultView.printProfits(ProfitsDto.toDto(profits, dealerProfit));

Conversation

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

Uh oh!

사이클 2 블랙잭 미션 제출합니다! 🙋🏻‍♂️

체크 리스트

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

금액 처리에 대하여

Player와 BetMoney 설계

도메인과 입출력의 분리에 대해서 (03.13 20:15 추가)

Uh oh!

Gomding left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alstj2384 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Gomding left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alstj2384 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Gomding left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alstj2384 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Gomding left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

alstj2384 commented Mar 12, 2026 •

edited

Loading

alstj2384 left a comment •

edited

Loading

alstj2384 left a comment •

edited

Loading