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

kdongsu5509 · 2026-03-14T07:13:34Z

체크 리스트

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

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

이번에 추가하게 된 BetAmount 도메인은 Player 객체가 관리하는 것이 가장 적합하다고 판단하여 3개 이상의 인스턴수 변수를 생성하지 말라는 제한 조건을 어기면서 시도해보았습니다. 이러한 접근이 적합했을 지 아직 확신을 가지지는 못하여서 아직 찝찝함을 느끼고 있습니다.
이런 찝찝함이 느껴지는 여러가지 부분이 존재하지만 특히 이전에는 Hand 의 정보로만 게임 결과를 판단하면 되어서 GameState 가 관리하던 결과 비교 메서드를 BetAmount 정보가 추가로 필요함에 따라 Player 로 위치를 하게 되었다는 점 때문에 이전의 책임 분배가 잘못된 것인지 혹은 현재의 책임이 잘못된 것인지 판단이 어려움 점이 가장 큰 이유입니다.

그 다음에 플레이어의 인스턴스 변수가 추가됨에 따라 플레이어를 생성하는 테스트 로직이 상당 수 변경되게 될 것으로 생각하여, 현재의 방식인 BetAmount.empty() 를 통한 0 값을 가진 객체를 생성하는 기본 생성자와, bet() 메서드를 통해 플레이어에게 입력받은 금액을 가진 새로운 BetAmount 를 만들 수 있게 하였습니다. 저는 테스트 변경을 피할 수 있고, 추가로 불변 객체이기 때문에 괜찮을 것이다라는 판단을 하여서 시도해보았습니다.

추가적으로 이전 step1 에서 리뷰어님이 남겨주신 리뷰를 선 반영을 해보니 이번 베팅하기 기능 추가 시 기존의 클래스들과 흐름을 상당히 편하게 이해할 수 있었습니다. 😁이 덕분에 객체 지향에서도 읽기 쉬움 코드의 중요성을 놓치면 안되겠다라는 생각 역시 할 수 있게 되어 정말 감사합니다!

딜러와 플레이어를 추가하였고, 그들의 공통 조상인 참가자를 추가함. 이후 카드와 카드들을 관리하는 덱의 정의를 추가함.

- 신규 덱 제공 기능 테스트 - 카드 뽑기 기능 테스트 추가(정상, 실패)

- 새로운 덱 제공 기능 - 카드 선택 기능 을 추가하였습니다.

Ace 값 판정과 전체 카드 점수 합 기능은 상호 의존성을 띄기 때문에 Ace는 제외한 카드 점수 합을 계산하는 기능을 추가함.

- add card score total sum feature - add bust discrimination feature

딜러 생성 시 필요한 파라미터 Deck의 인스턴스 종류를 명시함

공통 로직을 제거하기 위해 participant 추가

딜러만의 고유한 카드 추가 로직을 위해 별도의 메서드가 선언되어 있습니다. 차후 다른 개발자가 addCard 메서드 호출 시 현재 설계상으로는 오류가 발생하기 때문에 UnsupportedOperationException을 던지는 것으로 override 해두었습니다

- 모든 원시 값과 문자열을 포장한다라는 프로그래밍 요구 사항과 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다라는 요구사항을 충족하기 위해 상태 패턴 도입

…roller and BlackJackGame

로컬 ì½코드를 병합하지 않고 진행한 수정으로 인한 충돌 해결

찾기 오버헤드를 줄이기 위해 변경. 현재는 n=5라는 조건 때문에 찾기 시 성능을 고려하지 않았으나, 이 또한 변경가능한 요구사항이기 때문에 변경하기로 결정함

복잡한 관계를 가진 game state 구조 정리

- 퍼블릭 인터페이스를 기준으로 다시 작성하여 객체별 책임을 한 눈에 볼 수 있도록 정리하였음

echo724

안녕하세요 라티!
일단 리뷰 기다려주셔서 감사합니다. 빠르게 드리고 싶었는데 죄송하네요. 그래도 기다리신 만큼 좋은 피드백 남기려고 노력했습니다! 피드백 드리기 이전에, 일단 지난 피드백 반영 너무 잘 해주신 것 같습니다! 게임 상태를 줄여서 코드 이해가 훨씬 쉬워진게 눈에 보이더라구요! 잘 학습하시고 적용하신 부분인 것 같아 보입니다 ㅎㅎ

