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

JYL35 · 2026-03-14T22:03:58Z

안녕하세요. 제이미!
사이클 1에서도 리뷰 받았던 이든입니다.
우선 이번 사이클도 제출이 좀 늦어진 점 사과의 말씀 드립니다.

이번 사이클에서 생각보다 많은 시도를 하게 되어 제출이 늦어진 것 같습니다...

이번 리뷰도 잘 부탁드립니다!

체크 리스트

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

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

1. 인스턴스 변수 3개 제한과 상속 구조에서의 카운트 기준

이번 미션에서 '3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다'는 규칙을 지키기 위해 노력했습니다. 그런데 상속 구조(예: Member > Player)를 사용하다 보니, 부모 클래스의 필드와 자식 클래스의 필드를 합쳤을 때 이 기준을 어떻게 적용해야 할지 고민이 되었습니다.

리뷰어님은 상속 관계에서 부모와 자식의 필드 합계를 하나의 객체 크기로 보시는지, 아니면 각 클래스 단위로 보시는지 궁금합니다.

또한, 필드 개수를 줄이기 위해 상속을 선택하는 것이 객체지향적으로 옳은 방향인지에 대한 의견도 듣고 싶습니다.

2. 디미터 법칙(Law of Demeter)과 서비스 계층의 책임 범위

현재 구조가 Service > GameTable > Members > Member 순으로 레이어가 구성되어 있습니다. 하위 도메인이 데이터를 대신 전달해 주는 방식을 택하다 보니 상위 객체에 get 형식의 위임 메서드가 너무 많아지는 현상이 발생했습니다.

Service에서 직접 Member 객체를 가져와 제어하는 것이 계층 간 결합도를 높이는 행위일까요?

아니면 현재처럼 상위 도메인이 하위 도메인의 기능을 대신 호출(Wrapping)해 주며 캡슐화를 유지하는 것이 더 나은 설계일까요? 'Tell, Don't Ask' 원칙을 지키면서도 연쇄 Getter를 막을 수 있는지 궁금합니다. 혹은 어떤 것이 더 결합도를 높이는 행위인지 궁금합니다.

3. 테스트 코드의 유연성과 확장성 (OCP)

기능이 추가되더라도 기존 테스트가 잘 깨지지 않는 변경에 유연한 구조를 만들고자 노력했습니다. 상태 패턴을 도입하면서 새로운 상태(예: 새로운 규칙의 추가)가 생겨도 기존의 State 테스트나 구현 로직이 수정되지 않고 확장될 수 있도록 설계하고자 했습니다. 이 부분이 의도대로 잘 읽히는지 의견을 듣고 싶습니다.

4. 불변 객체(Immutable Object)와 엔티티의 필드 변경

Hand를 불변 객체로 리팩토링하면서 객체의 안정성은 높아졌으나, 이를 보유한 상위 도메인인 Member의 hand 필드에 final을 사용할 수 없는 문제가 생겼습니다. 만약 Member까지 불변으로 만들면 이를 관리하는 Members 리스트까지 매번 새로 생성해야 하는 불변의 연쇄 현상이 발생하게 되었습니다.

불변와 가변의 경계에서, 모든 상위 도메인을 불변으로 가져가는 것이 MVC 혹은 일반적인 웹 애플리케이션 구조에서 현실적인 대안일까요?

필드에 final을 쓰지 못하더라도 내부 상태만 불변으로 유지하는 선에서 타협하는 것이 일반적인지 리뷰어님의 조언을 듣고 싶습니다.

긴 글 읽어주셔서 감사합니다!

- 초기 Hand는 불변 리스트로 초기화 - appendCard 시에 불변 리스트에 카드를 추가하여 새로운 Hand 객체를 반환

- 멤버 명단 테스트 - 카드 추가 테스트 - 딜러 게임 결과 결정 테스트 - 플레이어 게임 결과 결정 테스트

- Draw 시 출력 후 early return이 누락되어 수정

- CardNumber, CardPatter 필드 final 누락으로인해 수정

- Cotroller: 메소드명 수정 및 게임 초기화 기능 사용 분기 수정

- 필드와 메소드를 딜러와 플레이어로 분리 - Word: ViewMessage로 이름 변경 및 딜러 이름 제거

- 52가지 카드를 저장하도록 구현 - 팩토리 메소드는 저장소에서 get하여 반환 - 52가지 카드를 매번 생성하고 지워야할 일이 없어짐

