[🚀 사이클2 - 미션 (블랙잭 게임 실행)] 아티 미션 제출합니다. by ParkJiYeoung8297 · Pull Request #1113 · woowacourse/java-blackjack

ParkJiYeoung8297 · 2026-03-13T18:10:21Z

사이클 2

기능

배팅 금액 입출력 기능 구현
전체 배팅 금액 구하는 기능 추가
최종 수익 출력하는 기능 구현
배팅 금액 예외 시 재입력 기능 추가
플레이어 burst면 상금 잃는 기능 추가
딜러 수익 계산 금액 기능 구현

사이클1 피드백 반영

Player의 필드 List를 일급컬렉션 Cards로 변경
기존 Cards는 전체 카드를 의미해서 Player에서 사용 못했습니다.
이번 수정 과정에서 전체 카드는 Deck이라는 도메인을 추가하고, Cards는 Player가 들고있는 카드 뭉치로 사용했습니다.
Dealer와 Player의 상속 관계를 제거
Dealer와 Player의 상속 관계로 인해 Dealer가 몰라도 되는 Player의 행동을 상속받고 있었습니다.
이를 해결하고자 Player와 겹치는 행동은 Player에서 처리하고, 딜러의 규칙은 곧 게임의 규칙이기에 Game에서 처리하도록 변경했습니다.
도메인에서 DTO 직접 생성했던 것을 Service에게 책임 이동
Controller에서 출력하는 책임을 OutputView로 이동
하드 코딩 상수화
사용하지 않는 import 정리

To 리뷰어

1.Dealer - Player
딜러의 행동(ex. 자신이 가진 카드의 합 구하기)은 Player와 중복이고,
딜러의 규칙(ex. 16이하이면 카드를 추가로 받는다.)은 게임의 규칙이기에 Game에서 처리할 수 있다고 생각했습니다.
객체에서의 책임은 현실세계와 차이가 있어서, 꼭 딜러가 하는 행동이라고 Dealer에 있어야하는 것이 아니라 응집도를 고려해 다른 곳에 위치할 수 있다고 생각하는데, 이런 구조로 구현하는 것에 대해 피드백 받고 싶습니다.

(이런 구조 → 코드 중복을 줄이기 위해 Dealer 객체를 없애고, 관련 행동과 규칙을 적절한 클래스에 둔다)

Domain
지금 변경한 도메인 구조가 잘 짜여진 것인지 피드백 받고 싶습니다. 어찌보면 Game이 aggregate root와 같다고 보이는데, 이런 구조가 적절할까요?
테스트 수정
도메인이 대거 수정되니, 테스트 코드도 다시 수정해야하는 상황이 발생했습니다.
본 코드랑 테스트 코드의 의존성이 큰거 같은데, 테스트 코드가 변경에 유연하게끔 작성하는 방법이 있을까요?
코드 수정
이미 사용중인 서비스에서는 이와 같이 도메인을 대거 수정하는 과정이 어려울거 같은데, 대거 수정이 필요할 경우 어떻게 해야하는지 궁금합니다.
(하나를 고치면 여러개가 에러나는 상황이다 보니, 저는 전부 주석해놓고 처음부터 하나씩 주석을 해제하고 문제해결하는 방식으로 리팩토링했습니다.)

*피드백을 반영하는 과정에서 도메인 재구성이 필요하다고 생각했습니다. 그래서 리팩토링 과정에서 많은 파일이 바뀌었습니다.🥲
*깃을 제대로 못 만져서, 사이클 1의 커밋 내용도 전부 뜨는 것 같습니다. (보기 힘드실거 같아서 죄송합니다..)
*사이클 1에서 달아주신 리뷰 답글은 14일(토)내로 작성해두겠습니다!

사이클 1의 PR

링크: #956

미션 중 기록

1. 기능 추가로 인해 수정한 위치 개수

기능을 추가하는 과정에서 현재 구조로 확장하기에 어려움이 있었다.
그래서 대부분의 비즈니스 로직을 도메인 안으로 넣어서, 변경에 유연하도록 도메인을 재구성하였다.

1)BlackjackResult삭제
원래는 BlackjackResult에서 승패와 같은 게임의 기록을 저장했는데,
배팅 상금이라는 결과가 하나 더 추가 되면서, 출력 결과(response)를 도메인으로 갖는 것은 확장성이 안좋다고 생각했다.
그래서 BlackjackResult를 없애고, Game이라는 도메인에서 그때그떄 원하는 결과를 반환할 수 있도록 메서드만 구현하였다.