커멘트 외에도 전반적인 피드백을 드리자면, 아래 부분을 좀 더 신경 써보시면 성장에 도움이 될 것 같아서 남깁니다.

캡슐화: 객체가 어떤 상태(값)들을 갖고 있는지 파악해보시고, 해당 객체에서 값을 빼오기 보다는 갖고 있는 값들로 결과를 구해오는 식으로 설계해보시면 좋을듯 합니다. 객체 내부에 값이 대부분 있는데, 객체 외부로 꺼내서 다시 주입하는 형태의 코드가 종종 보이더라구요. (ex MultiPlayers). 이 부분 신경써서 봐보시면 객체지향에 맞는 코드, 그리고 객체지향이 아니더라도 유지 보수/가독성 좋은 코드를 짜는데 도움이 될 것입니다.
데이터 일관성 고려: 현재 많은 부분에서 특정 상태의 객체(e.g. Player)를 찾는 과정에서 스트림 순회를 해서 가장 첫 번째 객체를 찾고 있더라구요. 한 번 순회해서 찾은 값이 다시 한 번 순회해서 찾을 때 리턴값과 일치한다고 보장할 수 있을까요? 현재는 성능에 문제가 있을 뿐더러, 다중 사용자나 다중 게임 실행 요구사항이 생길 경우 동시성 문제가 생길 수 있는 코드입니다. 혹시 이런 패턴으로 작성하신 구체적인 이유가 있을까요? 있다면 공유해주시면 감사하겠습니다! 만약 그렇지 않다면 발생가능한 문제에 대해서 고민해보시고 학습해보시면 도움이 될 것 같습니다!

이 부분들 빠르게 수정해보시고 리뷰 요청 다시 해주세요! 화이팅입니다~

echo724 · 2026-03-17T04:07:21Z

src/main/java/controller/BlackJackController.java