- VO: 같은 금액일 때 같은 객체로 취급하도록 구현 (같은 가치 취급) - 예외: 베팅 금액이 0원 미만이면 예외 발생 - 수익금 계산: 수익률을 받아 수익금 계산

- 상태 패턴 도입을 위해 State 계층 및 Started, Finished 추상 클래스 구현 - 종료 상태인 Bust와 Blackjack 구현

…인으로 변경

- 플레이어가 더 이상 카드를 받지 않고 싶어하면 상태가 Stay로 바뀌는 기능 구현

- 각 State별 stay() 기능 추가

상태 패턴 도입 및 베팅 기능 추가

BlackjackView 구현 및 버그 수정

jamie9504

안녕하세요, 이든. 리뷰어 제이미입니다.

코멘트 남겨두었습니다.

jamie9504 · 2026-03-15T16:38:46Z

src/main/java/application/BlackjackService.java

@@ -1,12 +1,16 @@
 package application;


우선 이번 사이클도 제출이 좀 늦어진 점 사과의 말씀 드립니다.

미션 요구사항에 제출 기한이 명시되어있지 않았다면, 사과하지 않으셔도 됩니다.
저는 신경쓰지 않는 편이지만, 다른 리뷰어를 만났을 때는 상호간의 일정을 위해 오래 걸릴 것 같으면 DM을 남겨두는 방법도 있을 것 같아요.

리뷰어님

제이미로 충분합니다.

인스턴스 변수 3개 제한과 상속 구조에서의 카운트 기준

이번 미션에서 '3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다'는 규칙을 지키기 위해 노력했습니다. 그런데 상속 구조(예: Member > Player)를 사용하다 보니, 부모 클래스의 필드와 자식 클래스의 필드를 합쳤을 때 이 기준을 어떻게 적용해야 할지 고민이 되었습니다.

리뷰어님은 상속 관계에서 부모와 자식의 필드 합계를 하나의 객체 크기로 보시는지, 아니면 각 클래스 단위로 보시는지 궁금합니다.

또한, 필드 개수를 줄이기 위해 상속을 선택하는 것이 객체지향적으로 옳은 방향인지에 대한 의견도 듣고 싶습니다.

인스턴스 변수란, 일반적으로 객체 하나가 런타임에 실제로 보유하는 필드의 총합으로 봅니다. 클래스에 어떻게 선언되어 있는지는 크게 중요하지 않아요. 상속을 했더라도, 런타임에 해당 객체가 실제로 가지고 있는 변수는 3개가 되겠죠?

필드 수를 줄이기 위해 상속을 선택하는 것은 좋지 않습니다. 상속은 "is-a"가 명확할 때 사용해야 합니다. 물론 지금은 Player가 Member인 관계는 자연스럽지만, 필드수 제한을 피하려는 목적으로 상속을 사용한다면 설계 자체가 왜곡될 수 있어요.

디미터 법칙(Law of Demeter)과 서비스 계층의 책임 범위

현재 구조가 Service > GameTable > Members > Member 순으로 레이어가 구성되어 있습니다. 하위 도메인이 데이터를 대신 전달해 주는 방식을 택하다 보니 상위 객체에 get 형식의 위임 메서드가 너무 많아지는 현상이 발생했습니다.

Service에서 직접 Member 객체를 가져와 제어하는 것이 계층 간 결합도를 높이는 행위일까요?

아니면 현재처럼 상위 도메인이 하위 도메인의 기능을 대신 호출(Wrapping)해 주며 캡슐화를 유지하는 것이 더 나은 설계일까요? 'Tell, Don't Ask' 원칙을 지키면서도 연쇄 Getter를 막을 수 있는지 궁금합니다. 혹은 어떤 것이 더 결합도를 높이는 행위인지 궁금합니다.

현재 구조인 상위 도메인이 하위 도메인의 기능을 Wrapping하는 방식이 더 낫습니다. 단, 위임 메서드가 과도하게 늘어난다면 중간 계층 자체가 불필요하다는 신호일 수 있어요.

Service → GameTable → Members 3단계보다 Service → Members 2단계로 줄이는 것도 고려해보세요. GameTable이 실질적으로 Members를 얇게 감싸는 역할만 한다면 제거 대상이 될 수 있어요.

테스트 코드의 유연성과 확장성 (OCP)