2)Deck 도메인 추가, Cards 일급 컬렉션 수정
Cards라는 일급 컬렉션을 카드 전체(52장)를 타깃으로 사용했다 보니, Player가 갖는 카드 더미는 Cards를 사용하지 못했다.
전체 카드는 랜덤 생성, 카드 추출 기능에 대한 책임만 가지기 때문에 플레이어가 가지는 카드 뭉치 Cards와 따로 분리하는 것이 낫다고 생각했다.
그래서 Player가 소유한 카드 뭉치를 Cards라는 일급 컬렉션으로 사용하기 위해, 전체 카드를 나타내는 Deck이라는 도메인을 추가하였다.
CardGenerator를 파라미터로 받아서 전체 카드 생성에 관해서 Deck에서 처리하도록 하였다.
카드 생성을 저번에 인터페이스로 해서 분리하니 이부분에 대한 수정은 편리했다.
(CardGenerator를 파라미터로 받아서 메서드로만 호출하면 되니까.)

4)Game 도메인 추가, Dealer 도메인 삭제
Game에 대한 비즈니스 로직이나 규칙들이 Player, Dealer, Cards 등에 흩어져있어 테스트 코드 작성에 어려움이 있었다.
따라서, 블랙잭 게임 규칙에 대한 메서드를 모아두기 위해 Game이라는 도메인을 추가하였다.

Game을 추가하고 나니 Dealer의 필드는 Player와 겹치고, Dealer의 규칙은 Game에서 수행할 수 있을 것으로 보았다.
(16이하이면 카드를 더 받는다는 Dealer의 규칙은 게임의 규칙이라고 볼 수도 있기 때문이다.)
Game과 Dealer는 항상 1대 1로 존재하기 떄문에, 객체 생성-소멸 주기가 같다고 판단하여 관련 로직을 Game에 두었다.

추가로 Dealer는 게임을 만들 때 외부에서 주입해주는 방식으로 했다. 그래야 GameTest에서 Dealer의 카드를 조작해줄 수 있기 때문이다.
테스트를 작성하며 의존성을 줄이는 방향으로 개발을 하게 되었다.

2. 사이클1 때보다 수정 범위가 줄었는가/늘었는가

사이클 1에서 단편적인 결과 출력에만 집중해서 도메인을 설계해서 그런지, 기능 추가를 위해 코드 변경이 막막하고 어려웠다.
그래서 도메인을 재구성하였기 때문에, 사이클1 때보다 수정 범위가 훨씬 컸다.
변경된 구조에서는 기능 추가 시 Game에 코드를 추가하면 되기 때문에, 코드 변경이 적을 것으로 예상된다.

3. 규칙 적용으로 변경한 코드 1곳

(If-Then) 하드코딩된 값이 보인다면, → 상수화한다.
도메인으로 로직을 이동하면서, 상수도 적절한 도메인으로 이동해 응집성 있게 수정하였다.

(If-Then) 같은 객체를 다루는 클래스여도 목적이 다르면, → 클래스를 분리한다. (e.g. Cards -> Deck, Hand)
Cards를 Cards(Player 소유 카드), Deck(전체카드)으로 나누어서 리팩토링하였다.

4. 테스트가 설계를 도운 순간 1회

게임 규칙에 대한 테스트를 진행하려고 했는데,
이런 규칙이 Player, Dealer, Cards 등 여러 도메인에 걸쳐서 존재하는 것이 불편했다.
테스트 구현을 통해 도메인의 책임 분리에 대한 재구성 필요 신호를 포착할 수 있어서 설계에 도움이 되었다.

체크 리스트

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

사이클 2의 수정사항 (260316)

단일 반환 람다식에서 중괄호 및 return 제거
OutputView에서 도메인 정책 제거 (리뷰어 확인 필요!)
Card에서 Ace 판단 여부 메서드 수정(캡슐화) - get 하지 않고, isAce로 boolean을 return
기능 책입 분리 (게임 판단 책임, 돈 계산 책임)
테스트만을 위한 메서드 삭제
테스트 유틸을 이용해 중복 제거 (for 유연한 테스트를 위함)

사이클 2의 수정사항2 (260318)

