oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-blackjack/kmkim2689/65-1/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,252 @@
+# PR #65 — [블랙잭 1단계] 케이엠 미션
+
+- **Reviewee:** [@kmkim2689](https://github.com/kmkim2689)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/65
+- **단계:** 1단계 (`study/` DSL 과제 + `blackjack/` 미션 동시 제출)
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 30 (리뷰어 22 / 리뷰이 8)
+
+## 잘한 점 (설계 관점)
+
+- **`Participant` 인터페이스 + `Player`/`Dealer` 구현** — 공통 행위(`drawCard`, `drawUntilSatisfaction`) 추상화.
+- **`fun interface` 스타일 callback (`generateCard: () -> Card`)** — `Player`가 `CardDeck`에 직접 의존하지 않고 *카드 공급자*만 받음. 테스터빌리티 ↑ (lotto의 `non-newable` 패턴 응용).
+- **`PickingState` enum (HIT/STAND)** + `checkBurst()` — *상태 머신*을 enum + 분기로 명시.
+- **`Ace` 동적 처리 — `Card.of(shape, value, currentSum)` 팩토리** — 현재 합 ≤ 10이면 A=11, 초과면 A=1. 카드 생성 시점에 결정.
+- **`GameInfo` 방어적 복사** — `private val _cards: MutableSet<Card>` + `val cards: Set<Card> get() = _cards`.
+- **테스트 함수명 시나리오+결과** — *`카드 총합이 10이하일때 ACE의 값은 11이다`*.
+- **후속 반영 — `Players` 일급 컬렉션으로 검증 이관** — `Dealer`에 있던 `players.distinct() == players.size` 검증을 `Players.init`으로.
+- **후속 반영 — `CardDeck` 재귀 → 미리 만들고 소진** — `MutableList.removeLastOrNull()`.
+
+## 못한 점 (설계 관점)
+
+### 1. `Dealer`가 *플레이어 이름 목록* 검증 — 책임 누수
+
+```kotlin
+class Dealer(
+    val players: List<String>,
+    val gameInfo: GameInfo = GameInfo(NAME_DEALER),
+) : Participant {
+    init {
+        require(players.distinct().size == players.size) { EXCEPTION_DUPLICATED_PLAYERS }
+        require(players.size in PLAYER_NUM_RANGE) { EXCEPTION_NUMBER_OF_PLAYERS.format(players.size) }
+    }
+}
+```
+
+리뷰어: "딜러에 대한 ValidationCheck를 해주셨는데, 과연 딜러에서 플레이어수, 중복 플레이어를 체크 해야하는 것인지 고민해보는 것이 좋을 것 같습니다🤔" — *Dealer가 플레이어 목록을 보유*하는 것 자체가 어색. 후속 반영: `Players(value: List<Player>)` 일급 컬렉션으로 분리 → `Dealer`는 자기 손패만.
+
+### 2. `CardDeck`이 *재귀 + Set 중복 회피* — 종료 불보장
+
+```kotlin
+object CardDeck {
+    private val selectedCards: MutableSet<Card> = mutableSetOf()
+    fun pick(): Card {
+        val shape = Shape.entries.shuffled().first()
+        val cardValue = CardValue.entries.shuffled().first()
+        val card = Card(shape.title, cardValue.title, cardValue.value)
+        return if (isAvailable(card)) card.also { selectedCards.add(card) } else pick()
+    }
+    private fun isAvailable(card: Card): Boolean = card !in selectedCards
+}
+```
+
+리뷰어: "해당 내용은 자칫 잘못해서 같은 숫자 또는 같은 모양이 뽑히면 그만큼 계속 실행될 수도 있겠다는 생각이 듭니다🥲" — *원하는 카드가 나올 때까지 재귀*는 *덱이 거의 다 소진된 상태에서 무한 재귀 위험*. 후속 반영: *셔플 후 stack에서 pop*.
+
+### 3. `Card.shape`/`title`이 `String` — 도메인 원시값 부재
+
+```kotlin
+data class Card(
+    val shape: String,
+    val title: String,
+    val value: Int,
+)
+```
+
+리뷰어: "해당 내용을 String으로 받은 이유가 있을까요??🤔" — `Shape` enum, `CardValue` enum이 있음에도 `Card`는 *문자열*. *enum의 title(한글) 문자열*을 `Card`로 전달 = *UI 표현이 도메인의 식별자*가 됨. PR #78과 유사한 *도메인-UI 결합* 변형.
+
+### 4. `CardDeck` Singleton (`object`) + 전역 변경 가능 상태
+
+```kotlin
+object CardDeck {
+    private val selectedCards: MutableSet<Card> = mutableSetOf()
+    // 매 테스트 격리를 위해 어딘가에서 초기화 필요
+}
+```
+
+PR #78과 동일한 *전역 변경 가능 상태* 패턴. 테스트마다 *덱 상태가 누적*되어 격리가 깨짐. 후속 반영도 `object`는 유지 — *근본 해결은 `class Deck`*.
+
+### 5. `Controller`가 `runCatching + 재귀` + `?:` 중첩
+
+```kotlin
+private fun getPlayerNames(): List<String> {
+    return runCatching {
+        InputView.readPlayerNames() ?: getPlayerNames()
+    }.onFailure {
+        println(it.message)
+        return getPlayerNames()
+    }.getOrThrow()
+}
+```
+
+`runCatching` 안의 `?: getPlayerNames()`(elvis 재귀) + `onFailure`에서 또 `return getPlayerNames()` + `getOrThrow()` — *세 가지 분기*가 *같은 일*(재시도)을 함. 리뷰어: "callback + Kotlin Extensions 를 잘 사용해주셨네요~ 해당 함수의 네이밍만을 보고 어떤 기능을 하는 것인지 유추가 잘 안될 수도 있겠다는 생각도 듭니다!🤔 추가적으로 callback 사용해주신 것은 좋으나 자칫 callback을 사용함으로서 가독성이 안좋아질 수도 있으니 해당 내용을 고민해보시는 것도 좋을 것 같습니다💪" — *Kotlin 기능 과시*가 *읽기 비용 ↑*.
+
+### 6. `InputView.readPlayerNames(): List<String>?` nullable 반환
+
+```kotlin
+fun readPlayerNames(): List<String>? {
+    println(MESSAGE_INPUT_PARTICIPANT_NAMES)
+    return readln().split(DELIMITER_NAMES).map { name ->
+        name.trim().ifEmpty { return null }
+    }
+}
+```
+
+리뷰어: "혹시 해당 내용의 리턴타입을 nullable 하도록 지정하신 이유가 있을까요??" — 빈 문자열을 *null로 표현*하는 결정의 *근거 부재*. 호출자에서 `?:` 재귀 호출로 *상호 결합*. *예외 vs null vs 재입력 루프*의 *의도*가 분산.
+
+### 7. `BlackJackController`의 callback 폭증 — `(GameInfo) -> Unit` 등
+
+```kotlin
+private fun playRound(players: List<Player>, dealer: Dealer) {
+    with(OutputView) {
+        players.forEach { player ->
+            player.drawForSingleParticipant(::printSinglePlayerCards)
+        }
+        printNewLine()
+        dealer.drawForSingleParticipant(::printDealerHit)
+    }
+}
+
+private fun Participant.drawForSingleParticipant(printCards: (GameInfo) -> Unit) {
+    drawUntilSatisfaction(CardDeck::pick, printCards)
+}
+```
+
+도메인이 *View 함수 reference*를 받아 *내부에서 호출*. *Tell-Don't-Ask*처럼 보이지만 실은 *도메인이 View를 호출*하는 의존 역전. *Print*를 매번 *Player 안*에서 하면 *Player의 책임 = 카드 받기 + 화면 출력*. 화면 출력은 Controller가 *결과 받아서* 호출해야 자연.
+
+### 8. `GameInfo.total` 모호한 이름
+
+```kotlin
+val total: Int   // 점수? 카드 수? 합계?
+    get() = ...
+```
+
+리뷰어: "점수인 것 같은데, total 이라는 네이밍을 보고 과연 그 내용이 유추될지는 잘 모르겠습니다🥲" — `score`, `handScore`, `totalScore` 같은 *의미 명시*.
+
+### 9. `Judge`가 *결과 판단자* — Tell-Don't-Ask 위반 변형
+
+```kotlin
+class Judge(
+    private val dealerInfo: GameInfo,
+    private val playersInfo: List<GameInfo>,
+) { ... }
+```
+
+리뷰어: "게임 결과를 판단한다는 의미에서 Judge라는 네이밍을 좋으나, 좀더 직관적으로 알 수 있는 네이밍을 고민해보시는 것도 좋을 것 같습니다👍" — *Judge*는 PR #63의 *심판* 토론과 동일 결. *상대 무관 비교*라면 `Participant.compete(other)`가 자연. *Judge 객체*는 *데이터를 빼앗긴 객체*가 될 위험.
+
+### 10. `Player`의 `init` 누락 + `Player(gameInfo, onInputDecision)`
+
+```kotlin
+class Player(
+    val gameInfo: GameInfo,
+    val onInputDecision: () -> String,
+) : Participant {
+    fun initializeCards(generateCard: () -> Card) {
+        repeat(INITIAL_DRAW_COUNT) { gameInfo.addCard(generateCard()) }
+    }
+}
+```
+
+리뷰어: "인스턴스를 생성하면서 호출을 하는데 init{} 블록등을 활용할 수도 있겠다는 생각이 듭니다!" — `initializeCards`를 *외부에서 명시 호출* = *생성자 호출 후에도 invariant 미충족*인 상태가 존재. *2장 손패 보유*가 invariant라면 `init`이나 생성자 매개변수로.
+
+### 11. `Player.drawCard` 자체가 `onInputDecision` 호출 — UI 응답이 도메인 메서드 안에
+
+```kotlin
+override fun drawCard(generateCard: () -> Card): PickingState {
+    val pickingState =
+        PickingState.entries.find { it.value == onInputDecision() }
+            ?: throw IllegalArgumentException(EXCEPTION_PLAYER_INPUT)
+    return when (pickingState) {
+        PickingState.HIT -> { gameInfo.addCard(generateCard()); checkBurst() }
+        PickingState.STAND -> PickingState.STAND
+    }
+}
+```
+
+`drawCard()`가 *UI 입력 callback 호출 + 카드 추가 + 상태 결정* 세 일을 한 번에. 의도는 *Tell-Don't-Ask + DI*지만 실제로는 *Player가 자기 결정을 외부에 묻고* + *카드 공급도 외부에 묻고* + *결과 enum 변환*까지 한다. 함수명(`drawCard`) ↔ 동작(*묻고 받고 처리*) 불일치.
+
+### 12. `Player.drawUntilSatisfaction` 재귀 — Stack 위험 + 흐름 분산
+
+```kotlin
+override fun drawUntilSatisfaction(generateCard: () -> Card, printCards: (GameInfo) -> Unit) {
+    val pickingState = drawCard { generateCard() }
+    printCards(gameInfo)
+    when (pickingState) {
+        PickingState.HIT -> drawUntilSatisfaction(generateCard, printCards)
+        PickingState.STAND -> return
+    }
+}
+```
+
+*반복*을 *재귀*로. Stack overflow는 실제 게임에선 거의 없으나 *루프 vs 재귀*의 *선택 근거*가 *형식*(꼬리재귀 흉내)일 뿐. (이는 racingcar의 *re4rk-pattern* 비판과 동일 결.)
+
+### 13. `Participant` 인터페이스명 모호
+
+```kotlin
+interface Participant {
+    fun drawCard(generateCard: () -> Card): PickingState
+    fun drawUntilSatisfaction(generateCard: () -> Card, printCards: (GameInfo) -> Unit)
+}
+```
+
+리뷰어: "프로젝트 규모가 커지면 네이밍만 보면 어떤 것을 만족한다는 것인지 의미가 명확하지 않을 수도 있겠다는 생각이 듭니다!" — `Satisfaction`이 *무엇의 만족*인지 모호. `drawWhileWilling` 같은 *결정 기준 명시*가 자연.
+
+### 14. `Dealer(playerNames)` — *딜러가 플레이어 이름을 안고 시작*
+
+```kotlin
+val dealer = Dealer(playerNames)
+```
+
+도메인 비유로 *카드를 나눠주는 진행자*가 *플레이어 목록을 안다*는 건 자연스럽지만, *플레이어 검증*까지 떠안으면서 책임이 비대. PR #125 (jerry8282)의 자가 의문(*카드를 나누어주는 진행자가 누구인가*)과 같은 결의 *Dealer 책임 비대*.
+
+## 리뷰어 의견 요지
+
+- **`Dealer`에 플레이어 검증을 박지 말 것** — `Players` 일급 컬렉션이 invariant 보유.
+- **`CardDeck` 재귀로 중복 회피 위험** — 셔플 + pop 패턴.
+- **`Card.shape: String` 보다 도메인 enum 직접 보유** — 원시값 포장.
+- **`runCatching + ?: 재귀 + onFailure 재귀`** — 같은 동작을 *세 분기*가 함. 의도 분산.
+- **`InputView` nullable 반환의 근거** — *예외 vs null vs 루프* 일관성.
+- **`Participant.drawCard`가 *입력 + 카드 + 상태*를 한 번에** — 책임 비대.
+- **`init`으로 *초기 손패* invariant 보호** — 외부 명시 호출 금지.
+- **callback 폭증은 *기능 과시* 위험** — 가독성 우선.
+- **`Judge` / `total` 같은 *모호명*** — 결과 동사 + 의미 명시.
+
+## 대표 인용
+
+> 해당 내용은 자칫 잘못해서 같은 숫자 또는 같은 모양이 뽑히면 그만큼 계속 실행될 수도 있겠다는 생각이 듭니다🥲
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/model/CardDeck.kt`
+
+> 딜러에 대한 ValidationCheck를 해주셨는데, 과연 딜러에서 플레이어수, 중복 플레이어를 체크 해야하는 것인지 고민해보는 것이 좋을 것 같습니다🤔
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/model/Dealer.kt`
+
+> callback 사용해주신 것은 좋으나 자칫 callback을 사용함으로서 가독성이 안좋아질 수도 있으니 해당 내용을 고민해보시는 것도 좋을 것 같습니다💪
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/controller/BlackJackController.kt`
+
+> 해당 내용을 String으로 받은 이유가 있을까요??🤔
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/model/Card.kt`
+
+> 인스턴스를 생성하면서 호출을 하는데 init{} 블록등을 활용할 수도 있겠다는 생각이 듭니다!
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/model/Player.kt`
+
+## 얻은 교훈
+
+- **Dealer는 자기 손패만, 플레이어 검증은 `Players` 일급 컬렉션** — 도메인 비유에 끌려 *플레이어 목록을 Dealer가 검증*하면 책임 비대.
+- **`CardDeck` 자료구조 = 셔플 + pop** — 재귀 + Set 중복 회피는 *덱이 거의 빈 상태*에서 무한 재귀 위험. `MutableList`+`removeLastOrNull()`이 자연.
+- **`Card.shape: String` 금지 — enum 직접 보유** — *enum.title* 같은 *UI 표현 문자열*을 식별자로 쓰면 *UI 변경이 도메인 변경*.
+- **`object CardDeck` Singleton은 *전역 변경 가능 상태*** — 매 게임 새 덱 인스턴스가 자연. `object`는 *상태 없음*일 때만.
+- **`runCatching + ?: 재귀 + onFailure 재귀`는 *같은 일을 세 분기*가 함** — Kotlin 기능 과시. *예외 → 재시도*면 *try-catch + while* 한 가지 패턴으로.
+- **InputView가 *nullable 반환*하면 *예외 vs null vs 루프* 의도가 분산** — *재시도 루프*가 InputView 책임이면 *non-null*만 반환.
+- **`Player.drawCard`가 입력 callback + 카드 callback + 상태 결정 = 세 책임** — 함수명과 동작 불일치. *상태 결정*은 `addCard`의 후처리로 자연.
+- **`init`으로 *초기 손패 2장* invariant 보호** — `initializeCards`를 외부에서 명시 호출하면 *생성 직후 invariant 미충족*.
+- **callback이 *도메인 → View*면 의존 역전** — `printCards: (GameInfo) -> Unit`을 *Player 안*에서 호출하면 도메인이 View를 안다.
+- **`total` / `Judge` / `Satisfaction` 같은 *추상 명사* 회피** — `score`, `compete`, `willingness` 등 *행위/결과*를 표현하는 어휘.
+- **`fun interface` 또는 `() -> Card` callback은 *비결정성 분리*에 좋음** — `Player`가 `CardDeck`에 직접 의존하지 않고 *카드 공급자*만 받는 것은 lotto의 `non-newable` 패턴과 동일 결.