기능이 추가되더라도 기존 테스트가 잘 깨지지 않는 변경에 유연한 구조를 만들고자 노력했습니다. 상태 패턴을 도입하면서 새로운 상태(예: 새로운 규칙의 추가)가 생겨도 기존의 State 테스트나 구현 로직이 수정되지 않고 확장될 수 있도록 설계하고자 했습니다. 이 부분이 의도대로 잘 읽히는지 의견을 듣고 싶습니다.

상태 패턴 도입으로 새로운 상태 추가 시 기존 테스트가 깨지지 않는 구조는 잘 잡혀 있어요. 다만 instanceof 사용이 남아있는 한 완전한 OCP라고 보기 어렵습니다. instanceof 제거 후에야 진정한 확장에 열린 구조가 됩니다.

불변 객체(Immutable Object)와 엔티티의 필드 변경

Hand를 불변 객체로 리팩토링하면서 객체의 안정성은 높아졌으나, 이를 보유한 상위 도메인인 Member의 hand 필드에 final을 사용할 수 없는 문제가 생겼습니다. 만약 Member까지 불변으로 만들면 이를 관리하는 Members 리스트까지 매번 새로 생성해야 하는 불변의 연쇄 현상이 발생하게 되었습니다.

불변와 가변의 경계에서, 모든 상위 도메인을 불변으로 가져가는 것이 MVC 혹은 일반적인 웹 애플리케이션 구조에서 현실적인 대안일까요?

필드에 final을 쓰지 못하더라도 내부 상태만 불변으로 유지하는 선에서 타협하는 것이 일반적인지 리뷰어님의 조언을 듣고 싶습니다.

모든 계층을 불변으로 만든다면, 모든 계층을 불변으로 만든다면 객체 재생성 비용과 코드 복잡도가 커지겠죠?
뭐든지 어떤 것을 선택하던 트레이드오프입니다. 장/단점을 비교했을 때 장점이 더 큰 경우에만 사용하면 됩니다.

Member의 state 필드에 final을 못 쓰는 것은 현재 설계상 자연스러운 트레이드오프입니다. 이 경우 setter를 노출하지 않고 receiveCard()처럼 의미있는 메서드로만 상태를 변경하는 것이 좋은 타협점이에요.

jamie9504 · 2026-03-15T16:42:05Z

src/main/java/domain/state/Stay.java

