oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-blackjack/moondev03/131-2/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,498 @@
+# PR #131 — [블랙잭 2단계] 다이스 미션
+
+- **Reviewee:** [@moondev03](https://github.com/moondev03)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/131
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @Gyuil-Hwnag (두루)
+- **라인 코멘트:** 22 스레드 / 32 코멘트 — 리뷰어 칭찬 다수 + 학생 자가 학습 답변 위주
+
+## 잘한 점 (설계 관점)
+
+- **`BetAmount` value class + `operator fun times` 오버로딩** — `betAmount.toDouble()` 같이 *value 접근 없는 직관적 변환*. 학생 자가 인용: *"`betAmount.value.toDouble()` 대신 `betAmount.toDouble()`을 사용하면, `value`에 직접 접근할 필요 없이 더 직관적으로 값을 변환할 수 있다고 생각했습니다. 또한, `value`를 `private`으로 감추면서 캡슐화를 유지할 수 있어, 향후 내부 구현을 변경하더라도 외부 코드에 영향을 주지 않는 장점이 있다고 생각합니다!"*
+- **`Score` private constructor + `Score.create(cards)` 팩토리** — *Ace 11 기본 + 21 초과 시 ace 카운트만큼 -10 반복* 패턴. *Ace 다수 (2장 이상) 정확 처리* — `repeat(aceCount) { if (total > 21) total -= 10 }` 로 *Ace 11→1 점진적 변환*. PR #128·#135·#114·#125 와 같은 결의 Ace 정공 패턴.
+
+  ```kotlin
+  private fun adjustAceValues(sum: Int, cards: List<Card>): Int {
+      val aceCount = cards.count { it.number == CardNumber.ACE }
+      var total = sum
+      repeat(aceCount) { if (total > BLACKJACK_SCORE) total -= ACE_BASE_SCORE }
+      return total
+  }
+  ```
+
+  *Ace 2장 이상 + 합 > 21* 일 때 *한 Ace씩 -10*. 21 ≤ 합 이면 종료.
+- **`PersonState` enum + `isFinal` 부가속성** — *HIT/BUST/STAY/BLACKJACK* 4상태 + *`isFinal` boolean*. *상태 일급화* 시도. *`Person.isDrawable() = !state.isFinal`* 이 *상태로부터 의미 추출*.
+- **`BlackJackInputView` / `BlackJackOutputView` interface** — DIP (Dependency Inversion Principle). 학생 PR 본문 자가 인용: *"BlackJackInputView / BlackJackOutputView => Interface. BlackJack Interface로 추가하여 어떤 컨트롤러든 BlackJackGame을 사용할 수 있도록 ..."*. 두루 코멘트: *"이전 코멘트에 남겨두었던 interface로 하셨군요💪 하시면서, 어떤 생각이 드셨을까요?"*. 학생 자가 답변: *"BlackJack View Interface를 작성하므로써 View 구현체에 따라 사용자가 원하는 다양한 형태의 뷰를 즐길 수 있을 것 같습니다."*
+- **`PersonCards` → `Hand` 합치기 자가 반영 — *깊이 (Player → Hand → PersonCards)* 축소** — 학생이 *Score 객체 분리 후 Hand의 역할 늘어남*을 *PersonCards 추출*로 풀려 했으나, 두루의 *"`Player -> Hand -> PersonCards` 뎁스가 깊어진다"* 진단으로 *Hand 안에서 다시 합침* 자가 후퇴. 학생 자가 답변: *"다시 PersonCards를 제거하고 Hand에서 관리하도록 변경했습니다."* — *과도한 분리 vs 깊이* 트레이드오프 자가 학습.
+- **콜백 → 인터페이스 주입 자가 반영 (DIP 자가 학습)** — 이전 콜백 형태에서 *`BlackJackGame.play()` 한 줄로 게임 진행*. 학생 자가 학습: *"콜백으로 인해 컨트롤러에 중복 코드가 제거되니 코드가 깔끔해진 것 같습니다! 추가로 의존성 역전 원칙(DIP) 개념에 대해 찾아볼 수 있는 기회가 된 것 같습니다!"*
+- **`Deck` 카드 부족 리필** — 두루 자가 칭찬: *"덱이 다 떨어졌을 때, 리필을 하는 기능 추가 좋습니다👍"*. PR #108·#133 (시아) 와 같은 결의 *카지노 무한 게임* 메타포 반영.
+- **수익률 계산 책임 분리** — `PlayerBetInfo.calculatePlayerPayout(dealer): Profit` + `GameResult` 컬렉션 + `Profit` 값 객체. *베팅 정보 + 결과 계산 책임 응집*. 두루 자가 칭찬: *"PlayerBetInfo 객체를 통해서, 플레이어가 이기고 졌을때 등에 대한 게임의 배팅 결과를 알려주는 군요👍"*.
+- **테스트 다양화 — BetAmount/PlayerBetInfo/BlackJackGame Controller/UI** — 두루 다중 칭찬: *"BetAmount에 대한 테스트 좋습니다~👍"*, *"Controller 테스트 형태를 작성하셨군요👍"*, *"Ui 테스트 형태를 작성해보셨군요👍"*. *흑백 테스트 + 인터페이스 테스트 + 도메인 객체 테스트* 다양화.
+- **`Player.changeToStay()` 만 state 변경 — 의도 제한** — `Player` 만 `STAY`로 변경 가능 + `Dealer`는 *자기 hit 룰 따라 자동 상태 전이*. *Player 의지에 의한 상태 변경* vs *Dealer 자동 룰* 의 구분. 다만 *protected var 의 자식 접근* 함정도 동반 (못한 점 §3).
+- **기본 생성자 자가 제거** — 두루의 *"개인적으로 생성자에 기본 생성자가 있는건 지양을 하는편이긴 합니다. ... 기본 생성자로 되어 있다보면, 개발자가 자칫 잘못해서 생성시에 빠트리는 경우가 있습니다."* 권고에 *기본 생성자 제거* 자가 반영.
+
+## 못한 점 (설계 관점)
+
+### 1. `BlackJackGame` 의 `lateinit var deck/dealer/playerBetInfos` — *호출 순서 invariant*
+
+```kotlin
+class BlackJackGame(
+    private val inputView: BlackJackInputView,
+    private val outputView: BlackJackOutputView,
+) {
+    private lateinit var deck: Deck
+    private lateinit var dealer: Dealer
+    private lateinit var playerBetInfos: List<PlayerBetInfo>
+
+    fun play() {
+        prepareGame()    // 여기서 초기화
+        runGame()        // 사용
+        finishGame()     // 사용
+    }
+
+    private fun prepareGame() {
+        deck = Deck()
+        dealer = Dealer()
+        playerBetInfos = generatePlayers()
+    }
+    ...
+}
+```
+
+→ **`lateinit var` 3개 + `prepareGame` 누락 시 `UninitializedPropertyAccessException`**. *play() 가 외부 진입점*이므로 *prepareGame → runGame → finishGame 순서가 보장*되긴 하나, *Kotlin lateinit 안티패턴*: *상태가 두 단계 (초기화 전/후) 로 나뉘어 invariant 가 암묵적*. *`init`에서 모두 초기화* 하거나 *생성자에 주입*이 자연.
+
+*deck/dealer 가 매 `play()` 호출마다 새로 생성* 의도면 *`run()` 시작 부분에서 새 `BlackJackGame` 인스턴스* 가 더 명료. *재사용 가능 BlackJackGame* + *상태 가짐* 의 트레이드오프 — 현재 *재사용 가능 + lateinit 의존*. PR #28·#92·#65·#10·#124 와 같은 결.
+
+### 2. `PersonState.from(person)` 정적 팩토리 + `Dealer` 타입 검사 — *안티 다형성*
+
+```kotlin
+enum class PersonState(val isFinal: Boolean) {
+    HIT(false), BUST(true), STAY(true), BLACKJACK(true);
+
+    companion object {
+        fun from(person: Person): PersonState {
+            val score = person.score()
+            val isDealer = person is Dealer  // ⚠ 타입 검사
+
+            return when {
+                person.cards().size == 2 && score.isBlackJackScore() -> BLACKJACK
+                score.isBustScore() -> BUST
+                isDealer && score.isDealerStayScore() -> STAY
+                else -> HIT
+            }
+        }
+    }
+}
+```
+
+→ **`person is Dealer` 타입 검사 = *Player/Dealer 다형성 부재 신호***. *Dealer는 *17 이상이면 STAY**, *Player는 *외부 입력 (`Player.changeToStay`)으로 STAY**. *룰 차이 = 다형성*. *Person.stateAfterDraw(): PersonState* abstract method 면 *Dealer는 17 이상 STAY 로직 / Player는 default HIT*. 현재는 *enum 안에 타입 검사* — *enum 이 Person 의 subtype 의식*.
+
+또한 `PersonState.from(person)` 호출이 *`Person.draw(deck)` 에서 매번*:
+
+```kotlin
+fun draw(deck: Deck) {
+    hand.addCard(deck.draw())
+    state = PersonState.from(this)  // ⚠ 매 카드마다 상태 재계산
+}
+```
+
+*상태 = 카드들로부터 매번 derive* — *상태 자체가 데이터인지 캐시인지 모호*. *진짜 State 패턴 (PR #152·#133·#136 등)* 은 *상태 객체 = 다음 상태로 전이*. *enum + from* 은 *상태 = 일종의 derived snapshot*. *Tell-Don't-Ask 의 메시지 분배*는 *State 객체 다형성*이 더 자연.
+
+### 3. `Person.protected var state` + `val gameState: PersonState get() = state` — *두 getter + 자식 접근*
+
+```kotlin
+abstract class Person {
+    protected var state: PersonState = PersonState.HIT
+    val gameState: PersonState get() = state  // ⚠ 같은 상태 두 이름
+
+    fun isDrawable(): Boolean = !state.isFinal
+    fun draw(deck: Deck) {
+        hand.addCard(deck.draw())
+        state = PersonState.from(this)
+    }
+    ...
+}
+
+class Player(...) : Person() {
+    fun changeToStay() {
+        state = PersonState.STAY  // ⚠ 자식이 부모 protected var 직접 변경
+    }
+}
+```
+
+두루 (Person.kt — 미해결): *"아래와 같이 사용을 하는 방법도 있습니다~ 다이스가 보시기에는 각 두방식은 어떤 차이점이 있을까요? `protected var state: PersonState = PersonState.HIT` `val gameState: PersonState get() = state` 예시 `var state: PersonState = PersonState.HIT; private set`"*
+
+학생 자가 답변: *"Person을 상속받는 Player에서는 STAY 상태로의 전환을 허용해야 해서 해당 형태로 작성했습니다. 원래는 Person에서 상태를 변경하는 함수를 만들었지만, STAY 상태로 변경하는 기능은 Player에서만 필요했기 때문에 이런 구조가 된 것 같습니다."*
+
+→ **`var state` (자식이 직접 변경) + `val gameState` (외부 노출 read-only) = *두 이름이 같은 상태***. *Kotlin `var state private set` + `protected fun stayed()` (자식이 호출)* 패턴이 *접근 통제* 정공. *`protected var` + 자식 직접 변경*은 *Player가 PersonState.STAY 만 set 한다는 invariant*가 *암묵적* — *Player.changeToBust() 같은 잘못된 변경*도 *컴파일러가 차단 안 함*.
+
+*Dealer 자기 상태 = PersonState.from(this) 결정 (draw 안에서)*. *Player.changeToStay = 외부 의지*. 두 진입점이 *명시적 메서드*면 *invariant 강제*. *현재는 var state 직접 변경*이 *책임 분배 불명확*.
+
+### 4. `PlayerBetInfo.calculatePlayerPayout` 의 *Player.gameState 분기 + ResultState 정적 호출*
+
+```kotlin
+class PlayerBetInfo(
+    val player: Player,
+    private val betAmount: BetAmount,
+) {
+    fun calculatePlayerPayout(dealer: Dealer): Profit {
+        val resultState = ResultState.calculateWin(player, dealer)  // ⚠ 정적 호출
+        val profit = when (resultState) {
+            ResultState.WIN -> calculateWinPayout()
+            ResultState.LOSE -> calculateLosePayout()
+            ResultState.DRAW -> calculateDrawPayout()
+        }
+        return Profit(profit)
+    }
+
+    private fun calculateWinPayout(): Double {
+        if (player.gameState == PersonState.BLACKJACK) {  // ⚠ gameState 분기
+            return betAmount * BLACKJACK_PAYOUT_MULTIPLIER
+        }
+        return betAmount * WINNING_PAYOUT_MULTIPLIER
+    }
+    ...
+}
+```
+
+→ **`ResultState.calculateWin(player, dealer)` 정적 호출 + `player.gameState` 분기**. *Tell-Don't-Ask 의 양면 위반*:
+
+1. **`ResultState.calculateWin(player, dealer)` 정적 헬퍼** — *Player.compete(other)* 메시지가 정공. PR #108·#133 (시아) 와 같은 결.
+2. **`player.gameState == PersonState.BLACKJACK` 분기** — *PlayerBetInfo가 Player의 상태를 검사 + 분기*. *Player.isBlackjack(): Boolean* 메시지가 *Tell-Don't-Ask*. 또는 *resultState 자체가 *WinNormal* vs *WinBlackjack* 으로 분리*.
+
+*수익률 룰* = *BLACKJACK = 1.5배, WIN = 1.0, DRAW = 0, LOSE = -1*. *ResultState* 가 *4 멤버 (WinBlackjack, Win, Draw, Lose)* 면 *gameState 분기 사라짐*. PR #132 (환노) 의 *`WinningResult.BlackjackWin`* 과 같은 결.
+
+### 5. `BetAmount * Int = Int` / `BetAmount * Double = Double` — *반환 타입이 Money 가 아님*
+
+```kotlin
+class BetAmount(val value: Int) {
+    operator fun times(multiplier: Int): Int = value * multiplier
+    operator fun times(multiplier: Double): Double = value * multiplier
+    ...
+}
+
+// 사용처
+return betAmount * BLACKJACK_PAYOUT_MULTIPLIER  // Double 반환
+return betAmount * LOSING_PAYOUT_MULTIPLIER     // Int 반환 (LOSING = -1)
+```
+
+→ **`BetAmount * multiplier` 반환 타입이 *원시 타입 (Int/Double)***. *수익 금액* 도메인 객체 (`Profit`/`Money`) 가 *없음*. *BetAmount * 1.5 = Double* 이 *Profit (Double 으로 표현)* 으로 *다음 단계에서 wrap*:
+
+```kotlin
+return Profit(profit)
+```
+
+이 *3 단계 변환* — *value 추출 → 곱셈 → Profit wrap*. *`BetAmount * multiplier: Profit`* 직접 반환이 *도메인 어휘 + 변환 단계 감소*. PR #133 (시아 2단계) 의 *Money.multiplyMoney* 와 *반대 트레이드오프* (시아는 Money 도메인 객체 + 가변/연산자 함정, 다이스는 도메인 객체 없음 + 단순).
+
+또한 `LOSING_PAYOUT_MULTIPLIER = -1 (Int)` 인데 `WINNING = 1.0 (Double)` — *타입 일관성 부재*. `LOSING = -1.0` 으로 통일이 자연.
+
+### 6. `GameResult.calculateDealerProfit` — *`NEGATIVE_ZERO_PROFIT = -0.0` 우회 — Double 산술 정밀도 함정*
+
+```kotlin
+class GameResult(dealer: Dealer, playerBetInfos: List<PlayerBetInfo>) {
+    val playerPayouts: Map<Player, Profit> = playerBetInfos.associateBy(...)
+    val dealerProfit: Profit = calculateDealerProfit()
+
+    private fun calculateDealerProfit(): Profit {
+        val profit = playerPayouts.values.sumOf { it.value } * NEGATIVE_ONE
+        val result = if (profit == NEGATIVE_ZERO_PROFIT) ZERO_PROFIT else profit
+        return Profit(result)
+    }
+
+    companion object {
+        const val ZERO_PROFIT = 0.0
+        const val NEGATIVE_ZERO_PROFIT = -0.0
+        const val NEGATIVE_ONE = -1
+    }
+}
+```
+
+→ **`-0.0` 우회 = *Double IEEE 754 부호 있는 0 함정***. *0.0 * -1 = -0.0* 인데 *외부 노출 시 "-0" 으로 표시* 문제. *학생이 `-0.0`을 명시적으로 검사 + 0.0 으로 변환*. *현실 도메인 의미는 "딜러 수익 = 0"*. *우회 자체는 좋은 면* — *Double 산술 함정 자가 인식*.
+
+다만 *근본 해결*은 *BigDecimal 또는 Long (cents 단위)* 으로 *부호 있는 0 자체 회피*. *금융 도메인 표준*이 *BigDecimal*. 현재 *Double + -0.0 우회* 는 *임시 해결*. PR #133 (시아 2단계) 의 *Money Double 정밀도* 와 같은 결.
+
+또한 `playerPayouts.values.sumOf { it.value } * -1` 자체는 *총합의 부호 뒤집기*. *딜러 수익 = 플레이어 수익의 합 × -1* 룰 정확. *명시*. PR #133 의 *getDealerResult* 와 같은 결.
+
+### 7. `PersonState.from(person)` 호출이 *State 다형성 vs enum 정적 분기* 의 경계
+
+```kotlin
+fun draw(deck: Deck) {
+    hand.addCard(deck.draw())
+    state = PersonState.from(this)
+}
+```
+
+→ **State 다형성 vs enum + 정적 분기**:
+
+- *PR #152 (모찌) 식 State 패턴* — `Hit.draw(card): State` 가 *다음 상태로 전이* — 다형성으로 분기 0.
+- *PR #131 (다이스) PersonState enum* — `PersonState.from(person)` 가 *Person 정보로 상태 결정* — 정적 분기.
+
+*트레이드오프*: enum + from = *변경 1곳 (from 함수)*, *Person.draw 호출자 분기 0*. State 패턴 = *상태별 클래스 분리*, *새 상태 추가 시 클래스 + 분기 추가*. *현재 4 상태 (HIT/BUST/STAY/BLACKJACK)* 면 *enum 으로 충분*. *상태별 행동 차이가 작으면 enum 정공*. *상태별 행동 차이가 크면 State 객체 정공*.
+
+다이스의 enum 선택은 *행동 = isFinal boolean* 만 다르고 *나머지는 Person.draw/cards/score 공통* 이므로 *enum 정합*. PR #152·#133·#136 의 *State sealed* 와 *반대 트레이드오프 선택*.
+
+### 8. `BlackJackGame.runGame()` god-object 변형
+
+```kotlin
+fun play() {
+    prepareGame()
+    runGame()
+    finishGame()
+}
+
+private fun runGame() {
+    dealCards()
+    playPlayersTurns()
+    playDealerTurns()
+}
+```
+
+→ **`BlackJackGame` 이 *Controller 절차적 명령 + 도메인 진행 흡수*** — 1단계 *BlackJackController god-object → 2단계 BlackJackGame god-object* 의 *이름 변경 + 책임 흡수*. *play/prepareGame/runGame/finishGame/dealCards/playPlayersTurns/playDealerTurns/playPlayerTurn/playerPlayerTurns/...* 메서드 다수.
+
+다만 *Controller 책임* 과 *Game 도메인 책임* 의 *경계가 모호한 채 한 클래스* — *InputView/OutputView 보유 + 도메인 객체 (Deck/Dealer/PlayerBetInfo) 생성 + 게임 진행*. PR #133 (시아 2단계) 의 *BlackjackEngine god-object* 와 같은 결.
+
+두루 코멘트 (BlackJackController.kt:10 — 미해결): *"너무 잘해주셔서, 코멘트 내용이 많지 않을 것 같은데, 시간이 있는 만큼 콜백 형태로도 구현을 해봤으니, 함수의 파라미터로 받아서 처리를 하는 방법도 구현을 해보고 두개를 비교해보는 것 과정에서도 얻을 것이 있을 것 같다는 생각이 듭니다💪 Controller 에서 `BlackjackGame.play()` 하나로 블랙잭 게임을 할 수 있는 형태로요"*
+
+→ ***Controller 가 BlackJackGame.play() 한 줄 호출*** 패턴 권고. *현재 BlackJackGame 가 Controller 역할까지 + InputView/OutputView 의존*. *Controller = main + BlackJackGame 생성 + play()* 만 호출이면 *완전한 분리*.
+
+### 9. `playPlayerTurn(player)` — *if-return + else branch 분리 부재*
+
+```kotlin
+private fun playPlayerTurn(player: Player) {
+    if (isHit(player.name)) {
+        player.draw(deck)
+        outputView.printPlayerDrawStatus(player)
+        return
+    }
+
+    player.changeToStay()
+}
+```
+
+→ **`isHit` 분기 후 if-return + else (`player.changeToStay()`)** — *Kotlin `when (isHit) { true → ..., false → ... }`* 또는 *`if-else`* 가 *대칭 분기* 표현. *if-return + 외부 else* 는 *Java 어휘*. Kotlin 어휘로 통일.
+
+또한 *`isHit(player.name)` 이 매 turn 마다 외부 입력* 이고 *`while (player.isDrawable())` 외부 루프* — *if-return 으로 매 iteration 종료*. *false 시 changeToStay → state.isFinal == true → 루프 종료* — *암묵적 흐름*. *Player.act(action: ActionType) (HIT/STAY 입력 받아 자기 상태 변경)* 메시지가 정공.
+
+### 10. `BlackJackGame` 이 *InputView 메서드를 직접 호출* — Controller 책임의 흡수
+
+```kotlin
+private fun generatePlayers(): List<PlayerBetInfo> {
+    val players = readPlayerNames()
+    return players.map { player ->
+        val betAmount = readPlayerBetAmount(player.name)
+        PlayerBetInfo(player, betAmount)
+    }
+}
+
+private fun readPlayerNames(): List<Player> =
+    retryWhenException {
+        inputView.getNames().map { name -> Player(name) }
+    }
+```
+
+→ **`BlackJackGame` 이 *InputView.getNames() + InputView.getBetAmount(name)* 직접 호출**. *도메인이 InputView 의존* — *InputView interface 추상화*는 했지만 *도메인이 의존*. *Controller 가 입력 받아 도메인에 전달* 패턴이 *MVC 의 정공*.
+
+다만 *BlackJackGame interface* 추상화 의도면 *InputView 인터페이스 의존이 BlackJackGame interface 안에서 표현*. *학생 PR 본문 = "어떤 컨트롤러든 BlackJackGame을 사용할 수 있도록"* — *역방향 의존 (Controller → BlackJackGame)* 인데 *BlackJackGame → InputView* 도 의존. *DIP* 가 *완전히 도메인 → 인터페이스* 방향 — *InputView 가 도메인의 컨벤션을 따름*.
+
+### 11. `Score.isDealerStayScore()` — *딜러 룰을 Score 객체가 알고 있음*
+
+```kotlin
+class Score private constructor(val value: Int) {
+    fun isBlackJackScore(): Boolean = value == BLACKJACK_SCORE
+    fun isBustScore(): Boolean = value > BLACKJACK_SCORE
+    fun isDealerStayScore(): Boolean = value > DEALER_ADDITIONAL_DRAW_BASE_SCORE
+    ...
+}
+```
+
+→ **`Score.isDealerStayScore` = *딜러 룰 (16점 초과면 STAY) 이 Score 안***. *Score 는 일반 점수 객체* 인데 *딜러 룰 의식*. *Dealer.canDraw() = score.value <= 16* 같은 *Dealer 안에서 직접*이 자연 — *Score는 *17 이상이 Dealer STAY*라는 룰 모름*.
+
+또한 `isDealerStayScore` 는 *> 16* 검사. *Dealer.isDrawable() = !state.isFinal* 의존 + *PersonState.from* 에서 *isDealer && score.isDealerStayScore() -> STAY* 호출. *Score → PersonState → Person → Dealer 의 4 단계 의존*. *룰 위치가 분산*.
+
+### 12. `Score.value` public — *Score 도메인 캡슐화 미달*
+
+```kotlin
+class Score private constructor(val value: Int) { ... }
+```
+
+→ **`Score.value` 가 *public*** — *Score 객체*의 *내부 표현 (Int)* 이 *외부 노출*. *Profit/PersonState/PlayerBetInfo* 등이 *score.value 직접 접근* 가능. *`Score.isXX()` 메시지가 외부 분기 대체*면 *value 직접 노출 불필요*. *value private + 메시지만 노출*이 *캡슐화 정공*.
+
+다만 *value 가 외부에 표시 (OutputView)* 가 필요하면 *Score.toString() / .display()* 같은 *명시적 노출 메시지*가 자연. PR #136 (밀러 2단계) 의 *Score 캡슐화* 와 같은 결.
+
+### 13. `Player.isFinal` 변수 미사용 의문 — 두루의 미세 진단
+
+```kotlin
+// PersonState.isFinal 사용처
+fun isDrawable(): Boolean = !state.isFinal
+```
+
+두루 코멘트 (PersonState.kt:7 — 미해결): *"이제 isFinal 이라는 변수는 따로 사용이 안되고 있군요~"*
+
+학생 자가 답변: *"Person에 있는 isDrawable()에서 사용하고 있습니다!"*
+
+→ **isFinal = 상태가 종결 상태인지 boolean** — *isDrawable* 외 *추가 사용처 없음*. *isDrawable() = (state == HIT)* 와 동등 (4 상태 중 HIT만 not final). *enum 부가 속성이 단일 사용처* — *직접 검사*가 더 명료할 수도. 다만 *isFinal 표현이 더 의미 명시*면 OK. *코드 미세 다이어트* 여부의 트레이드오프.
+
+### 14. `BetAmount.MIN_BET_AMOUNT = 0` — *최소 베팅 0원 허용?*
+
+```kotlin
+class BetAmount(val value: Int) {
+    init {
+        require(value >= MIN_BET_AMOUNT) { INVALID_BET_AMOUNT_MESSAGE }
+    }
+    ...
+    companion object {
+        private const val MIN_BET_AMOUNT = 0
+        ...
+    }
+}
+```
+
+→ **`MIN_BET_AMOUNT = 0` 허용** — *0원 베팅이 도메인 의미 있는가*. *베팅 = 거는 금액*이면 *최소 1원 이상*. *0원 허용*은 *베팅 안 함*과 구분 불가. *MIN_BET_AMOUNT = 1* 또는 *최소 1000원*이 *카지노 룰 표준*. *도메인 invariant 미강제*.
+
+### 15. `PersonCards` 분리/재합치 — 깊이 vs 책임의 균형 학습
+
+학생 자가 답변 (PersonCards.kt): *"저도 고민했던 부분인데 기존 `Hand`는 카드만을 관리하기 위해 구현했으나, 리팩토링을 수행하면서 점수 객체가 포함되게 되었습니다. 이로 인해 `Hand`의 역할이 늘었났다고 판단해서 분리하고 싶었습니다. 책임을 분리한 후 각각의 모델은 다음과 같은 책임을 수행하게 되었습니다. - `PersonCards`는 단지 카드를 관리하는 객체로서, 카드 추가나 카드 목록을 조회하는 책임만 집니다. - `Hand`는 `PersonCards`가 제공하는 카드 목록을 사용하여 점수 계산과 같은 역할을 수행합니다. 이 구조로 변경하므로써 두 모델의 하나의 책임을 가지게 되었다고 생각합니다!"*
+
+두루 후속: *"살짝 찜짬한 의문이 들었던 것은 아래와 같은 뎁스 형태로 구현이 되어 있어서 였습니다. `Player -> Hand -> PersonCards` 이렇게 객체간의 뎁스 형태로 되어 있다보면, 추후 요구사항이 변경되거나 뎁스 하단의 구조가 변경이 된다면, 자칫 잘못하면 전체 구조가 바뀔 수 있을 수 있겠다는 생각이 듭니다. 뎁스 구조에서 `점수 계산기 / 카드 관리`이렇게 분리를 해서 최 상단에서 계산을 해보도록 하는 것은 어떤가 라는 생각이 들었어요!"*
+
+학생 자가 답변: *"다시 PersonCards를 제거하고 Hand에서 관리하도록 변경했습니다."*
+
+→ **책임 분리 vs 객체 깊이 트레이드오프**. *Hand → PersonCards* 1 단계 더 깊어진 구조가 *변경 파급 ↑ + 디미터 위반 표면*. 학생이 *Score 객체 분리*로 *Hand의 점수 책임 이전* + *PersonCards 분리 불필요* 자가 결정. *책임 분리의 정공* = *수평 분리 (Hand + Score)* 가 *수직 분리 (Hand → PersonCards)* 보다 *디미터 안전*. 학습 가시화 모범.
+
+### 16. `Person.cards()` 노출 — *Person 카드 외부 노출*
+
+```kotlin
+abstract class Person {
+    private val hand: Hand = Hand()
+    ...
+    fun cards(): List<Card> = hand.cards
+    fun score(): Score = Score.create(hand.cards)
+}
+```
+
+→ **`Person.cards()` 외부 노출 = *View 호환*** — *OutputView가 받은 카드 출력* 시 필요. 다만 *Person.cards()* 메시지 자체 가 *내부 hand 표현 노출*. *Person.score() / Person.isBlackjack() / Person.isBust()* 메시지가 *분기 미니멈*인 반면 *cards()* 는 *List 데이터 노출*. *View 가 카드 목록을 받음*은 *카드 자체가 노출 가능*. PR #133 (시아 2단계) 의 *EventListener.displayParticipantCards(name, cards)* 와 같은 결.
+
+### 17. `GameResult` 가 *playerPayouts + dealerProfit* 두 필드 노출
+
+```kotlin
+class GameResult(dealer: Dealer, playerBetInfos: List<PlayerBetInfo>) {
+    val playerPayouts: Map<Player, Profit> = ...
+    val dealerProfit: Profit = ...
+}
+```
+
+→ **`GameResult` 가 *플레이어 수익 Map + 딜러 수익* 외부 노출**. *데이터 클래스에 가까움* — *결과 보유 + 외부 조회*. *Tell-Don't-Ask 적용*은 *GameResult.displayTo(view)* 같은 *자기 출력 메시지*. 다만 *View 가 도메인 알면 안 됨* 이라면 *현재처럼 데이터만 노출 + Controller 변환* 도 합리. *데이터 노출 vs 메시지* 의 트레이드오프.
+
+### 18. `runGame()` 의 흐름 = *dealCards → playPlayersTurns → playDealerTurns* 절차적
+
+→ **`runGame()` 의 *3 단계 절차*가 *Controller 절차적 명령*과 정합 vs *도메인 객체의 흐름 자율성* 위배**. *Game.start() / Game.next() / Game.end()* 같은 *상태 머신*이 *도메인 객체 자율성*. 다만 *블랙잭 게임 = 라운드 단위 진행 + 외부 입력 의존*이라 *완전한 자율성 어려움*. *입력 콜백 + 도메인 자율 진행*이 PR #132 (환노) 같은 *고차함수 패턴*. PR #131 은 *명령형 절차*에 머묾.
+
+### 19. 메서드 추출 + private 의 *Controller 의 함수 트리* 형성
+
+```kotlin
+fun play() { ... }
+private fun prepareGame() { ... }
+private fun runGame() { ... }
+private fun finishGame() { ... }
+private fun generatePlayers() { ... }
+private fun dealCards() { ... }
+private fun playPlayersTurns() { ... }
+private fun playDealerTurns() { ... }
+private fun showPersonFinalCardStatus() { ... }
+private fun showGameResult() { ... }
+private fun readPlayerNames() { ... }
+private fun readPlayerBetAmount(name) { ... }
+private fun playPlayerTurns(player) { ... }
+private fun playPlayerTurn(player) { ... }
+private fun isHit(name) { ... }
+private fun <T> retryWhenException(...) { ... }
+```
+
+→ ***15+ 메서드 = 함수 분해 자체는 좋은 면 + Controller god-object 의 자기 표현***. *각 메서드 작아짐* (가독성 ↑). *책임 분배*는 *Controller가 모든 진행 흡수*. *Game 도메인 객체*가 *play(callback)* 같은 *콜백 노출 + 외부 입력 받음* 패턴이면 *Controller의 메서드 수 축소* 가능.
+
+### 20. `Profit(profit)` — *Profit 값 객체 도입 좋은 면 + 정밀도 함정 잔존*
+
+```kotlin
+return Profit(profit)  // profit = Double
+```
+
+→ **Profit 값 객체 도입** = *Double 의 도메인 의미 wrap*. *수익 = Profit (Double)* 명시. *BetAmount × multiplier = Profit* 직접 반환이면 *변환 단계 감소*. *현재 BetAmount × 1.5 = Double + Profit(Double)*. 두 단계.
+
+또한 *Profit 가 Double 표현* — *BigDecimal 권고* (못한 점 §6) 의 연장. 학생이 *NEGATIVE_ZERO_PROFIT 우회*로 *Double 함정* 자가 인식.
+
+## 리뷰어 의견 요지
+
+- **뎁스 깊이 vs 책임 분리 — 수직 분리는 변경 파급 + 디미터 위험** — `Hand → PersonCards` 가 *깊이 분리*. *수평 분리 (Hand + Score)* 가 *디미터 안전 + 변경 격리*.
+- **`BlackjackGame.play()` 하나로 게임 진행** — *Controller 가 도메인 진입점 한 줄* 호출. *현재 BlackJackGame이 InputView/OutputView 의존*이라 *완전 분리 미달*. *Controller가 콜백 주입*이 정공.
+- **기본 생성자 지양 — 빠뜨림 위험** — *생성 시 자동완성 누락 위험*. *영향력이 큰 도메인 (가격 등)* 에서 *심각한 오류 가능성*. *명시적 인자 강제*.
+- **`var state private set` < `protected var state` + `val gameState get()`** — *접근 통제 명료성*.
+- **`isFinal` 단일 사용처** — *enum 부가 속성의 사용처 1개*면 *직접 검사 vs 추상화* 트레이드오프.
+- **Score 객체 분리 = 점수 계산 응집** — *Hand 의 점수 책임 이전*. *수평 분리*.
+- **DIP 자가 학습** — *콜백 → 인터페이스 주입* 으로 *의존성 역전 원칙 학습*.
+
+## 대표 인용
+
+**두루 (뎁스 vs 수평 분리, PersonCards.kt):**
+> 살짝 찜짬한 의문이 들었던 것은 아래와 같은 뎁스 형태로 구현이 되어 있어서 였습니다.
+> `Player -> Hand -> PersonCards`
+> 이렇게 객체간의 뎁스 형태로 되어 있다보면, 추후 요구사항이 변경되거나 뎁스 하단의 구조가 변경이 된다면, 자칫 잘못하면 전체 구조가 바뀔 수 있을 수 있겠다는 생각이 듭니다.
+> 뎁스 구조에서 `점수 계산기 / 카드 관리`이렇게 분리를 해서 최 상단에서 계산을 해보도록 하는 것은 어떤가 라는 생각이 들었어요!💪
+
+**두루 (BlackjackGame.play() 한 줄, BlackJackController.kt:10):**
+> 너무 잘해주셔서, 코멘트 내용이 많지 않을 것 같은데, 시간이 있는 만큼 콜백 형태로도 구현을 해봤으니, 함수의 파라미터로 받아서 처리를 하는 방법도 구현을 해보고 두개를 비교해보는 것 과정에서도 얻을 것이 있을 것 같다는 생각이 듭니다.
+> Controller 에서 `BlackjackGame.play()` 하나로 블랙잭 게임을 할 수 있는 형태로요
+
+**두루 (기본 생성자 지양, Player.kt):**
+> 개인적으로 생성자에 기본 생성자가 있는건 지양을 하는편이긴 합니다.
+> 얼마전에 회사 코드에서 기본생성자를 넣었다가 에러를 발생시켰던 일이 있어서 지양을 하게 되었던 것 같아요
+> 기본 생성자로 되어 있다보면, 개발자가 자칫 잘못해서 생성시에 빠트리는 경우가 있습니다.
+> 영향력이 적거나 없는 경우라면 괜찮겠지만, 예를 들어서 물건의 가격등이라면 아주 큰 문제가 발생할 수 있을 것 같네요🥲
+
+**학생 자가 학습 (DIP 자가 학습, BlackJackGame.kt:14):**
+> 콜백으로 인해 컨트롤러에 중복 코드가 제거되니 코드가 깔끔해진 것 같습니다!
+> 추가로 의존성 역전 원칙(DIP) 개념에 대해 찾아볼 수 있는 기회가 된 것 같습니다!
+
+**학생 자가 답변 (PersonCards → Hand 재합치, PersonCards.kt):**
+> 책임을 분리한 후 각각의 모델은 다음과 같은 책임을 수행하게 되었습니다.
+> - `PersonCards`는 단지 카드를 관리하는 객체로서, 카드 추가나 카드 목록을 조회하는 책임만 집니다.
+> - `Hand`는 `PersonCards`가 제공하는 카드 목록을 사용하여 점수 계산과 같은 역할을 수행합니다.
+> 이 구조로 변경하므로써 두 모델의 하나의 책임을 가지게 되었다고 생각합니다!
+> ...
+> 다시 PersonCards를 제거하고 Hand에서 관리하도록 변경했습니다.
+
+**학생 자가 답변 (Player.changeToStay 의도, Person.kt):**
+> Person을 상속받는 Player에서는 STAY 상태로의 전환을 허용해야 해서 해당 형태로 작성했습니다.
+> 원래는 Person에서 상태를 변경하는 함수를 만들었지만,
+> STAY 상태로 변경하는 기능은 Player에서만 필요했기 때문에 이런 구조가 된 것 같습니다.
+
+## 얻은 교훈
+
+1. ***수평 분리 (`Hand + Score`) > 수직 분리 (`Hand → PersonCards`)***. *수직 분리*는 *디미터 위반 + 변경 파급 ↑*. *수평 분리*는 *각 객체 독립 + 위임 메서드 한 단계*. 학생 자가 학습 모범 — *PersonCards 추출 → 두루 진단 → 다시 합침*. PR #128·#135·#125 와 같은 결의 책임 분리 균형.
+
+2. ***`Ace 11 기본 + repeat(aceCount) { -10 if >21 }` 패턴은 Ace 다수 정확***. *while + 차감* 변형이지만 *aceCount 만큼만 차감 + 21 이하 도달 시 종료* 로 *Ace 3장+ 정확 처리*. PR #128·#135·#114·#125 와 같은 결의 Ace 정공.
+
+3. ***DIP = 콜백 → 인터페이스 주입***. *Controller → BlackJackGame(InputView, OutputView)* 가 *도메인이 인터페이스 의존, 구현체 외부 주입* 패턴. *InputView/OutputView interface = 도메인의 추상화 의존*. *학생 자가 학습 모범*.
+
+4. ***`lateinit var` 안티패턴 잔존 — 호출 순서 invariant***. `lateinit var deck/dealer/playerBetInfos` 가 *prepareGame 호출 전 접근 시 예외*. *play() 진입점 보장*되더라도 *재사용 시 invariant 깨질 위험*. *생성자 인자* 또는 *각 play() 마다 새 인스턴스*가 안전. PR #28·#92·#65·#10·#124·#152 와 같은 결.
+
+5. ***`person is Dealer` 타입 검사 = Person 다형성 부재 신호***. *enum.from(person)* 의 *isDealer && score.isDealerStayScore() -> STAY* 분기는 *Dealer 자기 룰을 enum이 알고 있음*. *Person.stateAfterDraw(): PersonState* abstract method 다형성이 정공. PR #108·#133 (시아) 와 같은 결.
+
+6. ***`protected var` + 자식 직접 변경 = invariant 부재***. *Player.changeToStay() { state = STAY }* 가 *자식이 부모 protected var 직접 변경* — *컴파일러가 잘못된 변경 차단 안 함*. *`var state private set` + protected method (`fun stayed()`)* 가 *접근 통제 강제*.
+
+7. ***Score 객체 도입 = 점수 책임 응집***. *Hand 의 점수 계산을 Score 객체로 이전* 후 *Hand = 카드 관리 + Score = 점수 계산* 책임 분리. *Score private constructor + factory* 가 *불변 + 캡슐화* 정공.
+
+8. ***`Score.isDealerStayScore()` = 딜러 룰 누수***. *Score 가 일반 점수* 인데 *Dealer 룰 (17 이상 STAY) 의식*. *Dealer.canDraw() = score.value <= 16* 같은 *Dealer 안에서 직접*이 자연. *룰 위치 분산*은 *룰 변경 시 여러 곳 수정 필요*.
+
+9. ***BetAmount × multiplier = 원시 타입 vs 도메인 객체***. *BetAmount * 1.5 = Double + Profit(Double)* 가 *2단계 변환*. *BetAmount × multiplier: Profit* 직접 반환이 *도메인 어휘 + 변환 단계 감소*. PR #133 (시아 2단계) 의 *Money* 와 *반대 트레이드오프*.
+
+10. ***Double `-0.0` 우회 = IEEE 754 함정***. *0.0 * -1 = -0.0* 가 *외부 표시 "-0"* 문제. *학생이 명시적 우회 검사*는 좋은 면. *근본 해결 = BigDecimal 또는 Long (cents)*. *금융 도메인 표준 어휘*.
+
+11. ***Controller (BlackJackGame) god-object 변형***. 1단계 *BlackjackController god-object → 2단계 BlackJackGame 이름 변경 + 책임 흡수*. *play/prepareGame/runGame/finishGame/dealCards/playPlayersTurns/...* 15+ 메서드. *Controller = Game.play() 호출자* 분리가 정공.
+
+12. ***기본 생성자 지양 — 영향력 큰 도메인 위험***. *물건 가격 등*에서 *생성 시 빠뜨림 위험*. *명시적 인자 강제*가 *컴파일러 보호*. *Kotlin default value* 는 *편의*이지만 *도메인 invariant 강제 부재*. 학생 자가 반영.
+
+13. ***enum 부가 속성 (`isFinal`)은 단일 사용처 시 직접 검사와 트레이드오프***. *PersonState.isFinal = HIT 만 false* 일 때 *isDrawable() = state == HIT* 와 동등. *enum 멤버에 의미 묶기* vs *분기 직접 표현* 의 가독성 트레이드오프. *둘 다 합리*.
+
+14. ***칭찬 위주 리뷰의 한계 — 학생 자가 학습 기회 풍부 + 깊은 진단 부족***. 두루의 *🥳/👍/💪* 다수 + *"고민해보면 좋을 주제"* 메타 질문 위주. *깊은 안티패턴 진단 < 자가 학습 기회 제공*. *학생 자가 답변 풍부*가 그 보상. PR #128·#135·#124·#152·#133·#136 의 *학생 자가 학습 모범*과 같은 결.
+
+15. ***`var state` 직접 변경 vs `state = state.next()` 메시지***. *PersonState.from(this)* 가 *매 draw 마다 상태 재계산*. *State 객체 다형성 (PR #152·#136)* 은 *next() 메시지 + 다음 상태 객체 반환*. 두 표현의 트레이드오프 — *enum + from* 은 *간단 + 분기 변경 1곳*, *State 객체* 는 *상태별 행동 차이 표현*. *PR #131 은 행동 차이 작음 → enum 합리*.