allMatch에 빈 리스트가 항상 true를 반환하는 문제 수정 (Players)
메서드에서 사용안하는 파라미터 제거 (Game)
자바 네이밍 컨벤션 - 카멜 케이스 적용 (OutputView)
외부에서 betMoney로 값 변경할 수 있는 문제 수정 (Player)
배팅 점수 계산 책임 분리를 위해 Betting 도메인 생성(Player의 책임 분리)
불변 컬렉션 방어적 복사 적용
래퍼 타입에서 불필요하게 원시값으로 변경하는 문제 수정 (OutputView)
Dealer 도메인 생성 및 책임 분리

Player의 책임을 줄이기 위해 Betting과 Dealer 도메인을 생성했습니다.
돈 계산에 대한 책임을 Betting에게, 딜러에 대한 책임을 Dealer에게 부여해, 책임을 분리했습니다.

jurlring

아티 안녕하세요 🐰
질문 주신 부분에 대한 생각들과 코멘트 몇가지 남겨두었어요.
시간 괜찮으실 때 확인해주세요~!
즐거운 주말 되세요~~

src/main/java/domain/Game.java

src/main/java/controller/BlackjackController.java

src/test/java/domain/GameTest.java

src/main/java/validator/Validator.java

src/test/java/testutil/PlayerTestUtil.java

src/main/java/domain/Players.java

jurlring · 2026-03-14T13:47:47Z

src/main/java/domain/Player.java