+        while (game.whoseBettingTurn().isPresent()) {
+            Player currentPlayer = game.whoseBettingTurn().get();


이 부분 지난 리뷰에도 남겼는데, 혹시 더 효율적인 방법은 없을까요? whoseBettingTurn 내부적으로 리스트를 순회하는 구조인데, 이렇게 두 번 호출 될 경우 문제는 없을까요? 성능 문제도, 동시성 문제도 있을 것 같은데 생각해보시면 학습에 도움이 될듯 합니다!

조회하는 시점과 실제 사용하게 되는 시점이 달라 문제가 발생할 수 있다는 점을 이해하게 되었습니다! 감사합니다!

우선 game.whoseBettingTurn() 을 한 번만 호출한 뒤, 비어있으면 break 를 호출하도록 변경하였습니다.

그 다음으로 내부적으로 Queue<String> 를 두어 아직 베팅을 하지 않은 사람만을 관리하도록 변경하였습니다.

echo724 · 2026-03-17T04:08:24Z

src/main/java/controller/BlackJackController.java

+        while (game.whoseBettingTurn().isPresent()) {
+            Player currentPlayer = game.whoseBettingTurn().get();
+            outputView.printBetAmountPrompt(currentPlayer.getName());
+            String betAmountValue = retry(inputView::readBetAmountValue);


retry 재활용 굳입니다! 잘 짜셨네요 ㅎㅎ

감사합니다 😁

echo724 · 2026-03-17T04:13:02Z

src/main/java/domain/BlackJackGame.java

+        Player target = multiPlayers.findNotBetPlayer()
+                .orElseThrow(() -> new IllegalStateException(ErrorMessage.NO_MORE_BETTABLE_PLAYER.getMessage()));
+        multiPlayers.executeBet(target, betAmountValue);


이 부분 어차피 multiPlayers에게 player를 찾아서 betAmountValue와 함께 다시 multiPlayers의 메서드를 호출하는 형태라면, 그냥 executeBet 메서드만 호출하고 메서드 내부에서 target을 찾으면 되지 않을까요? 외부로 값을 빼올 때는 빼와야만 하는 구체적인 이유가 있어야합니다. (호출자에게 반드시 필요한다던가, 뷰에서 필요로 한다던가) 안그러면 캡슐화도 깨지고, 응집도도 줄어들겠죠?

이 부분에 대한 것을 머리로는 이해하고 있었는데, 코드에서 찾기가 참 힘드네요😅 수정하겠습니다!!

echo724 · 2026-03-17T04:15:09Z

src/main/java/domain/BlackJackGame.java

    }

+    public void doBetProcess(String betAmountValue) {
+        Player target = multiPlayers.findNotBetPlayer()


근데 아래 커멘트보다 좀 중요하게 볼 부분은 이 부분인데요, 어떻게 특정 플레이어게 입력받은 betAmountValue가 여기서 찾은 target의 bet인지 어떻게 확신할 수 있죠? 만약 입력한 플레이어와 다른 플레이어가 여기서 찾아지면 어떻게 하죠?

일단 될 것이라는 생각을 하고 작성한 것 같습니다. 이미 whoseTurn 메서드에서 Player 가 노출된 만큼 Player 를 전달하는 방식으로 전달하는 방식으로 해결하겠습니다.
해당 부분에서 파라미터를 줄일 수 있어서 적용했는데, 문제 상황을 고려하지 못한 것 같습니다.

echo724 · 2026-03-17T04:20:25Z

src/main/java/view/InputViewImpl.java

+    public String readBetAmountValue() {
+        String line = sc.nextLine();
+        validateIsBlank(line);
+        return line;
+    }


이 부분에서 betAmount를 String Type으로 반환하고 해당 값을 Game에서부터 Player까지 넘긴 후에야 BetAmount에 대한 값 검증이 이루어지는데요, 만약 BetAmount 값이 잘못 되었을 경우 어떻게 될까요? 입력 단과 가까운 곳에서 값 검증이 이루어져야하지 않을까요? retry도 되어있는데 사실 검증이 입력단에서 이루어지면 betAmount 값이 잘못되도 유저는 리트라이가 가능하겠죠? 그래서 이 부분 리턴값을 BetAmount로 하는 것은 어떨까요? 문제가 있을까요?

이렇게 되는 경우 View 계층에서 Domain 계층을 알게 된느 문제가 생긴다고 판단했습니다! 절충안(?)으로 적절할 지 모르겠으나, 비즈니스 로직인 양수 이어야 함은 BetAmount 에서 검증하는 것으로 하고 InputView 에서는 정수 검증을 하는 것은 어떻게 생각하시는 지 궁금합니다. 우선 검증의 구분이라는 방향으로 잡고 수정해보겠습니다

echo724 · 2026-03-17T04:23:26Z

src/main/java/view/InputViewImpl.java

        validateIsBlank(input);
        validateHitOrStandValue(input);
-        return input;
+        return input.equals("y");


"y"가 중복해서 코드에 등장하는 군요? 혹시 이 부분 문자가 y가 아닌 yes로 변경되면 어떻게 될까요? 그러면 HIT_OR_STAND 값도 같이 바꿔줘야하죠?

기본적인 실수를 하였네요 😅 static 변수로의 도입 및 중복 제거 하겠습니다!!

echo724 · 2026-03-17T04:30:33Z

src/main/java/domain/state/GameState.java

 import java.util.List;
 import java.util.function.Supplier;

 public interface GameState {


이 부분 피드백 반영 잘해주셨네요! 확실히 상태의 수가 줄어드니 코드 읽기가 훨씬 편해졌습니다. 가독성이 좋다는 의미는 코드 유지 보수성도 좋아진다는 의미이기도 합니다. 코드를 짤때는 모든 컨텍스트가 머리에 있어서 이해가 쉽지만, 다른 프로젝트도 하고 이리저리 시간이 지나면 코드를 작성했던 컨텍스트는 별로 남지 않아서 결국에는 가독성이 중요해지더라구요.

리뷰어님의 이전 리뷰를 통해 저도 읽어보니 확실히 편해짐을 느낄 수 있어서 좋았던 것 같습니다!!

echo724 · 2026-03-17T04:51:28Z

src/main/java/domain/Dealer.java

    public Dealer addCard(Supplier<Card> cardSupplier) {
-        GameState newGameState = gameState.hit(cardSupplier);
-        return Dealer.from(newGameState);
+        if (gameState.getCardsSum() <= DEALER_CARD_SUM_MIN) {
+            GameState newGameState = gameState.hit(cardSupplier);
+            return Dealer.from(newGameState);
+        }
+        GameState stayGameState = gameState.stay();
+        return Dealer.from(stayGameState);
    }


지난 리뷰에서 놓치긴 했는데, Dealer 타입이 불변일 필요가 있을까요? 선호의 영역이기도 한데, 제가 어색하다고 생각하는 부분은 Game의 경우, 상태로 Dealer를 갖고 있어서, Dealer를 불변으로 하는 경우 this.dealer = newDealer 이부분을 반드시 해줘야하는데, 이 부분을 실수로 놓칠 경우가 종종 있다고 생각합니다 (실제로 그런 적도 몇 번 봤구요) 그래서 Dealer가 이리저리 여러 군데 사용되는 값 객체가 아니고 다른 객체의 상태로 관리되는 경우라면 가변을 고려해볼 것 같아요. 어떻게 생각하시나요?

이번 사이클 2의 토론 활동의 결과물로 불변 객체만 사용한다 라는 조건이 있어서 해당 방식으로 사용하였습니다.
이 과정에서 리뷰어님이 남겨주셨던 문제 역시 경험하여서 리뷰어님의 의견에 전적으로 동의합니다!! 이런 방식을 사용하니, 결국 중간에 불변 객체의 사용을 끊어내야 하는 부분이 존재하였고, 저는 이 부분에서 우선 BlackJackGame 에서 Dealer 불변 객체의 전파를 끊었고, MultiPlayers 에서 Players 의 상태를 흐름 제어 라는 이유로 끊었습니다. 그러나 다른 객체의 상태로 관리되는 경우 에도 불변 상태로 인하여 다른 객체도 불변이 되어야 하는 현상의 전파를 중간에 끊을 수 있는 좋은 조건이 될 것 같습니다!

변경을 위해 코드를 재검토해보니, Player와 Dealer의 공통 부모인 Participant에서 Hand를 관리하고 있습니다. 리뷰어님 말씀대로 Dealer를 상태 변화가 가능한 객체로 두더라도, 공통으로 사용하는 Hand는 여전히 불변 객체로 유지하는 것이 안전하다고 판단됩니다.

만약 여기서 Hand의 성격을 분리하게 되면 DealerHand와 같은 별도의 구현체가 필요해지는데, 이는 오히려 상속을 통한 구조적 이점을 잃게 되어 현재처럼 Participant가 불변 Hand를 보유하는 구조가 가장 적합하다고 생각합니다. 그렇기 때문에 Dealer도 우선은 불변 객체로 두는 것이 더 낫다고 생각합니다!

그렇군요! 설계에 대한 적절한 이유와 고민이 있다면, 그리고 그걸 말로 잘 설득할 수 있다면 저는 잘 설계 하셨다고 생각합니다. 특히 불변 객체를 선택하는데 있어서는 장단점과 상황 고려를 잘 해보셨으면 합니다!

echo724 · 2026-03-17T04:55:17Z

src/main/java/dto/PlayerResultDto.java

+    public static PlayerResultDto from(Player player, Dealer dealer) {
+        GameResult gameResult = player.calculateGameResult(dealer);
+        double earnMoney = gameResult.getAllocation() * player.getBetAmount();


DTO인데 게임 계산/결과 도출 로직이 이 부분에 있군요? 호출자 입장에서는 DTO 생성 로직인줄 알고 있을텐데, 의도치 않은 행위라고 생각하지 않을까요?

earnMoney 계산 하는 부분 calculateGameResult 메서드 내부에서 처리할 수 있지 않을까요?

echo724 · 2026-03-17T05:03:57Z

src/test/java/domain/BlackJackGameTest.java

    }

+    @Test
+    @DisplayName("베팅을 안한 사용자가 있으면 제공한다")


제가 놓친 것일 수 도 있는데 핵심인 베팅 계산 로직 테스트가 안보이네요? 해당 테스트는 반드시 필요해 보이는데 어떻게 생각하시나요?

저도 리뷰어님의 의견에 동의합니다.
이러한 계산 로직이 PlayerResultDto 에 존재하게 되어 테스트 과정이 누락되게 된 것 같습니다. dto 이기 때문에 테스트 할 필요 없다고 생각하였는데, dto에 비즈니스(?) 로직이 들어가게 되면서 전반적으로 누락된 것 같습니다

"y"가 하드코딩되어 있는 것을 제거. 추가적으로 HitOrStand와 중복된 값이어서 변수화 진행

dto에 들어가있는 결과 로직을 제거. 이후 공개가 불필요해진 calculateGameResult를 private 으로 전환

사용자가 양의 정수가 아닌 값을 입력하는 것을 입력 단계에서 파악할 수 있도록 변경하여 불필요한 리소스 낭비를 제거

Scanner 의 기본 기능을 사용하는 것으로 교체

- `Player` 를 전달함으로써 `Player` 부정합 가능성 배제. - `조회` 와 `명령`의 분리에 따른 동시성 문제가 발생할 수 있는 문제 해결 - `MultiPlayers`의 응집도가 낮은 부분 수정('BlackJackGame' 의 코드 제거 후 추가)

kdongsu5509 · 2026-03-17T10:18:24Z

리뷰어님이 주신 캡슐화의 개념을 분명히 알게 되었는데 이것을 제 코드에서 찾아내는 것이 힘드네요😅 항상 처음 작성할 때 잘 작성해야 함을 느낄 수 있었습니다 ㅋㅋ

stream 을 이용해서 찾는 방식으로 작성한 이유는 최초에는 List 타입으로 작성하여서 순서를 보장할 수 있었기 때문이었습니다. 이후 Map 으로 변경하는 과정에서 수정을 적절히 하였어야 하는데 돌아가게 만드는 것을 우선시 하다 보니 간단하게 변경해놓고 나중에 하자라고 한 부분을 놓치게 되었습니다.

이번 리팩토링 과정에서는 이전의 코멘트를 참고하여 순회를 하지 않고 Map 의 특성을 살리는 방식으로 변경했습니다. 또한 순서를 보장하기 위해 Queue<String> 에 Map 의 key로 사용되는 이름을 넣어 순서를 관리하도록 하였습니다.,

딜러의 합이 16이상일 때에도 카드 추가 로직이 작동하여 오류가 발생. 이를 해결하기 위해 isDealerFull 및 방어 로직 추가

echo724

안녕하세요 라티! 빠르게 피드백 반영해주셨네요! 이번에 제가 던졌던 질문에 고민도 해보시고 실제로 반영도 잘 해보신 것 같습니다! 설계 이유에 대해 고민하고 또 그걸 설명하는 과정 자체가 설계 역량을 기르고 협업하는데 있어서 많은 도움이 될거에요! 화이팅입니다!

이번에 커멘트로는 새로 추가하신 큐 부분에 달았는데요, 제가 저번에 문제를 제기했던 부분은 List 그 자체의 문제라기 보다는 같은 값을 찾는데 List를 두 번 순회하는 것이 문제가 될 수 있다는 것을 알려드리고 싶었습니다. 혹시나 이 부분 오해가 있었을까봐 다시 알려드렸어요! (아니라면 무시해주세요 ㅎㅎ) 그래서 기준에 Player를 순회하면서 각 플레이어에게 베팅이 가능한지, 플레이가 가능한지 물어보는 로직은 자연스러웠다고 생각합니다. 오히려 내부적으로 두 개의 큐를 추가로 관리함으로써 오는 비용이 더 클 것 같은데요, 이 부분 어떻게 생각하시나요?!

추가로 커멘트 단 부분도 확인해주시고 다시 요청 보내주세요~

echo724 · 2026-03-18T13:20:52Z

src/main/java/controller/BlackJackController.java

+        while (true) {
+            Optional<Player> player = game.whoseBettingTurn();
+            if (player.isEmpty()) {
+                break;
+            }
+            Player currentPlayer = player.get();


ㅎㅎ 피드백 반영 잘 하셨네요. 이렇게 하면 성능 이슈도, 동시성 이유도 없겠죠? 제가 좀 이 부분을 신경 쓴 부분은 현재 미션에서는 괜찮지만 나중에 미션 + 웹 서비스 환경에서는 프로그램이 멀티 스레드 환경에서 돌아가기 때문에 저런 부분은 쉽게 문제를 일으킬 수 있습니다. 멀티 스레드이다보니 테스트로도 안잡히는 경우가 있어서 저런 부분은 미리미리 고민 해보는 것이 좋습니다.

echo724 · 2026-03-18T13:31:59Z

src/main/java/domain/MultiPlayers.java

+    private final Queue<String> notBettingPlayers;
+    private final Queue<String> playablePlayers;


아 이렇게 큐로 상태를 관리하는 방향으로 바꼈군요.. 전에 플레이어에게 상태를 물어보는 방식으로 다음 플레이어를 찾는 방식이였던것 같은데 맞나요? 그 부분은 괜찮았는데 혹시 이렇게 큐로 관리하려는 구체적인 이유가 있을까요? 제 기준에서는 players가 이미 갖고 있는 정보를 또 관리하는 느낌이고 코드가 그 만큼 복잡해 진 것 같아요 ㅠ

echo724 · 2026-03-18T13:32:27Z

src/main/java/domain/MultiPlayers.java

+//    public Optional<Player> findNotBetPlayer() {
+//        return players.values().stream()
+//                .filter(player -> !player.isBet())
+//                .findFirst();
+//    }


안쓰는 코드는 꼭 지워주세요!

echo724 · 2026-03-18T13:35:49Z

src/main/java/view/InputViewImpl.java

+    public int readBetAmountValue() {
+        int betValue = sc.nextInt();
+        sc.nextLine();
+        return betValue;
+    }


아마도 BetAmount의 검증 위치를 줄이는 방식은 InputView에서 BetAmount를 생성해서 리턴하도록 하는 방식인데요, BetAmount의 경우 딱히 비지니스 로직을 처리하지 않고 있고, 또한 int값이 BetAmount로만 사용 되는 것 같은데 괜찮지 않을까요?

echo724 · 2026-03-18T13:45:24Z

src/main/java/domain/Dealer.java

    public Dealer addCard(Supplier<Card> cardSupplier) {
-        GameState newGameState = gameState.hit(cardSupplier);
-        return Dealer.from(newGameState);
+        if (gameState.getCardsSum() <= DEALER_CARD_SUM_MIN) {
+            GameState newGameState = gameState.hit(cardSupplier);
+            return Dealer.from(newGameState);
+        }
+        GameState stayGameState = gameState.stay();
+        return Dealer.from(stayGameState);
    }


그렇군요! 설계에 대한 적절한 이유와 고민이 있다면, 그리고 그걸 말로 잘 설득할 수 있다면 저는 잘 설계 하셨다고 생각합니다. 특히 불변 객체를 선택하는데 있어서는 장단점과 상황 고려를 잘 해보셨으면 합니다!

Yeji-Kim-Erica added 30 commits March 4, 2026 17:44

docs(README): add feature list

4d992f1

feat: add name input feature

37074a5

feat: add hit or stand input feature

070e5ba

feat: add game instruction output feature

0e85d53

docs : add domains features

f121afe

딜러와 플레이어를 추가하였고, 그들의 공통 조상인 참가자를 추가함. 이후 카드와 카드들을 관리하는 덱의 정의를 추가함.

test : add card contents test

e2d44c2

feat : add card and enum class for card

8582f6d

test : add deck creation test

11fb3ea

feat : add deck creation feature

644c62b

docs : check what I implemented

b80246c

test : add deck test

3a01775

- 신규 덱 제공 기능 테스트 - 카드 뽑기 기능 테스트 추가(정상, 실패)

feat : add DRAW_CARD_OUT_OF_RANGE

ab9bdbc

feat : add new deck features

8571797

- 새로운 덱 제공 기능 - 카드 선택 기능 을 추가하였습니다.

test: add participant deck creation and cards draw

b8d0a79

feat: add participant deck creation feature

6c65b8c

docs: check what I implemented

fac0ae3

refactor: seperate card creation responsibility

4772f2a

refactor: change ace default card score

debd9c0

feat: add card sum calculation excluding aces

5598c39

Ace 값 판정과 전체 카드 점수 합 기능은 상호 의존성을 띄기 때문에 Ace는 제외한 카드 점수 합을 계산하는 기능을 추가함.

feat: add ace score discrimination feature

12c235e

feat: add card score related feature

430f617

- add card score total sum feature - add bust discrimination feature

feat: add card addition feature

80d3469

feat: add conditional card drawing feature for dealer

200ce6c

refactor: change dealer constructor parameter name

b79ef33

딜러 생성 시 필요한 파라미터 Deck의 인스턴스 종류를 명시함

test: add dealer constructor test

160cc41

refactor : separate common logic between Dealer and Player

7721bca

공통 로직을 제거하기 위해 participant 추가

fix : fix typo

f6ed131

refactor: delete '\n'

638445c

feat: add Player class

30ef159

kdongsu5509 added 18 commits March 12, 2026 15:57

fix : delete unused logic

714eb80

fix : delete comment

fb55d62

docs : update docs to reflect newest proj contents

02458ce

fix : wrapping name to meet programming req

ef06868

fix : adopt state pattern to meet programming requirement

ddb8b64

- 모든 원시 값과 문자열을 포장한다라는 프로그래밍 요구 사항과 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다라는 요구사항을 충족하기 위해 상태 패턴 도입

fix : delete dependency of view at controller

c3d2d74

fix : import new GameStateDto for low cohension between BlackJackCont…

6e79c80

…roller and BlackJackGame

Merge with logic of cycle2

135e1eb

로컬 ì½코드를 병합하지 않고 진행한 수정으로 인한 충돌 해결

fix : clarify state per exact case

22cd46f

fix : change list to map

363e170

찾기 오버헤드를 줄이기 위해 변경. 현재는 n=5라는 조건 때문에 찾기 시 성능을 고려하지 않았으나, 이 또한 변경가능한 요구사항이기 때문에 변경하기로 결정함

fix : refactor game states

7f62ae0

복잡한 관계를 가진 game state 구조 정리

feat : add BetAmount Domain

ee58305

feat : add in-out logic for betting

e7c6a6b

feat : add bet Process

9c1a233

fix : change result printing logic

1f42451

test : add test of betting logic

d8c0824

fix : change io flow to meet requirements

5df0e69

docs : update readme

4fd489c

- 퍼블릭 인터페이스를 기준으로 다시 작성하여 객체별 책임을 한 눈에 볼 수 있도록 정리하였음

echo724 self-requested a review March 16, 2026 08:18

echo724 requested changes Mar 17, 2026

View reviewed changes

kdongsu5509 added 6 commits March 17, 2026 14:35

fix : extract "y" as static var

9f36f67

"y"가 하드코딩되어 있는 것을 제거. 추가적으로 HitOrStand와 중복된 값이어서 변수화 진행

fix : extract earn money calculate logic from PlayerResultDto

c11b31a

dto에 들어가있는 결과 로직을 제거. 이후 공개가 불필요해진 calculateGameResult를 private 으로 전환

fix : change return type of readBetAmountValue of InputView

50872cc

사용자가 양의 정수가 아닌 값을 입력하는 것을 입력 단계에서 파악할 수 있도록 변경하여 불필요한 리소스 낭비를 제거

fix : delete number validate logic

12be3fe

Scanner 의 기본 기능을 사용하는 것으로 교체

test : add missing assertion case

1f4f918

fix : fix dealer illegal method call

6f42a8b

딜러의 합이 16이상일 때에도 카드 추가 로직이 작동하여 오류가 발생. 이를 해결하기 위해 isDealerFull 및 방어 로직 추가

echo724 self-requested a review March 17, 2026 12:49

echo724 requested changes Mar 18, 2026

View reviewed changes

		while (game.whoseBettingTurn().isPresent()) {
		Player currentPlayer = game.whoseBettingTurn().get();

		private final Queue<String> notBettingPlayers;
		private final Queue<String> playablePlayers;

Conversation

kdongsu5509 commented Mar 14, 2026

체크 리스트

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

Uh oh!

echo724 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!

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!

Choose a reason for hiding this comment

Uh oh!

kdongsu5509 Mar 17, 2026 • 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!

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!

kdongsu5509 commented Mar 17, 2026

Uh oh!

echo724 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

kdongsu5509 Mar 17, 2026 •

edited

Loading