oh-my-oop 0.2.0

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

@@ -0,0 +1,262 @@
+# PR #114 — [블랙잭 1단계] 다이스 미션
+
+- **Reviewee:** [@moondev03](https://github.com/moondev03)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/114
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 30 (리뷰어 22 / 리뷰이 8)
+
+## 잘한 점 (설계 관점)
+
+- **`PersonState` 인터페이스 + `DealerState`/`PlayerState` enum 분리 — *상태별 다른 룰* 표현** (못한 점 §1 참고).
+- **`GameRule` object에 상수 모음** — `FIRST_TURN_DRAW_AMOUNT`, `BLACKJACK_SCORE`, `ACE_BASE_SCORE`, `ACE_OTHER_SCORE`.
+- **`Card private constructor + Card.create()` 팩토리** + **`Deck.init`에 `52장 invariant` `require()`** — 생성 시 검증.
+- **`Hand` 일급 컬렉션 + 방어적 복사 + `Hand.copy()`** — `Person`이 외부 `Hand`를 받으면 *생성자에서 deep copy*로 격리.
+- **`ScoreCalculator` 분리 (후속에 `object`로 변환)** — 점수 알고리즘 응집.
+- **`GameResult(dealer, players).winStatus: Map<Player, ResultState>`** — *Player → 결과* 단일 자료구조.
+- **테스트 함수 *행위 → 결과* 일부 적용** (`플레이어가 이기는 경우`은 기능 라벨, 후속 리뷰 반영 권고).
+- **후속 반영 — `PersonUiModel` 제거 + View가 모델 직접 사용 + Controller 명명 정리**.
+
+## 못한 점 (설계 관점)
+
+### 1. `DealerState` / `PlayerState` *분리* — Dealer = Person 추상화와 모순
+
+```kotlin
+enum class DealerState(override val isFinal: Boolean) : PersonState {
+    FIRST_TURN(false),
+    HIT(false),
+    BUST(true),
+    BLACKJACK(true),
+    STAY(true),
+    ;
+}
+enum class PlayerState(override val isFinal: Boolean) : PersonState { ... }
+```
+
+리뷰어: "Dealer도 *한명의 플레이어로 보게되었는데, DealerState, PlayerState로 나뉘게 된 이유가 궁금합니다!*" — 둘 다 *동일 상태값*(`FIRST_TURN`/`HIT`/`BUST`/`BLACKJACK`/`STAY`)이라면 *enum 두 개*가 *중복*. `PersonState` 단일 enum 또는 `sealed interface State` (PR #78의 패턴)로 통일. *역할 차이*는 *Hit 가능 조건*(Dealer ≤ 16, Player 사용자 선택)에만 있고, *상태 모델*은 같음.
+
+### 2. `BlackJackController`의 `lateinit var deck`
+
+```kotlin
+class BlackJackController(...) {
+    private lateinit var deck: Deck
+
+    fun play() {
+        val players = generatePlayers()
+        val dealer = Dealer()
+        deck = Deck()                  // 매 play()마다 새 덱
+        ...
+    }
+}
+```
+
+학생 자가 변호: "`play()`가 *다시 호출되는 상황*이라면, 기존 `Deck`이 유지되어 새로운 `Deck`으로 게임을 진행할 수 없다는 문제가 발생할 수 있어 `lateinit`을 사용했습니다. 추가로 코드 가독성 측면에서 *각 함수에 매개변수로 deck을 전달하지 않아도 된다*는 점도 이유 중 하나였던 것 같습니다."
+
+리뷰어: "*Deck 객체를 지연초기화 하신 이유가 궁금합니다*🤔 추가적으로 *여러가지 방법으로 지연초기화*를 할 수 있는데, 각자의 장단점은 어떤 것이 있을까요?" — `lateinit`은 *호출 순서 invariant 없음 = 외부에서 잘못 호출하면 예외*. 진짜 의도는 *play() 단위 새 게임 인스턴스*. `play()`가 *local val deck*로 충분하고, *각 함수에 deck 인자 전달*은 *의존을 가시화*하는 *이점*이지 *단점*이 아님. `lateinit var` + *매개변수 회피*는 *멤버 의존을 숨기는 비용*.
+
+### 3. `Person.score()` — *점수 계산이 Person의 책임인가*
+
+```kotlin
+abstract class Person(
+    hand: Hand,
+    private val calculator: ScoreCalculator = ScoreCalculator(),
+) {
+    protected val hand = hand.copy()
+    ...
+    fun score(): Int = calculator.calculate(cards())
+}
+```
+
+리뷰어: "*점수를 계산하는 것이 과연 Person 객체에 반드시 있어야 할까요?*" — *Hand가 카드 보유 + 점수 계산* 응집이 자연. `Person`은 *Hand 위임자*가 되어야 *Hand 책임*에 일관. `Person.score() = hand.score()`로 *위임* 또는 *Hand.score()*를 직접 호출. *ScoreCalculator 주입*은 *Hand 내부*에 자리.
+
+### 4. `Person.canDraw()` — *플레이어가 그만 받겠다고 하는 표현이 어디로 갔나*
+
+리뷰어: "*플레이어가 내가 몇장을 받았으니 그만 주소!* 라고 한다?는 고민해보면 좋을 것 같다는 생각이 듭니다~" — `Person.canDraw()`는 *Bust/BlackJack/Stay가 아니면 true*. *Stay 선택*은 `player.changeToStay()`로 *외부에서 강제 setter*. *플레이어가 자기 의지로 Stay*를 표현하는 자연 메서드는 *없음*. `player.stand()` 또는 `player.decideHitOrStand(decision)` 등이 *주체적 표현*.
+
+### 5. `Player.changeToStay()` — setter형 메서드
+
+```kotlin
+class Player(val name: String) : Person(Hand()) {
+    fun changeToStay() { gameState = PlayerState.STAY }    // ⚠ 외부에서 상태 강제
+}
+
+// Controller에서
+private fun letPlayerDrawCard(player: Player) {
+    if (inputView.getFlag()) { player.draw(deck); ... }
+    player.changeToStay()                                    // 직접 호출
+}
+```
+
+*상태 setter*가 *공개*. Controller가 *플레이어 상태를 결정*. *Tell-Don't-Ask 변형 위반*. `player.stand()`처럼 *결과 동사*가 자연.
+
+### 6. `Person.getDrawAmount(state: PersonState)` — *상태에 따라 2장 vs 1장* 분기
+
+```kotlin
+protected fun getDrawAmount(state: PersonState): Int {
+    if (gameState == state) {
+        return GameRule.FIRST_TURN_DRAW_AMOUNT      // 2
+    }
+    return GameRule.HIT_DRAW_AMOUNT                  // 1
+}
+```
+
+*FirstTurn = 2장*, *HIT = 1장*. *상태 분기*가 메서드 안에 박힘. PR #135 (ijh1298)의 *Dealer 1장 / Player 2장 공개*와 같은 *비즈니스 룰을 어디 둘 것인가* 결.
+
+### 7. `BlackJackController`가 *턴 관리자 부재*
+
+```kotlin
+fun play() {
+    ...
+    settingInitialCards(dealer, players)
+    processPlayerTurns(players)
+    processDealerTurns(dealer)
+    showGameResult(dealer, players)
+}
+```
+
+리뷰어: "*턴을 지정해주는 객체도 있도록 해볼 수 있겠다는 생각이 드는군요* 딜러의 턴인지, 플레이어의 턴인지 입니다~ 다이스의 생각은 어떠신가요?" — Controller가 *플레이어 → 딜러 순서*를 *직접 진행*. `Turn`/`GameRound` 객체가 *순서 + 종료 조건*을 캡슐화하면 *Controller는 진행자에게 메시지만*.
+
+### 8. `Hand.copy()` 의도 — 방어적 복사용
+
+```kotlin
+class Hand {
+    fun copy(): Hand = Hand().apply { _cards.addAll(this@Hand._cards) }
+}
+
+// Person에서
+abstract class Person(hand: Hand, ...) {
+    protected val hand = hand.copy()        // 외부 Hand 주입 → 격리
+}
+```
+
+리뷰어: "*copy에 대해서 아래와 같이 구현을 하신 이유가 궁금합니다!*" — *외부 Hand 참조 격리*는 의도 좋으나, *Hand 자체가 일급 컬렉션 + 방어적 복사*면 *Hand.copy()*는 *과잉*. *생성자가 빈 Hand*로 시작하면 *외부 참조 없음*. `Hand.copy()`의 *진짜 의도*는 *불변성 모방*인데 *내부 _cards는 여전히 mutable*. *반쪽 보호*.
+
+### 9. `PersonUiModel` Companion — UI 매핑이 UiModel에
+
+```kotlin
+data class PersonUiModel(val name: String?, val cards: List<String>, val score: Int) {
+    companion object {
+        fun create(person: Person): PersonUiModel { ... }
+        private fun Card.toUiString(): String = "${number.toUiString()}${pattern.toUiString()}"
+        private fun CardNumber.toUiString(): String = when (this) { ACE -> "A"; ... }
+        private fun CardPattern.toUiString(): String = when (this) { HEART -> "하트"; ... }
+    }
+}
+```
+
+리뷰어: "*해당 내용이 PersonalUiModel 이 담당해야 하는 기능인지에 대해서 궁금합니다*~" — *UiModel*은 *데이터 holder*가 본업. *UI 매핑(CardNumber → "A")* 은 *OutputView의 책임*. 학생 후속 인정: "*UiModel을 제거하고, View에서 모델 직접 사용*" — 도메인 ↔ View 사이 *번역 레이어*가 *짧은 콘솔 게임에서는 과잉*.
+
+### 10. `Application.kt` — 이름이 *블랙잭 없음*
+
+```kotlin
+fun main() {
+    BlackJackController().play()
+}
+```
+
+리뷰어: "*Application 이라는 네이밍도 좋지만, 블랙잭이라는 네이밍이 드러나게 지어보는 것도 좋을 것 같다는 생각이 듭니다*~" — 프로젝트 단위 파일명에 *도메인 어휘*를. (다만 Kotlin 관례로 `Application.kt`/`Main.kt`도 흔함 — 트레이드오프.)
+
+### 11. `setting` vs `initial` 중복 명명
+
+```kotlin
+private fun settingInitialCards(dealer: Dealer, players: List<Player>) { ... }
+```
+
+리뷰어: "*setting 와 initial 이라는 네이밍이 중복되는 네이밍*이라는 생각이 살짝 드는데, 다이스의 생각은 어떠신가요?" — `setting = initial 설정`이므로 *동어반복*. `distributeInitialCards()` / `dealInitial()` 등 *역할 동사*. 학생 후속 반영.
+
+### 12. `combinePerson(dealer, players): List<PersonUiModel>` — 묶음용 메서드 (후속 제거됨)
+
+리뷰어: "*해당 내용에서 처럼 List로 묶어줘야 하는 이유에 대해서 궁금합니다!*" — *Dealer + Players를 List로 합쳐 View에 전달*. 학생: "*단순히 OutputView에 한 번에 넘겨줄 수 있도록 하기 위해 하나의 List로 묶도록 했었습니다*. 지금은 UiModel을 제거하면서 해당 메서드도 제거되었습니다." — *View에 정렬된 묶음 전달*은 자연이나, *Participants 일급 컬렉션*이 그 역할이 자연.
+
+### 13. `InputView.getNames()` 반환을 *Controller가 Player로 변환*
+
+```kotlin
+private fun generatePlayers(): List<Player> {
+    outputView.printNameMessage()
+    return inputView.getNames().map { Player(it) }
+}
+```
+
+리뷰어: "*inputView 에서 Player를 만들어서 반환을 하는 방법도 있을것 같습니다!* [...] *둘은 어떠한 차이점이 있게 될까요?*🤔" — *InputView가 도메인 객체 생성*하면 *View → Domain 의존* + *InputView 책임 확장*. *Controller에서 String → Player 변환*은 *View 단순화*. 두 방식 모두 합리적인 *트레이드오프*.
+
+### 14. `ScoreCalculator`가 `class` (상태 없음)
+
+```kotlin
+class ScoreCalculator {
+    fun calculate(cards: List<Card>): Int { ... }
+}
+```
+
+리뷰어: "*점수계산기에 대해서 class 키워드를 사용하신 이유가 있을까요?*" — *상태 없음*이면 `object` 또는 *top-level fun*. 학생 후속: `object ScoreCalculator`로 변경. **상태 없는 클래스는 객체가 아님** (STYLE_GUIDE §11).
+
+### 15. `ScoreCalculator.adjustAceValues` — *값 비교*로 ACE 식별
+
+```kotlin
+private fun adjustAceValues(sum: Int, values: List<Int>): Int {
+    var total = sum
+    val aceCount = values.count { it == GameRule.ACE_OTHER_SCORE }    // ⚠ 11 = ACE라고 가정
+    repeat(aceCount) {
+        if (total > GameRule.BLACKJACK_SCORE) total -= GameRule.ACE_BASE_SCORE
+    }
+    return total
+}
+```
+
+학생 자가 인정: "*기존 로직에서는 ACE 카드의 개수를 `ACE_OTHER_SCORE`로 카운트*하고 있어서, 만약 특정 카드의 점수가 `ACE_OTHER_SCORE`와 동일한 점수로 설정된다면 *ACE 카드의 숫자가 잘못 계산되는 문제가 발생*할 수 있다고 생각합니다." — *값으로 식별*하면 *동일 값 카드*(예: 미래에 10점 카드가 11점으로 바뀌면) 충돌. `cards.count { it.number == CardNumber.ACE }`처럼 *타입으로 식별*이 안전.
+
+### 16. 테스트 함수명 — *기능 라벨*
+
+```kotlin
+@Test fun `플레이어가 이기는 경우`() { ... }
+@Test fun `플레이어가 지는 경우`() { ... }
+@Test fun `플레이어가 비기는 경우`() { ... }
+@Test fun `플레이어가 버스트되는 경우`() { ... }
+```
+
+리뷰어: "*어떤 테스트인지 확실하게 알 수 있게 `행위 -> 결과` 형식으로* 네이밍을 정해보는 것도 좋을 것 같다는 생각이 듭니다!" — `플레이어 21점 + 딜러 18점이면 플레이어가 이긴다` 같은 *시나리오 + 결과*가 *입력 조건 명시*. 현재는 *상태 라벨*만.
+
+## 리뷰어 의견 요지
+
+- ***DealerState/PlayerState 분리 = Dealer = Person 추상화와 모순*** — 단일 enum 또는 sealed interface.
+- ***lateinit var은 호출 순서 invariant 없음*** — local val 또는 생성자 주입.
+- ***점수 계산 = Hand 책임***.
+- ***`changeToStay()`보다 `stand()`*** — 결과 동사.
+- ***Controller에 *턴 객체* 도입 가능*** — `Turn`/`Round`.
+- ***`UiModel`이 UI 매핑까지 = 책임 비대*** — OutputView로.
+- ***상태 없는 클래스 → object 또는 top-level fun***.
+- ***ACE를 *값(11)*으로 식별 = 타입 식별이 안전***.
+- ***테스트 함수명 = 시나리오 + 결과***.
+- ***`Hand.copy()` 방어적 복사는 *반쪽 보호*** — `_cards`가 mutable이면.
+
+## 대표 인용
+
+> Dealer도 한명의 플레이어로 보게되었는데, *DealerState, PlayerState로 나뉘게 된 이유*가 궁금합니다!
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/domain/state/DealerState.kt`
+
+> *점수를 계산하는 것이 과연 Person 객체에 반드시 있어야 할까요?*
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/domain/person/Person.kt`
+
+> 플레이어가 *내가 몇장을 받았으니 그만 주소!* 라고 한다?는 고민해보면 좋을 것 같다는 생각이 듭니다~
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/domain/person/Person.kt`
+
+> 턴을 지정해주는 객체도 있도록 해볼 수 있겠다는 생각이 드는군요. 딜러의 턴인지, 플레이어의 턴인지 입니다~
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/controller/BlackJackController.kt`
+
+> 해당 내용이 *PersonalUiModel 이 담당해야 하는 기능*인지에 대해서 궁금합니다~
+> — @Gyuil-Hwnag on `src/main/kotlin/blackjack/uiModel/PersonUiModel.kt`
+
+## 얻은 교훈
+
+- ***`DealerState` + `PlayerState` 분리가 같은 상태값이면 중복*** — `Person`이 추상화면 *상태도 공유*. 차이는 *전이 조건*에만.
+- ***`lateinit var deck`은 호출 순서 invariant 없음*** — *play() 단위 새 게임*이 의도면 *local val* 또는 *생성자 주입*. 매개변수 전달이 *의존 가시화*.
+- ***점수 계산 = Hand 책임*** — `ScoreCalculator` 분리는 가능하나 *Hand 내부 위임* 자연. Person.score() = hand.score().
+- ***`changeToStay()` setter < `stand()` 결과 동사*** — *상태 강제*가 아닌 *행위 표현*.
+- ***Controller가 턴 진행자 = Turn/Round 객체 신호*** — *순서 + 종료 조건*을 캡슐화.
+- ***`Hand.copy()` 방어적 복사는 _cards가 mutable이면 반쪽*** — *진짜 불변*은 `List<Card>` 노출 또는 *원본 자체가 불변*.
+- ***UiModel이 UI 매핑까지 = 책임 비대*** — 데이터 holder가 본업. UI 매핑은 OutputView.
+- ***상태 없는 클래스 = object 또는 top-level fun*** — *new로 인스턴스 매번 생성*은 *상태 없음*의 의도 위반.
+- ***ACE를 *값(11)*으로 식별 = 동일 값 카드 충돌 위험*** — 타입(`CardNumber.ACE`) 식별이 안전 + 의미 명확.
+- ***테스트 함수명 = 시나리오 + 결과*** — *기능 라벨*은 *입력 조건 명시*가 빠짐.
+- ***InputView가 도메인 객체 생성 vs Controller가 변환*** — 두 방식의 트레이드오프 (View 단순화 vs View → Domain 의존).
+- ***`combinePerson` 같은 *조합용 메서드*는 일급 컬렉션 부재 신호*** — `Participants(dealer, players)`가 자연.
+- ***`setting` + `initial` 같은 동어반복 명명*** — *역할 동사 한 단어*.