oh-my-oop 0.2.0

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

@@ -0,0 +1,251 @@
+# PR #119 — [블랙잭 1단계] 미플 미션
+
+- **Reviewee:** [@HamBeomJoon](https://github.com/HamBeomJoon)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/119
+- **단계:** 1단계
+- **리뷰어:** @lee-ji-hoon (코니)
+- **라인 코멘트:** 30 (리뷰어 18 / 리뷰이 12)
+
+## 잘한 점 (설계 관점)
+
+- **`abstract class Person` + `Dealer`/`Player`** — 후속에 *Person → name 공통* 권고 반영.
+- **`@BeforeEach setUp` test fixture 활용** — 격리.
+- **`DrawChoice` enum 도입 + InputView에서 매핑** — UI 형식 분리 (후속에 *InputView가 모델 생성*은 회피).
+- **후속 반영 — `addCard`만 남기고 `addCards` 제거 + Deck class 전환 + ResultCalculator 객체 분리 + Number → `BUST_NUMBER`/`ACE_EXTRA` 비즈니스 로직 분리 + `name`을 Person으로 이동**.
+- **학생 자가 토론 깊이 — *View가 Model을 생성해도 되나* 의문 → 자가 답변: *의존과 생성은 다르다***.
+
+## 못한 점 (설계 관점)
+
+### 1. `Number` enum 명명 — Kotlin stdlib `Number`와 충돌
+
+```kotlin
+enum class Number(val value: String, val score: Int) {
+    ACE("A", 11), TWO("2", 2), ..., KING("K", 10);
+}
+```
+
+리뷰어: "*Kotlin에서 이미 Number라는 좋은 네이밍은 이미 먹어둔 상태이니 이 Number가 '어떠한 Number' 인지를 명확히 표현*해주는 것이 좋을 것 같네요." — **표준 라이브러리 충돌**. `Rank`/`CardNumber`/`Denomination` 같은 *도메인 특정 어휘*. **stdlib 어휘를 모르고 식별자 충돌 = 학생 점진 학습 단계**.
+
+### 2. `Number.value: String` UI 표현 보유
+
+```kotlin
+enum class Number(val value: String, val score: Int) { ACE("A", 11), ... }
+```
+
+리뷰어: "*View에 표현하기 위해서 value가 생긴 것 같은데요.* 그러면 만약 *J를 이미지로 교체한다고 했을 때 해당 모델의 변경이 생길텐데 이런 변경사항이 생기는게 맞을지 MVC 관점에서 고민*해봅시다." — **enum UI value 10개 PR 연속 (Suit/Verdict/word/koreanText/value/description 등)**.
+
+### 3. `Number.ACE.score = 11` 기본값 — 룰 표현 불일치
+
+```kotlin
+ACE("A", 11)
+```
+
+리뷰어: "*블랙잭에서 `ACE` 는 기본적으로 `1`을 의미합니다. 특이한 케이스에서 `+10` 을 하는 것입니다.* 즉 *+10이 되는 상황은 비즈니스 로직으로 녹여낼 수 있고 테스트를 해야 한다.*" — PR #29·#112와 동일. *Ace 기본 1 + 11 검토는 단일 룰*. *11 기본 + 보정*은 *알고리즘 편의*가 *도메인 어휘 왜곡*.
+
+### 4. `ResultType` enum이 *Bust 상수 + 승부 계산 + 결과* 셋
+
+```kotlin
+enum class ResultType(val value: Char) {
+    WIN('승'), TIE('무'), LOSS('패');
+    companion object {
+        fun judgeScore(dealer: Dealer, player: Player): ResultType { ... }
+        const val BUST_NUMBER = 21
+    }
+}
+```
+
+리뷰어: "*`ResultType` 이라는 객체를 봤을 때 `결과` 에 집중을 하고 있는데 여기서 `BUST_NUMBER` 도 갖고 있고 승부 결과까지 만들고 있네요.* 블랙잭이라는 도메인으로 생각했을 때, *블랙잭은 플레이어와 딜러간의 대결*일텐데요." — **enum이 *결과 타입 + 도메인 상수 + 비교 알고리즘* 셋** = 책임 비대. *결과 타입*만 (enum), *Bust 상수*는 `Card`/`Hand`/`Game`, *비교*는 *참가자 메서드*. PR #29·#125·#128·#92와 같은 결.
+
+### 5. `ResultType.judgeScore(dealer: Dealer, player: Player): ResultType` — 정적 비교자
+
+```kotlin
+fun judgeScore(dealer: Dealer, player: Player): ResultType {
+    val dealerFinalScore = if (dealer.isBust()) 0 else dealer.calculateTotalScore()
+    val playerFinalScore = if (player.isBust()) 0 else player.calculateTotalScore()
+    if (dealerFinalScore < playerFinalScore) return WIN
+    if (dealerFinalScore == playerFinalScore) return TIE
+    return LOSS
+}
+```
+
+→ PR #10·#28·#125·#28·#33·#24·#116·#92·#63과 같은 **상대 무관 비교 = 참가자 메시지** 권고. `participant.match(other)`. 또: *Bust 시 점수를 0으로 표시*하는 트릭은 *비교 로직을 단순화하는 패치*. *Bust 처리는 별도 분기*가 자연.
+
+### 6. `ResultType.judgeScore` 룰 누락 — *모두 Bust 시 어떻게*
+
+```kotlin
+val dealerFinalScore = if (dealer.isBust()) 0 else dealer.calculateTotalScore()
+val playerFinalScore = if (player.isBust()) 0 else player.calculateTotalScore()
+if (dealerFinalScore < playerFinalScore) return WIN
+if (dealerFinalScore == playerFinalScore) return TIE
+return LOSS
+```
+
+리뷰어: "*제가 슬랙에 올린 블랙잭 위키의 내용인데요. 지금은 아래와 같은 경우에 어떻게 될까요?* 1. *플레이어1이 버스트가 된다.* 2. *플레이어2가 버스트가 된다.* ..." — **둘 다 Bust = `0 == 0 = TIE`**가 학생 코드의 결과. 그러나 룰은 *둘 다 Bust = 플레이어 패배*. PR #116과 동일한 *블랙잭 룰 오해*.
+
+### 7. `Person.cards: open val` 외부 공개
+
+```kotlin
+abstract class Person {
+    private val _cards: MutableList<Card> = mutableListOf()
+    open val cards get() = _cards.toList()
+    ...
+}
+```
+
+리뷰어: "*이 값이 open 되어야 할 필요가 있을까요?* 그리고 *외부로 공개 되어 있는 이유는 지금 이 객체에게 메세지를 던지지 않고 있는 상황이 아닌지 생각*해 봅시다." — **`open val` = 자식이 override + 외부 공개**. *override 필요 없으면 `final`*. *외부 공개 = 호출자가 cards를 직접 보고 분석* = *객체에 메시지 X*. Tell-Don't-Ask. PR #33·#28·#65·#114·#92·#10과 같은 결.
+
+### 8. `Person.addCard` + `addCards` 공존
+
+```kotlin
+fun addCard(card: Card) = _cards.add(card)
+fun addCards(cards: List<Card>) = _cards.addAll(cards)
+```
+
+리뷰어: "*`abstract` 으로 만들었는데 `addCard` `addCards` 이 2개 정말 공존해야 할까요?* *사람 입장에서는 한 장씩 받는 것이지 않을까요?*"
+
+학생 자가 인정: "*addCard만 남겼습니다!*" — **호출자 편의를 위한 메서드 폭증**. `addCards`는 `cards.forEach { addCard(it) }`로 호출자가 표현. *Person.addCard(card)*가 *현실 사람의 카드 받기*에 일치.
+
+### 9. `Person` 추상에 *name 미포함*
+
+```kotlin
+abstract class Person { ... }
+class Dealer : Person() { val name = DEALER_NAME }
+class Player(val name: String) : Person() { ... }
+```
+
+리뷰어: "*사람으로 따지면 "이름" 도 공통이 될 수 있지 않을까요?*" — `Person`의 공통 속성. `abstract val name: String` 또는 `Person(val name: String)` 추상 생성자.
+
+학생 자가 인정: "*Person에 추가 했습니다!*" — 후속 반영.
+
+### 10. `Dealer.companion object` 위치 규약 위반
+
+리뷰어: "*`companion object` 는 어디에 위치를 해야 하는가. 를 확인해보시면 좋을 것 같네요.* https://kotlinlang.org/docs/coding-conventions.html#class-layout" — Kotlin Class layout: `companion object`는 *모든 멤버 마지막에*.
+
+### 11. `Deck` Singleton + *카드 소진 테스트* 부작용
+
+```kotlin
+object Deck { /* 52장 static state */ }
+
+// 테스트
+@Test fun `52장 모두 뽑은 후 예외`() { repeat(53) { Deck.draw() } }    // ⚠ 이 테스트가 다른 테스트의 Deck 상태를 망가뜨림
+```
+
+학생 자가 의문 (PR 본문): "*Deck을 Object로 만들어 싱글턴으로 만들었는데, 테스트에서 Deck의 카드를 모두 뽑았을 때 예외처리를 테스트하면서 카드를 52장 드로우하니 다른 테스트에서 Deck의 카드를 뽑을 때 에러가 발생*했습니다. (coverage 테스트로 실행했을 때) 실제로 프로그램을 실행했을 경우는 *이런 경우가 발생하지 않는데, 이런 테스트 때문에 object를 다시 class로 변경해야 하는지, 카드를 모두 뽑았을 때 예외처리하는 테스트를 제거해야 하는지 궁금*합니다!"
+
+리뷰어: "*테스트 때문에 object -> class로 변경을 한다. 이 관점에서 봤을 때 2가지 측면이 있습니다.* 1. *잘못된 테스트이다.* 2. *object로 구현하면 안 된다.* [...] *근데 지금 만약 게임이 1판이 아니고 2판 3판 이뤄진다* 위 경우를 생각 해보면 *이 테스트가 필요했을지 아닐지 직접 판단*하실 수 있을 것이라고 생각합니다."
+
+→ **테스트가 코드 결함을 드러냄 = 코드 결함이 진짜 문제**. *Singleton Deck*은 *2판 이상에서 카드 소진* 시 *재시작 불가*. *테스트가 의미 있는 것*. PR #65·#79·#125·#92·#33과 같은 *Singleton Deck* 안티패턴.
+
+### 12. `BlackjackController.playerDrawOrStay` 재귀 + 다중 return
+
+```kotlin
+private fun playerDrawOrStay(player: Player) {
+    val condition: DrawChoice = inputView.readMoreCardCondition(player)
+    if (condition.isStay()) {
+        outputView.printPlayerHands(player)
+        return
+    }
+    gameManager.drawCard(player)
+    outputView.printPlayerHands(player)
+    if (player.isBust()) return
+    playerDrawOrStay(player)   // 재귀
+}
+```
+
+리뷰어: "*이 함수가 단순 플레이어가 draw 하거나 stay를 하겠구나 하고 봤는데요 지금 너무 어렵게 구현이 되어있는 것 같아요.* return을 2개나 하고 있고 *재귀로 호출이 되게끔 만들었는데요*. ```while과 when문을 적절하게 섞으면 지금 어떠한 상태 일 때 player의 턴을 종료한다.``` 라는 것을 *조금 더 명시적으로 나타낼 수 있을 것 같습니다.*"
+
+학생 자가 토론: "*when을 통해 사용자 choice가 yes, no 일때에 따라 처리하도록 변경했습니다. 뭔가 예외처리도 해야하고 while(true)가 어색한데 이렇게 하는 것이 괜찮을까요?!*" — **재귀로 표현된 의도** = *Stay이면 중단 + Hit이면 카드 + 반복*. `while (player.canDraw() && readMoreCardCondition(player).isHit())` 형태가 *상태 머신을 표현*.
+
+### 13. `InputView`가 *`List<Player>` 반환* — Player 생성
+
+```kotlin
+class InputView {
+    fun readPlayerNames(): List<Player> { ... }
+}
+```
+
+리뷰어: "*MVC 관점에서 View가 Model을 만드는 것이 크게 문제가 없을까요?* 미플의 생각이 궁금하네요!"
+
+학생 자가 토론: "처음에는 view와 model을 *아예 독립적으로 분리하는 것이 맞다 생각*했는데, 저번 미션을 하면서 *inputView는 모델에 의존하지 않으려고 노력을 했는데 outputView는 모델을 많이 쓰고 있어서 '아 아예 독립적으로 짤 수는 없을 것 같다'고 생각해 inputView도 모델에 의존할 수 있게 짰습니다.* 하지만, 이번 코니의 리뷰를 보고 *용어를 제가 오해하고 있었던 것 같습니다. 단순히 모델에 '의존'해서 사용하는 것과 이렇게 모델을 '생성'하는 것을 저는 같다고 생각해 아무생각 없이 생성한 것 같습니다.* 처음 제 생각과 마찬가지로 *view는 모델을 의존하는 것은 되지만, 객체 생성 등은 하면 안된다고 생각*합니다."
+
+리뷰어 답변 (MVC 다이어그램 첨부): "*위 그림을 보면 Model의 update를 view에게 알려주고 있기에 의존은 어쩔 수 없다고 생각을 합니다.*" — **의존 ≠ 생성 = 학생 자가 도달한 결론**. *View가 Model을 의존*은 *MVC 정상*, *View가 Model을 생성*은 *책임 누수*.
+
+### 14. `Shape` enum도 *UI value*
+
+```kotlin
+enum class Shape(val type: String) { ... }
+```
+
+리뷰어 후속: "*사용을 안하게 변경만 되었을 뿐 실제로는 아직 남아있습니다... 🫠*" — **학생이 *사용처만 변경*하고 *enum 필드 자체*는 남김**. 후속 반영 *반쪽*. *진정한 변경은 필드 제거*.
+
+### 15. `PersonTest`의 *setUp에서 항상 Bust 상태 초기화*
+
+```kotlin
+class PersonTest {
+    @BeforeEach fun setUp() {
+        person.addCard(Card(Number.JACK, Shape.HEART))
+        person.addCard(Card(Number.JACK, Shape.HEART))
+        person.addCard(Card(Number.JACK, Shape.HEART))   // ⚠ Bust 상태로 시작
+    }
+}
+```
+
+리뷰어: "*setUp에서 항상 bust가 true이 상태로 초기화를 해둘 경우 나중에 다른 테스트를 할 때 문제가 없을까요?*" / "*그리고 Person이라는 객체*"
+
+→ **setUp의 fixture가 너무 *특정 시나리오*면 *다른 시나리오 테스트 시 변경 필요***. *공통 setup*은 *최소 invariant*만, *시나리오별 추가 카드*는 *각 테스트*에서.
+
+또 *PersonTest의 의도 불명*: "*이 테스트는 어떤 상황을 테스트 하기 위함일까요? 테스트에서 어떠한 의도를 갖고 만드신 것인지 궁금*하네요" — *Person*은 추상. *PersonTest*는 *추상 클래스 자체 검증*인지 *Player/Dealer 공통 행위 검증*인지 모호.
+
+### 16. `View가 어떤 화면을 보여줄지 판단 = 도메인 책임 X`
+
+리뷰어 후속 (학생이 *ResultType.value 제거 후 View에서 매핑*): "*네 좋습니다. 어떠한 상태에 따라서 어떤 화면을 보여줄지는 View가 충분히 판단을 해도 된다 라고 생각을 하기에 남겼던 리뷰이기에 잘 반영해주셨습니다*" — **View가 *결과 상태 → 표현 매핑*은 정상**. *도메인이 결과 상태만 전달 + View가 표현 결정*이 MVC 분리의 정수.
+
+## 리뷰어 의견 요지
+
+- ***`Number` stdlib 충돌 = 도메인 어휘 부족***.
+- ***Ace 기본 1 + 11 검토는 비즈니스 로직 + 테스트 가능***.
+- ***`ResultType` enum 책임 비대 = 결과 타입 + 상수 + 비교 알고리즘***.
+- ***`open val cards` 외부 공개 = Tell-Don't-Ask 위반***.
+- ***`addCard` + `addCards` 공존 = 호출자 편의 메서드 폭증***.
+- ***Person 추상에 name 공통 누락***.
+- ***Singleton Deck 테스트 + 2판 이상 = 코드 결함을 테스트가 드러냄***.
+- ***재귀 + 다중 return < while + when 상태 머신***.
+- ***InputView가 Model 생성 = View 책임 누수*** — *의존 ≠ 생성* 학생 자가 도달.
+- ***UI enum value 필드 제거 반쪽 = 진정한 변경은 필드 자체 제거***.
+- ***setUp이 특정 시나리오 = 다른 시나리오 테스트 불가***.
+- ***View가 결과 상태 → 표현 매핑은 정상***.
+
+## 대표 인용
+
+> 만약 J를 이미지로 교체한다고 했을 때 *해당 모델의 변경이 생길텐데 이런 변경사항이 생기는게 맞을지 MVC 관점에서 고민*해봅시다.
+> — @lee-ji-hoon on `Number.kt`
+
+> `ResultType` 이라는 객체를 봤을 때 *결과* 에 집중을 하고 있는데 여기서 *`BUST_NUMBER` 도 갖고 있고 승부 결과까지 만들고 있네요.*
+> — @lee-ji-hoon on `ResultType.kt`
+
+> MVC 관점에서 *View가 Model을 만드는 것이 크게 문제가 없을까요?* 미플의 생각이 궁금하네요!
+> — @lee-ji-hoon on `InputView.kt`
+
+> 테스트 때문에 object -> class로 변경을 한다. 이 관점에서 봤을 때 2가지 측면이 있습니다. *1. 잘못된 테스트이다. 2. object로 구현하면 안 된다.* [...] 만약 게임이 *1판이 아니고 2판 3판 이뤄진다* 위 경우를 생각 해보면 *이 테스트가 필요했을지 아닐지 직접 판단*하실 수 있을 것이라고 생각합니다.
+> — @lee-ji-hoon on `DeckTest.kt`
+
+> 블랙잭에서 `ACE` 는 *기본적으로 `1`을 의미*합니다. 특이한 케이스에서 `+10` 을 하는 것입니다. 즉 *+10이 되는 상황은 비즈니스 로직으로 녹여낼 수 있고 테스트를 해야 한다.*
+> — @lee-ji-hoon on `Number.kt`
+
+## 얻은 교훈
+
+- ***stdlib 어휘 충돌 = 도메인 어휘 부족 신호*** — `Number` → `Rank`/`CardNumber`. *학생 점진 학습 단계*에서 표준 라이브러리 어휘 학습.
+- ***enum UI value (10개 PR 연속 등장 안티패턴)*** — `value: String/Char`로 *표현*을 가지면 *디자인 변경 = 도메인 변경*.
+- ***Ace 기본 1 + 11 검토 단일 룰*** — *11 기본 + 보정*은 알고리즘 편의가 도메인 어휘 왜곡.
+- ***enum 책임 비대 = 결과 타입에 상수 + 비교 알고리즘 흡수*** — `BUST_NUMBER`는 `Card`/`Hand`, *비교*는 `Participant.match`.
+- ***상대 무관 비교 = 참가자 메시지*** — *정적 비교자 (`judgeScore(dealer, player)`)*는 *11개 PR 연속 등장하는 권고*.
+- ***둘 다 Bust = 0 == 0 = TIE 트릭은 블랙잭 룰 위반*** — *둘 다 Bust = 플레이어 패배*. PR #116과 같은 결.
+- ***`open val cards` 외부 공개 = Tell-Don't-Ask 위반*** — *override 불필요 + 외부 공개 불필요*면 `private val _cards` + 메시지.
+- ***`addCard` + `addCards` 공존 = 호출자 편의 폭증*** — 단일 단위 메서드 + 호출자가 forEach.
+- ***Person 추상에 name 공통은 자연*** — *공통 속성*은 *추상에*.
+- ***Singleton Deck + 2판 이상 = 카드 소진 후 재시작 불가 = 코드 결함*** — *테스트가 결함을 드러냄*. 학생 자가 *테스트 vs 코드* 의문 → 리뷰어가 *2가지 측면 (잘못된 테스트 vs object 잘못)* + *2판 이상* 시나리오로 답.
+- ***재귀 + 다중 return = 상태 머신 흐릿함*** — `while + when`이 *종료 조건 명시*. PR #29·#10과 같은 결.
+- ***InputView가 Model 생성 = 책임 누수 (의존 ≠ 생성)*** — *MVC에서 View가 Model 의존*은 정상, *생성*은 책임 분리 위반. 학생 자가 도달.
+- ***UI enum value 제거 반쪽 = 필드 자체 제거 필요*** — *사용처만 변경*은 *필드는 살아있음*. 진정한 변경은 *데이터 모델*에서.
+- ***setUp 특정 시나리오 = 다른 시나리오 테스트 불가*** — *공통 setup은 최소 invariant*. 시나리오별 변형은 각 테스트.
+- ***View가 결과 → 표현 매핑은 정상*** — *도메인 = 결과 상태만, View = 표현 결정*이 MVC 분리.