+
+    @Override
+    public double earningRate(State dealerState) {
+        if (dealerState instanceof Bust) {


상태 패턴의 장점 중 하나가 바로 이런 instanceof 분기를 없애는 것인데,
현재 earningRate 내부에서 다시 instanceof로 판별하고 있어서 패턴의 효과가 반감되고 있어요.

이 분기를 제거할 수 있는 방법이 있을지 고민해보세요.
(코드 전반적으로 검토해보세요.)

jamie9504 · 2026-03-15T16:42:53Z

src/main/java/domain/state/DealerHit.java

+    @Override
+    public State stay() {
+        throw new IllegalArgumentException("딜러는 스스로 멈출 수 없습니다.");
+    }


State 인터페이스에 stay()가 있는데, 딜러는 이를 호출할 수 없어 예외를 던지고 있네요.

딜러와 플레이어의 상태를 같은 인터페이스로 묶는 것이 적절한지,
역할별로 인터페이스를 분리하는 방향을 고민해보세요!

jamie9504 · 2026-03-15T16:46:15Z

src/main/java/domain/GameTable.java

+import domain.card.Card;
+import domain.card.Deck;
+import domain.member.Money;
+import dto.MemberStatus;


domain이 dto를 알고 있고, dto도 domain을 알고 있네요.
이런 구조에서 어떤 문제가 생길 수 있을지 고민해보세요.

jamie9504 · 2026-03-15T16:48:06Z

src/main/java/domain/GameTable.java

+                .map(name -> new MemberStatus(name, members.findCardByName(name), members.checkPlayerScore(name)))
+                .forEach(memberStatuses::add);
+        return List.copyOf(memberStatuses);
+    }


getMemberStatuses()의 로직이 사실상 members 안에서 모두 처리될 수 있어 보여요.
GameTable이 이 역할을 직접 담당하는 것이 적절한지 고민해보세요.

jamie9504 · 2026-03-15T17:08:03Z

src/test/java/domain/card/MoneyTest.java

@@ -0,0 +1,35 @@
+package domain.card;


이 친구는 왜 이 패키지에 위치해 있을까요?

jamie9504 · 2026-03-15T17:09:59Z

src/test/java/domain/member/MembersTest.java

+
+import static org.assertj.core.api.Assertions.assertThat;
+
+public class MembersTest {


무승부 케이스나, 딜러 점수가 높아서 패배하는 케이스 등이 테스트되고 있나요?
TDD로 구현했다면 이런 케이스가 누락되지 않았을 것 같은데, 어떻게 생각하시나요?

jamie9504 · 2026-03-15T17:10:27Z

src/test/java/domain/state/HitTest.java

+    @DisplayName("플레이어가 카드를 뽑아 21점이 되었을 때 카드 개수가 2개가 아니면 Stay 상태를 반환한다")
+    @Test
+    void draw_TotalScoreIs21AndCardSizeIsNot2_ReturnBlackjack() {


DisplayName과 메서드명의 의미가 다르네요.

jamie9504 · 2026-03-15T17:12:54Z

src/main/java/domain/state/Stay.java

+        if (myScore > dealerScore) return MatchResult.WIN.profitRate();
+        if (myScore < dealerScore) return MatchResult.LOSE.profitRate();


기본적으로 Java Style Guide을 원칙으로 한다.

원칙을 한 번 읽어보고 적용해보세요.

jamie9504 · 2026-03-15T17:13:42Z

src/test/java/domain/card/MoneyTest.java

+    @DisplayName("금액이 같으면 같은 객체로 취급한다 (VO)")
+    @Test
+    void equals_SameAmount_ReturnTrue() {
+        assertThat(new Money(10000)).isEqualTo(new Money(10000));


천 단위에 _를 사용하면 가독성이 좋아져요. (예: 10_000)

JYL35 added 30 commits March 11, 2026 14:52

docs(README): 리뷰를 통해 수정한 내용을 반영

819bff5

refactor: 파일 구조 수정

258ba6f

refactor(Hand): 불변 객체로 수정

0e0783a

- 초기 Hand는 불변 리스트로 초기화 - appendCard 시에 불변 리스트에 카드를 추가하여 새로운 Hand 객체를 반환

refactor(Members): 플레이어 게임 결과 결정 기능 수정(간소화)

aeb1bd5

test(Members): 누락된 테스트 작성

e2ec1e6

- 멤버 명단 테스트 - 카드 추가 테스트 - 딜러 게임 결과 결정 테스트 - 플레이어 게임 결과 결정 테스트

refactor(OutputView): 플레이어 결과 출력 기능 수정

8ef0716

- Draw 시 출력 후 early return이 누락되어 수정

refactor(Card): 필드 불변으로 수정

5b571dd

- CardNumber, CardPatter 필드 final 누락으로인해 수정

refactor(Service): 필드 초기화 전 사용 가능성이 있어 방지 기능 구현

6b2d824

- Cotroller: 메소드명 수정 및 게임 초기화 기능 사용 분기 수정

refactor(Members): 딜러와 플레이어로 분리

8528c2d

- 필드와 메소드를 딜러와 플레이어로 분리 - Word: ViewMessage로 이름 변경 및 딜러 이름 제거

refactor(Deck): 덱 셔플 시 강제 캐스팅 제거

9f838fb

feat(ValidatedInput): 입력 값 검증 클래스 구현

45e3509

feat(InputView): 베팅 금액 입력 기능 구현

bc0a00a

docs(README): Cycle2 미션에 맞게 수정

3308686

test(Card): 같은 주소의 카드를 반환하는지 확인하는 테스트 작성

37ec062

feat(Card): 정적 팩토리 메소드 구현

63d3e91

- 52가지 카드를 저장하도록 구현 - 팩토리 메소드는 저장소에서 get하여 반환 - 52가지 카드를 매번 생성하고 지워야할 일이 없어짐

test(Money): VO 검증, 예외, 수익금 계산 테스트 작성

bd43438

feat(Money): VO, 예외, 수익금 계산 기능 구현

e429be5

- VO: 같은 금액일 때 같은 객체로 취급하도록 구현 (같은 가치 취급) - 예외: 베팅 금액이 0원 미만이면 예외 발생 - 수익금 계산: 수익률을 받아 수익금 계산

test(State): Bust와 Blackjack 상태 테스트 작성

9d85b36

feat(State): 게임 종료 상태 관리를 위한 State 추가

a9798d8

- 상태 패턴 도입을 위해 State 계층 및 Started, Finished 추상 클래스 구현 - 종료 상태인 Bust와 Blackjack 구현

test(State): Hit 이후 상태 전환 테스트 작성

c496ce9

test(State): Stay 상태의 종료 여부 및 수익률, 예외 테스트 작성

96fa9fe

feat(State): Stay 종료 상태 구현

880fc5d

test(State): Hit 상태 및 Running 클래스 구현

2af5859

test(State): 클래스 명 및 메소드 명 수정

52be408

test(Member): Player의 상태별 수익 반환 테스트 작성

9be9861

refactor(Money): Money 클래스 위치 변경

bcc7fca

refactor(Member): Member 클래스 상태 패턴 적용 및 Player 베팅 금액 필드 추가

e7d490a

refactor(Members & GameTable): Members 및 GameTable의 점수 직접 비교 로직을 상태 확…

d4cc1ad

…인으로 변경

refactor(Service): 변경된 GameTable에 맞게 수정

132e809

feat(Controller): 베팅 금액 입력 기능 구현

ab20a64

JYL35 and others added 19 commits March 15, 2026 02:45

test(State): 딜러가 카드를 뽑은 이후 반환되는 상태 테스트 작성

dd7d869

feat(State): 딜러가 카드를 뽑은 이후 상태 반환 기능 구현

88ecc99

test(State): 플레이어가 카드를 뽑았을 때 합산이 21이면 나오는 상태 테스트

7c01058

feat(State): 플레이어가 카드를 뽑았을 때 조건에 따라 상태 반환 기능 구현

93b9937

refactor(State): Blackjack, Stay, Bust의 수익률 반환 기능 수정

47725e2

test(Members): 모든 멤버 수익 정산 테스트

96872c3

feat(Members): 모든 멤버 수익 정산 기능 구현

426cc5e

- 플레이어가 더 이상 카드를 받지 않고 싶어하면 상태가 Stay로 바뀌는 기능 구현

refactor(Member): Bust 상태를 이용해서 Bust인지 확인하는 기능 구현

22ab1ca

refactor(Service): 모든 멤버의 게임 결과 반환 기능 수정

b8375da

refactor(View): 모든 멤버의 게임 결과 출력 기능 수정

2b3f0e0

fix(State): 블랙잭 시 베팅금에 1.5배 적용이 안되는 문제 해결

2d7bfcf

- 각 State별 stay() 기능 추가

style: 코드 컨벤션 맞춤

53d42bd

refactor(Dealer): 딜러 뽑기 조건 비교 기능 제거

457c5a6

refactor(Dealer): 사용하지 않는 클래스 상수 제거

9139edc

docs(README): 체크 리스트 확인

1351ebb

Merge pull request #5 from JYL35/cycle2

12afb7e

상태 패턴 도입 및 베팅 기능 추가

feat(View): inputView, outputView를 담는 BlackjackView 구현

ca8d35d

fix: 21이 되어도 종료하지 않는 현상 수정

b39a1d9

Merge pull request #6 from JYL35/cycle2

4bcf5fb

BlackjackView 구현 및 버그 수정

jamie9504 requested changes Mar 15, 2026

View reviewed changes

jamie9504 assigned jamie9504 and JYL35 Mar 15, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

[🚀 사이클2 - 미션 (블랙잭 베팅)] 이든 미션 제출합니다.#1127
JYL35 wants to merge 49 commits intowoowacourse:jyl35from
JYL35:step2

JYL35 commented Mar 14, 2026 •

edited

Loading

Uh oh!

jamie9504 left a comment

Uh oh!

jamie9504 Mar 15, 2026 •

edited

Loading

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

jamie9504 Mar 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants


		import static org.assertj.core.api.Assertions.assertThat;

		public class MembersTest {

		if (myScore > dealerScore) return MatchResult.WIN.profitRate();
		if (myScore < dealerScore) return MatchResult.LOSE.profitRate();

Conversation

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

Uh oh!

체크 리스트

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

1. 인스턴스 변수 3개 제한과 상속 구조에서의 카운트 기준

2. 디미터 법칙(Law of Demeter)과 서비스 계층의 책임 범위

3. 테스트 코드의 유연성과 확장성 (OCP)

4. 불변 객체(Immutable Object)와 엔티티의 필드 변경

Uh oh!

jamie9504 left a comment

Choose a reason for hiding this comment

Uh oh!

jamie9504 Mar 15, 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!

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

JYL35 commented Mar 14, 2026 •

edited

Loading

jamie9504 Mar 15, 2026 •

edited

Loading