+    public void betMoney(int money) {
+        bettingScore = money;


플레이어 생성 시점에 bettingScore를 초기화 하는 방법은 없을까요? 그럼 장점은 어떤게 있을까요?

현재 bettingScore는 생성 시점에 0으로 초기화하고 있습니다. 🙂

플레이어 생성 시점에 bettingScore를 초기화 하는 방법은 없을까요? 그럼 장점은 어떤게 있을까요?

생성할 때, 초기화를 해준다면 객체가 필요한 값을 가지고 있게 되어 객체 안정성이 높아질 것 같습니다!

다만 현재 입력 받는 구조에서는 controller에서 List<String> names를 돌려서 betting score를 받고,
Map으로 {이름 : betting score}를 저장해서 도메인 파라미터로 넘겨줘야 하기 때문에,
먼저 Player를 생성하고, 이후 betScore로 세팅해주는 방식을 생각했습니다.

betting score는 플레이어한테 중요한 값인데, betMoney로 외부에 수정이 가능한 메세지를 노출하고 있다고 생각했어요.

controller에서 List names를 돌려서 betting score를 받으면 어떤 문제가 있어요?

엇 List<String> name을 for문 돌아서 배팅금액을 입력 받고, Map으로 넘겨줘야한다고 생각했는데,
createPlayer를 만들어서 배팅금액 입력받을 때마다 Player를 생성해줘도 될 것 같습니다.
(createPlayers()에서 Player도 생성하고, Players도 생성하는 두 가지 책임을 가지고 있었네요..😅)

Player에서 Betting 필드를 final로 두고 생성할 당시에 값을 넣어주는 방식으로 수정했습니다!
배팅 금액 관련해서 수정할 수 없도록 했고, Betting 도메인 내부에서 최종 수익을 계산하는 책임을 부여했습니다.

public class Player { private final Cards cards; private final String name; private final Betting betting; public Player(String name, Betting betting) { this.name = name; this.betting = betting; this.cards = new Cards(); }

jurlring · 2026-03-14T13:55:45Z

src/main/java/domain/Player.java

+    public MatchCase calculateMatchCase(int dealerTotal) {
+        if (cards.getFinalScore() > dealerTotal) {
+            return MatchCase.WIN;
+        }
+        if (cards.getFinalScore() == dealerTotal) {
+            return MatchCase.DRAW;
+        }
+        if (cards.getFinalScore() < dealerTotal) {
+            return MatchCase.LOSE;
+        }
+        throw new IllegalArgumentException("[ERROR] 일치하는 enum이 없습니다.");
    }

-    private int calculateAceScore() {
-        if (!isAceExist() || calculateScore() > 11) {
-            return ACE_ADDITION_NONE_SCORE;
+    public void calculateMoney(MatchCase matchCase, boolean isDealerBlackjack) {
+        if (cards.isBlackjack() && !isDealerBlackjack) {
+            bettingScore = (int) ((int) bettingScore * Game.BLACKJACK_BONUS);
+            return;
+        }
+        if (matchCase.equals(MatchCase.LOSE)) {
+            loseMoney();
+            return;
+        }
+
+        if (matchCase.equals(MatchCase.WIN)) {
+            return;
        }


플레이어가 너무 과도한 책임을 가진게 아닐까요~?
단일책임원칙을 지키고 있지 않아보여요.

메서드를 이용해서 분리해, 하나의 책임을 지도록 수정했습니다.

판단 로직만 남겨두고 돈 계산하는 메서드를 분리했는데,
이와 같이 수정하면 책임 분리가 되었다고 할 수 있을까요? (승부 판단 책임, 돈 계산 책임)

public void calculateMoney(MatchCase matchCase, boolean isDealerBlackjack) { if (cards.isBlackjack() && !isDealerBlackjack) { gainMoney(); return; } if (matchCase.equals(MatchCase.LOSE)) { loseMoney(); return; } if (matchCase.equals(MatchCase.WIN)) { return; } resetMoneyZero(); } private void resetMoneyZero() { bettingScore = 0; } private void gainMoney() { bettingScore = (int) ((int) bettingScore * Game.BLACKJACK_BONUS); } private void loseMoney() { int minusScore = bettingScore * 2; bettingScore -= minusScore; }

메서드를 분리한 것과 책임이 분리되었다는 다른 것 같아요!
말씀주신대로라면 승부 판단 책임은 플레이어가 가지는데, 기존에도 플레이어가 가진 책임이 있지요..! 플레이어가 카드도 들고있고, 베팅금액도 들고 있고, 승패도 판단하는데 단일 책임원칙을 지켰다고 볼 수 있을까요?!
카드를 가진 참가자와 베팅을 하는 참가자를 나누면 어때요?

단일 책임 원칙을 메서드 단위에서만 신경썼는데, 도메인 단위에서도 고려해야겠네요. 🙂
Dealer, Betting 도메인을 추가로 생성해서 책임을 분리해봤습니다!

카드만 가진 참가자 : Dealer
베팅 하는 참가자 : Player
베팅금액 계산 : Betting

단일 책임 원칙은 로버트 마틴(Robert C. Martin)이 제안한 SOLID 원칙중에 하나로 객체 지향 프로그래밍 및 설계에서 유지보수가 쉽고, 확장 가능하며, 견고한 코드를 만들기 위한 5가지 핵심 원칙중 하나인데요!
그렇다보니 메서드 단위가 아니라 객체 단위로 지켜야합니다.
지금 나눠주신건 Betting의 원시값을 포장해주신 것 같고, 아직 플레이어가 카드도 들고있고, 베팅금액을 계산하고, 승패도 판단하고 있는 것으로 보이는데요.
승패를 MatchCase가 판단하면 안되나요?
베팅금액을 계산을 꼭 플레이어가 해야할까요?

단일 책임 원칙을 적용하기 전에 단일 책임 원칙이 뭔지 단일 책임 원칙을 지키면 어떤 장점이 있을지 고민해보시면 좋을 것 같습니다! :)

jurlring · 2026-03-14T14:08:51Z

src/main/java/view/OutputView.java

+import domain.dto.MatchResultDto;
+import domain.enums.MatchCase;

 public final class OutputView {


Dealer를 플레이어로 생성하게 변경되어, view단에서 도메인 정책에 대한 구현이 들어가는 것 같아요 😿

최대한 도메인 규칙 없이 dto 값만 꺼내와서 사용할 수 있게끔 아래의 코드를 수정했습니다.
(before: 플레이어의 총합이 딜러 수익이라는 점을 앎, after: dto에서 단순히 값을 꺼내서 출력함)

도메인 정책에 대한 구현이 view에 있다는 것이 잘 이해가 안되는데, 이런 점을 말씀하신게 맞을까요?
혹시 아니라면, 조금만 더 구체적으로 설명해주실 수 있을까요?🥲

<추가 질문>
추가로 OutputView에서 도메인을 직접 get하는건 지양해야한다고 보지만,
enum은 상수의 집합이기 때문에 값을 직접 get하는 것은 괜찮다고 생각하는데
이 부분에 대해서 주디는 어떻게 생각하시는지 궁금합니다!

네 수정해주신 부분이 맞습니다~! 도메인 정책에 대한 구현이 view에 있으면 도메인 정책이 응집되어 있지 않기 때문에 view가 바뀔 때마다 고려해야하고, 놓치게되면 장애로 이루어지겠죠 😱 그렇다면 MVC구조로 설계하신 의미도 없구요!

enum은 상수의 집합이기 때문에 값을 직접 get하는 것은 괜찮다라고 생각하셨군요~!
좋은 접근이지만 displayCardContent에서 card.getCardRank().getName() + card.getCardShape().getName() 이렇게 Card의 내부 구조를 OutputView가 직접 조합하고 있어요! 만약 카드 표현 방식이 바뀌면 OutputView를 수정해야 하는데, 이건 View의 책임일까요?!

출력에 대한 것은 View의 책임이라고 생각합니다!🙂

출력과 같은 경우에는 사용자의 요구사항에 따라 빈번하게 바뀔 수 있는 값이라,
이를 최대한 presentation layer 내에서 수행하는 것이 좋을 것 같습니다.
(출력 요구사항 변경으로 인해 도메인이나 서비스 코드가 바뀌는 구조는 위험하다고 생각했습니다.)

또한 추후 입력이 늘어날 때(콘솔 출력, 파일 출력), 아래의 예시와 같이 출력 형식에 관련된 것을 각각의 View에서 수행하는 것이 책임 분리에 좋을 것 같습니다.

1) ConsoleOutputView :

System.out.printf("%s %s",card.getCardRank().getName(), card.getCardShape().getName());

출력 : 8 스페이드

2) FileOutputView :

System.out.printf("카드 랭크 : %s, 카드 모양 : %s",card.getCardRank().getName(), card.getCardShape().getName());

출력 : 카드 랭크 : 스페이드, 카드 모양 : 8

실제로 출력 형식에 맞추어 조합하는 책임을 주디는 어디에 두시는지 궁금합니다! 🙋🏻‍♀️

말씀해주신 것처럼 출력은 요구사항에 따라 자주 변경될 수 있는 부분이라면, 출력 형식에 대한 책임을 View에서 담당하도록 두는 방향에는 공감가네요! 👍

다만, 디미터의 법칙 관점에서는 card.getCardRank().getName()처럼 객체를 여러 번 탐색하는 구조는 지양하는 것이 좋다고 생각합니다.
이런 구조는 내부 구현에 대한 의존도가 높아져서, 예를 들어 Card 내부 구조가 변경되면 (CardRank가 사라지거나 구조가 바뀌는 등) 이를 사용하는 모든 코드가 함께 영향을 받게 되는 문제가 있겠지요!
또한 객체에게 메시지를 보내기보다는 데이터를 꺼내 사용하는 방식이 되어, 객체지향적인 책임 분리가 흐려질 수 있다고 생각합니다.
그래서 가능하다면 Card가 스스로 필요한 값을 표현할 수 있는 메시지를 제공해주는 방향도 고려해볼 수 있을 것 같아요~!

src/main/java/domain/Deck.java

- 기능 책임 분리 - 람다에서 불필요한 괄호 제거 - 불필요한 주석 제거

ParkJiYeoung8297 · 2026-03-16T11:56:11Z

주디. 코드 리뷰 감사합니다. ☺️
피드백 주신 것을 바탕으로 아래의 사항들을 수정했습니다!

사이클 2의 수정사항 (260316)

단일 반환 람다식에서 중괄호 및 return 제거
OutputView에서 도메인 정책 제거 (리뷰어 확인 필요!)
Card에서 Ace 판단 여부 메서드 수정(캡슐화) - get 하지 않고, isAce로 boolean을 return
기능 책입 분리 (게임 판단 책임, 돈 계산 책임)
테스트만을 위한 메서드 삭제
테스트 유틸을 이용해 중복 제거 (for 유연한 테스트를 위함)

jurlring

아티 안녕하세요!
문의에 대한 답변과 코멘트 몇가지 남겨두었어요 :)
시간 괜찮으실 때 확인해주세요!

jurlring · 2026-03-16T23:37:50Z

src/main/java/domain/Cards.java

+    public List<Card> getCards() {
+        return cards;
+    }
 }


불변 컬렉션에 대해서 학습해보면 좋을 것 같아요!
https://tecoble.techcourse.co.kr/post/2021-04-26-defensive-copy-vs-unmodifiable/

src/main/java/view/OutputView.java

jurlring · 2026-03-17T10:40:37Z

src/main/java/domain/Player.java

+    public void betMoney(int money) {
+        bettingScore = money;


betting score는 플레이어한테 중요한 값인데, betMoney로 외부에 수정이 가능한 메세지를 노출하고 있다고 생각했어요.

controller에서 List names를 돌려서 betting score를 받으면 어떤 문제가 있어요?

jurlring · 2026-03-17T10:45:47Z

src/main/java/view/OutputView.java

+import domain.dto.MatchResultDto;
+import domain.enums.MatchCase;

 public final class OutputView {


네 수정해주신 부분이 맞습니다~! 도메인 정책에 대한 구현이 view에 있으면 도메인 정책이 응집되어 있지 않기 때문에 view가 바뀔 때마다 고려해야하고, 놓치게되면 장애로 이루어지겠죠 😱 그렇다면 MVC구조로 설계하신 의미도 없구요!

enum은 상수의 집합이기 때문에 값을 직접 get하는 것은 괜찮다라고 생각하셨군요~!
좋은 접근이지만 displayCardContent에서 card.getCardRank().getName() + card.getCardShape().getName() 이렇게 Card의 내부 구조를 OutputView가 직접 조합하고 있어요! 만약 카드 표현 방식이 바뀌면 OutputView를 수정해야 하는데, 이건 View의 책임일까요?!

src/test/java/testutil/PlayerTestUtil.java

src/main/java/view/OutputView.java

jurlring · 2026-03-17T11:06:19Z

src/main/java/domain/Player.java

+    public MatchCase calculateMatchCase(int dealerTotal) {
+        if (cards.getFinalScore() > dealerTotal) {
+            return MatchCase.WIN;
+        }
+        if (cards.getFinalScore() == dealerTotal) {
+            return MatchCase.DRAW;
+        }
+        if (cards.getFinalScore() < dealerTotal) {
+            return MatchCase.LOSE;
+        }
+        throw new IllegalArgumentException("[ERROR] 일치하는 enum이 없습니다.");
    }

-    private int calculateAceScore() {
-        if (!isAceExist() || calculateScore() > 11) {
-            return ACE_ADDITION_NONE_SCORE;
+    public void calculateMoney(MatchCase matchCase, boolean isDealerBlackjack) {
+        if (cards.isBlackjack() && !isDealerBlackjack) {
+            bettingScore = (int) ((int) bettingScore * Game.BLACKJACK_BONUS);
+            return;
+        }
+        if (matchCase.equals(MatchCase.LOSE)) {
+            loseMoney();
+            return;
+        }
+
+        if (matchCase.equals(MatchCase.WIN)) {
+            return;
        }


메서드를 분리한 것과 책임이 분리되었다는 다른 것 같아요!
말씀주신대로라면 승부 판단 책임은 플레이어가 가지는데, 기존에도 플레이어가 가진 책임이 있지요..! 플레이어가 카드도 들고있고, 베팅금액도 들고 있고, 승패도 판단하는데 단일 책임원칙을 지켰다고 볼 수 있을까요?!
카드를 가진 참가자와 베팅을 하는 참가자를 나누면 어때요?

src/main/java/domain/Game.java

src/main/java/domain/Players.java

src/main/java/validator/Validator.java

- 안쓰는 파라미터 제거

- Player 생성 시 bettingScore 초기화

ParkJiYeoung8297 · 2026-03-17T23:25:55Z

사이클 2의 수정사항2 (260318)

allMatch에 빈 리스트가 항상 true를 반환하는 문제 수정 (Players)
메서드에서 사용안하는 파라미터 제거 (Game)
자바 네이밍 컨벤션 - 카멜 케이스 적용 (OutputView)
외부에서 betMoney로 값 변경할 수 있는 문제 수정 (Player)
배팅 점수 계산 책임 분리를 위해 Betting 도메인 생성(Player의 책임 분리)
불변 컬렉션 방어적 복사 적용
래퍼 타입에서 불필요하게 원시값으로 변경하는 문제 수정 (OutputView)
Dealer 도메인 생성 및 책임 분리

Player의 책임을 줄이기 위해 Betting과 Dealer 도메인을 생성했습니다.
돈 계산에 대한 책임을 Betting에게, 딜러에 대한 책임을 Dealer에게 부여해, 책임을 분리했습니다.

jurlring

아티 안녕하세요!
코멘트 몇가지 남겼는데 시간 괜찮으실 때 확인부탁드려요 :)

jurlring · 2026-03-18T12:20:39Z

src/main/java/domain/Dealer.java

+        cards.addCard(card);
+    }
+
+    public void addInitializedCard(Deck deck) {


딜러와 플레이어의 행위들이 너무 많이 중복되는 것 같아요! 중복 코드를 없애는건 어떨까요?

jurlring · 2026-03-18T12:21:33Z

src/main/java/domain/Dealer.java

+        return cards.getFinalScore() > Game.BLACKJACK_VALUE;
+    }
+
+    public boolean isDealerBlackjack() {


딜러 객체가 isDealerBlackjack이라는 행위를 하는건 중복일 수 있을 것 같아요!
dealer.isDealerBlackjack 딜러가 두번 들어가는데 필요할까요?!

jurlring · 2026-03-18T12:34:11Z

src/main/java/domain/Player.java

+    public MatchCase calculateMatchCase(int dealerTotal) {
+        if (cards.getFinalScore() > dealerTotal) {
+            return MatchCase.WIN;
+        }
+        if (cards.getFinalScore() == dealerTotal) {
+            return MatchCase.DRAW;
+        }
+        if (cards.getFinalScore() < dealerTotal) {
+            return MatchCase.LOSE;
+        }
+        throw new IllegalArgumentException("[ERROR] 일치하는 enum이 없습니다.");
    }

-    private int calculateAceScore() {
-        if (!isAceExist() || calculateScore() > 11) {
-            return ACE_ADDITION_NONE_SCORE;
+    public void calculateMoney(MatchCase matchCase, boolean isDealerBlackjack) {
+        if (cards.isBlackjack() && !isDealerBlackjack) {
+            bettingScore = (int) ((int) bettingScore * Game.BLACKJACK_BONUS);
+            return;
+        }
+        if (matchCase.equals(MatchCase.LOSE)) {
+            loseMoney();
+            return;
+        }
+
+        if (matchCase.equals(MatchCase.WIN)) {
+            return;
        }


단일 책임 원칙은 로버트 마틴(Robert C. Martin)이 제안한 SOLID 원칙중에 하나로 객체 지향 프로그래밍 및 설계에서 유지보수가 쉽고, 확장 가능하며, 견고한 코드를 만들기 위한 5가지 핵심 원칙중 하나인데요!
그렇다보니 메서드 단위가 아니라 객체 단위로 지켜야합니다.
지금 나눠주신건 Betting의 원시값을 포장해주신 것 같고, 아직 플레이어가 카드도 들고있고, 베팅금액을 계산하고, 승패도 판단하고 있는 것으로 보이는데요.
승패를 MatchCase가 판단하면 안되나요?
베팅금액을 계산을 꼭 플레이어가 해야할까요?

단일 책임 원칙을 적용하기 전에 단일 책임 원칙이 뭔지 단일 책임 원칙을 지키면 어떤 장점이 있을지 고민해보시면 좋을 것 같습니다! :)

src/main/java/domain/Players.java

jurlring · 2026-03-18T13:39:54Z

src/main/java/view/OutputView.java

+import domain.dto.MatchResultDto;
+import domain.enums.MatchCase;

 public final class OutputView {


말씀해주신 것처럼 출력은 요구사항에 따라 자주 변경될 수 있는 부분이라면, 출력 형식에 대한 책임을 View에서 담당하도록 두는 방향에는 공감가네요! 👍

다만, 디미터의 법칙 관점에서는 card.getCardRank().getName()처럼 객체를 여러 번 탐색하는 구조는 지양하는 것이 좋다고 생각합니다.
이런 구조는 내부 구현에 대한 의존도가 높아져서, 예를 들어 Card 내부 구조가 변경되면 (CardRank가 사라지거나 구조가 바뀌는 등) 이를 사용하는 모든 코드가 함께 영향을 받게 되는 문제가 있겠지요!
또한 객체에게 메시지를 보내기보다는 데이터를 꺼내 사용하는 방식이 되어, 객체지향적인 책임 분리가 흐려질 수 있다고 생각합니다.
그래서 가능하다면 Card가 스스로 필요한 값을 표현할 수 있는 메시지를 제공해주는 방향도 고려해볼 수 있을 것 같아요~!

ParkJiYeoung8297 and others added 30 commits March 5, 2026 10:32

feat: 사전학습 Ace 처리 기능 추가

e791dae

feat(domain): 카드 관련 enum 도메인 추가

23b6f2f

feat: Dealer, Player 도메인 템플릿 생성

c842532

feat(Controller): 플레이어 이름 입력 기능 추가

0827d8f

test: Controller 테스트 기본 세팅 추가

cfa77d3

docs: 참가자 입력 기능 명세

390b538

feat: 추가 카드 여부 입력 구현

ee81344

docs: Readme 기능 추가

b018db5

feat(sauter001): 플레이어에게 카드 2 장씩 배분

d25051c

feat(sauter001): 딜러 카드 배분

7b596d6

feat: 참가자 이름과 카드 개수, 카드 출력

015b0b9

docs: Readme update

4f24260

feat(sauter001): 딜러가 추가 카드를 받아야 할 때 처리

12be3c5

refactor: Controller에서 초기화 기능 Servcie 코드로 분리

f7b4483

refactor: 카드 사이즈 메서드 추가

b691c7a

test(service): 카드 생성 및 사이즈 검증 테스트 추가

94cf2f9

docs: Readme update

9c1765e

feat(domain): 카드 합계 기능 구현

c954cf6

test(domain) : 합계 기능 구현 정상 테스트 추가

e8b4052

test: 에이스 고려한 카드 점수 합계 테스트

a8fa42d

feat(sauter001): Ace 1/11 규칙 고려해 카드 합계 계산

ab9e634

feat: 버스트 판단 여부 기능 구현

f0c3269

test(domain): 버스트 판단 여부 테스트 추가

61d9f36

docs: Readme update

14a6ab1

fix: 에이스 11점 적용 안되는 문제 해결

1d2f59d

refactor: 딜러가 카드를 뽑는 메소드명 명확하게 변경

b680504

feat: 카드 결과 판단 기능 구현

f115217

docs: Readme update

cdaa334

feat(sauter001): 블랙잭 승부 결과 클래스 생성

6f32ee7

feat: 블랙잭 승부 계산 (burst 고려)

66ade47

ParkJiYeoung8297 added 10 commits March 13, 2026 21:25

fix&refactor: 배팅 상금 구하는 로직 수정 및 리팩토링

d94b0cc

chore: 메서드 순서 및 공백 정리

980f6bb

fix: dealer를 Game외부에서 주입하도록 수정

de30afc

test: 리팩토링 대상 테스트 수정

5d425df

fix: 블랙잭 여부 판단 오류 수정

18ef51f

fix: 추가 카드 받은 후 출력하는 부분 수정

b1d09ff

refactor: 하드 코딩 상수화

3907f88

test: 테스트 코드 수정

dacc0d0

docs: Readme update

be40df3

docs: Readme update

081470b

jurlring requested changes Mar 14, 2026

View reviewed changes

ParkJiYeoung8297 added 6 commits March 16, 2026 17:03

fix:

2390b53

- 기능 책임 분리 - 람다에서 불필요한 괄호 제거 - 불필요한 주석 제거

fix: Card에서 Ace 판단 여부 메서드 수정(캡슐화)

c002e16

fix: 테스트만을 위한 메서드 삭제

9c06d9c

fix: 테스트 유틸을 이용해 중복 코드 제거 및 딜러 테스트 추가

c29cc27

chore: 자바 컨벤션에 따른 공백 정리

e4d96e5

docs: Readme update

1d1f392

jurlring requested changes Mar 17, 2026

View reviewed changes

ParkJiYeoung8297 added 9 commits March 18, 2026 00:35

fix: allMatch에서 빈 리스트일때 무조건 true 되는 문제 수정

efbfe92

- 안쓰는 파라미터 제거

fix: PlayerTest에서 allBurst 오류 수정과 관련된 테스트 케이스 추가

d6c0020

feat: 배팅 점수 계산 책임 분리를 위해 Betting 도메인 생성

07206c7

test: Player 코드 변경으로 인해 테스트 케이스 수정

bbc7a89

- Player 생성 시 bettingScore 초기화

fix: 불변 컬렉션 방어적 복사 적용

741c2cd

feat: 딜러 도메인 생성 및 책임 분리

9cd5f0c

test: 딜러 도메인 생성으로 인한 테스트 케이스 수정

45b04d7

chore: 자바 컨벤션에 따라 코드 정리

3850bdf

docs: Readme update

ed04e8f

jurlring requested changes Mar 18, 2026

View reviewed changes

Conversation

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

Uh oh!

사이클 2

기능

사이클1 피드백 반영

To 리뷰어

사이클 1의 PR

미션 중 기록

1. 기능 추가로 인해 수정한 위치 개수

2. 사이클1 때보다 수정 범위가 줄었는가/늘었는가

3. 규칙 적용으로 변경한 코드 1곳

4. 테스트가 설계를 도운 순간 1회

체크 리스트

사이클 2의 수정사항 (260316)

사이클 2의 수정사항2 (260318)

Uh oh!

jurlring left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

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

Uh oh!

사이클 2의 수정사항 (260316)

Uh oh!

jurlring left a comment

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ParkJiYeoung8297 commented Mar 17, 2026

사이클 2의 수정사항2 (260318)

Uh oh!

jurlring left a comment

ParkJiYeoung8297 commented Mar 13, 2026 •

edited

Loading

ParkJiYeoung8297 commented Mar 16, 2026 •

edited

Loading