oh-my-oop 0.2.0

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

@@ -0,0 +1,253 @@
+# PR #111 — [블랙잭 1단계] 밀러 미션
+
+- **Reviewee:** [@oungsi2000](https://github.com/oungsi2000)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/111
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 30 (리뷰어 21 / 리뷰이 9)
+- **참고:** PR #112 (etama123)와 *코드 구조가 매우 유사* — 페어 또는 공유 코드. 리뷰어/토론은 별개.
+
+> ⚠ **PR #112와 공통 패턴은 [PR #112](../etama123/112-1단계-블랙잭.md) 참고**. 본 문서는 *Gyuil-Hwnag 리뷰어의 추가 발견*과 *학생 자가 토론*에 집중.
+
+## 잘한 점 (설계 관점)
+
+- **`Card private constructor + Card.of(rank, suit)` Flyweight + `POOL`** — 52장 캐싱.
+- **`Deck(shuffledCards: List<Card>)` 명시 주입** (후속).
+- **`abstract class Participant` + `Dealer`/`Player`** + `hitThreshold` 추상.
+- **GameResult를 *빡세게 리팩토링* → `PlayerResults` 일급 컬렉션 (후속 반영)**.
+- **`GameResultStatus.toDisplayName()` 확장 함수를 *학생 자가 의문 → View로 이동***.
+- **학생이 *PR 본문에 자가 의문* 여러 개 (Card.toList(), GameResult 의도, GameResultStatus 위치 등) 정직하게 표현**.
+
+## 못한 점 (설계 관점 — PR #112와 공통)
+
+PR #112와 *코드 구조 동일*해 *공통 패턴* (자세한 분석은 [PR #112](../etama123/112-1단계-블랙잭.md)):
+
+- **`Card.toString` UI 결합 (`toDisplayName`)**.
+- **`enum.toDisplayName()` 확장 함수 = 도메인-뷰 결합**.
+- **`Rank.ACE.score = 11` 일반 통념 위배**.
+- **`Dealer.getCard(deck)`이 *while 루프*로 *시점 압축***.
+- **`DealerResult/GameResult/PlayerResult` 결과 객체 셋**.
+
+## 못한 점 (설계 관점 — PR #111 추가/특이 패턴)
+
+### 1. `Card.getAllCard(): List<Card>` POOL 직접 반환 vs 방어적 복사 — 학생 자가 토론
+
+```kotlin
+class Card private constructor(val rank: Rank, val suit: Suit) {
+    companion object {
+        private val POOL: List<Card> = Rank.entries.flatMap { rank -> Suit.entries.map { suit -> Card(rank, suit) } }
+        fun getAllCard() = POOL    // ⚠ POOL 자체 반환
+    }
+}
+```
+
+학생 자가 토론: "*현재는 모든 카드의 정보를 위해 내부적으로 이용되는 상수 POOL을 반환*하고 있습니다. [...] 현재는 미처 반영하지 못했지만 *방어적 복사를 이용하여 POOL.toList() 를 반환하게 했을 때 저는 문제를 찾지 못하겠습니다만 혹시 문제가 있을지* 궁금합니다"
+
+리뷰어: "*혹시 추가적인 설명 가능*하실까요?"
+
+학생 자가 답변: "*POOL을 toList() 메서드 없이 그대로 반환하게 된다면 외부에서 POOL을 수정하였을 때 Card 내부의 POOL에도 영향이 가는 문제가 있는*..."
+
+→ **`val POOL: List<Card>` 자체가 *immutable 인터페이스* (Kotlin List는 read-only view)**. `toList()` 호출 시 *복사된 새 List 반환*. **학생이 *Kotlin의 List vs MutableList* 구분을 *Java 어휘로 의심***. 정답: *`List<Card>` 반환은 안전*, *`MutableList<Card>` 반환이라면 `toList()` 필요*.
+
+### 2. `GameResult.dealerResult` public + `playerResult: MutableList<PlayerResult>` private — 비대칭 가시성
+
+```kotlin
+class GameResult(private val dealer: Dealer, val players: List<Player>) {
+    val dealerResult = DealerResult()                          // public
+    private val playerResult: MutableList<PlayerResult> = mutableListOf()    // private
+}
+```
+
+학생 자가 토론: "*DealerResult와 PlayerResult의 가시성 변경자가 다릅니다.* 현재의 *DealerResult를 private 로 만든 후* [...]"
+
+리뷰어: "*글로만 봐서는 어떤것을 기대하셨는지에 대해서 막 와닿지는 않군요..*😅 *현재 GameResult 의 구현을 보면 아래의 내용들이 궁금합니다!* 1. *GameResult 객체에서 delear와 player 두 가지 결과가 필요한지?*"
+
+또 리뷰어 권고: "*아래와 같은 순서로 리팩토링을 해볼 수 있을 것 같습니다!* 1. *DealerResult 제거*. 2. *GameResultStatus에 Dealer가 이겼는지에 대한 값 추가*. 3. *fun getResult(players: List<Player>, dealer..."
+
+→ **결과 객체 셋 → 단일 추상**. *DealerResult = Player 역집계*. 학생 후속: *DealerResult 삭제 + PlayerResults 일급 컬렉션*. PR #112와 같은 결.
+
+### 3. `GameResultStatus.toDisplayName()` 확장 함수 — 학생 자가 의문
+
+```kotlin
+// blackjack/domain/GameResultStatus.kt
+enum class GameResultStatus { PLAYER_WIN, PLAYER_LOSE, DRAW }
+fun GameResultStatus.toDisplayName(): String = when (this) {
+    PLAYER_WIN -> "승"; PLAYER_LOSE -> "패"; DRAW -> "무"
+}
+```
+
+학생 자가 의문: "*이 부분의 확장함수가 과연 enum에 view 로직을 끼어 넣는 것, 나아가 domain 로직에 view 로직을 끼어 넣는 것이 아닌가 궁금*합니다"
+
+리뷰어: "*좋은 의견이네요!* 위에 남겨둔 코멘트를 반영한다면, *Game 결과의 타입을 받아서 View에서 누가 승리했는지를 알고, 승자에 대한 표기까지 View의 로직으로 넘겨볼 수 있겠군요* *`domain 로직에 view 로직을 끼어 넣는 것이 아닌가`* ..."
+
+학생 자가 답변: "*처음에는 큰 생각이 없었는데 View 의 역할에 가깝다고 생각합니다!* *View의 역할은 데이터를 받아 포맷팅을 하여 화면(콘솔)에 띄우는 역할이 주된 역할이기 때문입니다!* *이 부분을 반영하여 확장함수를 view의 private 메서드로* ..."
+
+→ **학생이 *자가 의문 → 자가 답변* 패턴**. *enum 옆 확장 함수*가 *PR #112에서도 같은 토론 발생*. 둘 다 *View로 이동* 결론. **enum UI value 안티패턴의 가장 명확한 *학생 자가 깨달음*** — 13개 PR 연속 등장 중 자가 인식.
+
+### 4. `InputView.askPlayerHit`가 *예외 throw* — 학생 자가 의문
+
+```kotlin
+fun askPlayerHit(name: String): Boolean {
+    println("${name}는 한장의 카드를 더 받겠습니까?(예는 y, 아니오는 n)")
+    val input = readln()
+    if (input == "y") return true
+    if (input == "n") return false
+    throw IllegalArgumentException()    // ⚠ 유효성 실패 시 throw
+}
+```
+
+학생 자가 토론: "*이 부분을 현재는 throw 하도록 설정했지만 추후 검증 실패 시 null을 반환하도록 하여 컨트롤러에서 전파 후 특정 로직 실행을 하도록 설정하도록 하겠습니다*"
+
+→ **학생이 *throw vs null* 트레이드오프 자가 인식**. *재입력 루프*가 Controller 책임이라면 *null + Elvis 재시도*가 자연. PR #25·#135와 같은 결.
+
+### 5. `init 블록에서 생성 시 결과 계산` vs Elegant Object — 학생 자가 토론
+
+학생 자가 토론: "*혹은 init 블록에서 객체가 생성될 때 dealerResult와 playerResult를 생성하게끔 하려했지만* *엘레강트 오브젝트에서 생성자에는 코드를 넣지 마세요* 라는 부분이 조금 걸립니다"
+
+→ **"Elegant Objects" 책의 *생성자에 코드 X* 원칙 vs *생성 시 invariant 계산* 트레이드오프**. *원칙 충돌 시 자가 판단* 필요. *생성자가 *복잡 로직*이면 원칙 위반*, *생성 시 한 번 계산*이면 *invariant 유지*. **원칙 절대화 vs 맥락 판단**.
+
+### 6. `GameController`가 *카드 미리 셔플 + Deck에 전달*
+
+```kotlin
+class GameController(...) {
+    private val shuffledCards: List<Card> = Card.getAllCard().shuffled()    // ⚠ Controller가 셔플
+    private val deck = Deck(shuffledCards)
+}
+```
+
+리뷰어: "*카드를 생성하여 댁에 넣어주는 방식으로 하셨군요~ 해당 구현이 나오게 된 이유가 궁금합니다!*"
+
+학생 자가 답변: "*자동차 경주, 로또에서 테스트 불가능한 부분은 최대한 상위 계층으로 전파하여 주입하는 방식으로 진행하라는 내용이 있었습니다.* *블랙잭 또한 랜덤 요소로 인한 테스트 불가능한 부분이 있었기에 Controller에서 미리 섞은 후* ..."
+
+→ **lotto/racingcar `non-newable` 패턴 의식적 적용**. *셔플 = 비결정성*을 *Controller에서 주입*하면 *Deck은 결정적 자료구조*. **학생이 *이전 미션 학습 적용*** — 점진 학습의 모범.
+
+또: 학생 자가 의문: "*BlackJackGame 는 view를 의존해도 되는가?* 입니다. *저는 고민을 하다, 결국 의존하면 안된다 라는 결론이 나서 view를 걷어내었습니다*."
+
+리뷰어: "*플레이어가 카드를 뽑고, 결과를 알려준다는 로직을 Controller 말고 GameManager라는 객체에서 실행하도록 해볼 수도 있겠다는 생각이 듭니다! Controller에 로직이 드러나지 않도록 구현을 해보는 것은 어떨까라는 생각이 듭니다*~💪"
+
+→ *Controller god-object* + *Game/Manager 분리* 권고. PR #25·#92·#33과 같은 결.
+
+### 7. `Dealer.getCard()` 함수명 모호
+
+```kotlin
+class Dealer : Participant() {
+    fun getCard(deck: Deck) { while (canHit()) { addCard(deck.draw()) } }
+    fun hasAdditionalCard(): Boolean = cards.size > INITIAL_CARD_COUNT
+}
+```
+
+리뷰어: "*getCard()라는 네이밍만 본다면, Dealer의 카드들을 반환하는 것으로 유추되는데 어떤 기능을 담당하는지 드러나도록 네이밍을 수정해보는것도 좋을 것 같습니다!*" — `get*`은 *질의*. `drawUntilStop()` / `playDealerTurn()` 같은 *동작 동사*. PR #112와 같은 결.
+
+### 8. `DealerResult` Int 필드 (win/lose/draw 카운트)
+
+```kotlin
+class DealerResult { var win = 0; var lose = 0; var draw = 0 }
+```
+
+리뷰어: "*해당 값을 int로 선언을 하신이유가 있을까요? 다른 방법도 있을 것 같다는 생각이 들어서요!*" — `Map<Status, Int>` 또는 `Counter` 자료구조. *세 개의 var Int*는 *카운트 추가 시* 멤버 추가 필요. *역집계로 단순화* 가능 (PR #112와 같은 결).
+
+### 9. `Deck` class 선택 이유
+
+```kotlin
+class Deck(private val cards: List<Card>) { ... }
+```
+
+리뷰어: "*Deck 이라는 객체는 class로 선언을 하신 이유가 있을까요?*🤔" — `class` vs `object` vs `value class`. *cards를 보유*하면 class. *불변이면 value class*도. 학생의 선택 근거 묻기. 학생 답변 없음.
+
+### 10. `Card.private constructor` 이유
+
+```kotlin
+class Card private constructor(val rank: Rank, val suit: Suit) { ... }
+```
+
+리뷰어: "*Card 객체에 private constructor 키워드가 추가된 이유가 궁금합니다!*" — Flyweight 의도. *외부에서 new로 새 인스턴스 생성 차단*. `Card.of(rank, suit)` 팩토리만 사용. **리뷰어가 의도 확인**.
+
+### 11. `Participant.totalSum: Int = 0; private set` + `cards: MutableList<Card>` public
+
+```kotlin
+abstract class Participant {
+    var totalSum: Int = 0
+        private set
+    val cards: MutableList<Card> = mutableListOf()   // ⚠ public mutable
+    ...
+}
+```
+
+학생 자가 인정: "*다시 보니 이부분은 addCard 메서드를 통하지 않고 직접 cards에 접근하여 수정할 수 있겠네요 시정하겠습니다*"
+
+→ **`var private set + cards public mutable` 비대칭**. *totalSum*은 *값 변경 차단*했지만 *cards*는 *외부에서 add 가능* = *totalSum 동기화 깨짐*. *cards도 `private`* + `addCard()` 메서드 노출. 학생 자가 발견.
+
+### 12. `Participant`에 *점수 계산이 박힘*
+
+리뷰어: "*점수를 계산하는 부분을 분리를 해볼 수 있을 것 같다는 생각이 듭니다*~💪" — PR #112·#114·#119·#10 등 *점수 = Card/Hand 책임* 권고와 같은 결.
+
+### 13. `Rank` enum의 *toDisplayName* + ACE 11 — 리뷰어 권고 코드 예시
+
+```kotlin
+// 리뷰어 권고 코드
+enum class Rank(val score: Int) {
+    ACE(11), TWO(2), ..., TEN(10),
+    KING(10), QUEEN(10), JACK(10);
+}
+```
+
+리뷰어: "*위에 `GameResultStatus`와 같은 내용이겠군요~ 아래와 같이도 구현을 해볼 수 있습니다!* ```kotlin enum class Rank(val score: Int) { ACE(11), TWO(2), ..., TEN(10), KING(10), QUEEN(10), JACK(10); }```" — *Score만 enum 속성*, *DisplayName은 OutputView*. **enum의 *도메인 속성*과 *UI 속성*의 명확한 구분 강조**.
+
+### 14. `OutputView` 하드코딩 vs 상수화 — 학생 자가 의문
+
+학생 자가 토론: "*하드코딩 된 부분 상수화 진행하였습니다! 다만 view에서 어디부터 어디까지 상수화를 진행해야 하는가? 는 아직 감이 잘 안오는 것 같습니다,,,*"
+
+리뷰어 권고: "*추가적으로 하드코딩된 내용들에 대해서, 상수화 + 포맷을 적용해볼 수 있을 것 같습니다*~💪" — **View 상수화의 *경계* 자가 의문**. *반복 사용 + 의미 명시 + 변경 가능성*이 *상수화 기준*. *일회용 + 자명한 표현*은 상수화 과잉.
+
+### 15. `ParticipantTest` 중복 setup
+
+리뷰어: "*해당 내용들에 대해서는 함수로 만들어 둔다면, 공통적으로 사용되는 중복된 내용을 줄여볼 수 있을 것 같군요!*" — *test fixture 헬퍼*. PR #17·#28·#10과 같은 결.
+
+## 리뷰어 의견 요지
+
+- ***`POOL: List<Card>` 그대로 반환 안전 vs `MutableList`면 `toList()` 필요*** — Kotlin List/MutableList 구분.
+- ***GameResult 가시성 비대칭 = 책임 분산 신호***.
+- ***`enum 옆 toDisplayName 확장함수`는 학생 자가 의문 → View 이동*** (자가 깨달음).
+- ***예외 throw vs null 반환 = 재입력 루프의 위치 결정***.
+- ***Elegant Objects 원칙 vs 생성 시 invariant 계산 트레이드오프***.
+- ***Controller에서 미리 셔플 = 비결정성 상위 전파*** — lotto/racingcar 학습 적용.
+- ***`getCard()` 함수명 모호*** — 동작 동사.
+- ***DealerResult Int 필드 = 카운트 추가 시 멤버 추가 필요***.
+- ***`Deck class` / `Card private constructor` 선택 근거 묻기***.
+- ***`totalSum var private set + cards public mutable` 비대칭 = 동기화 깨짐*** (학생 자가 발견).
+- ***점수 계산 = 분리 책임***.
+- ***enum의 도메인 속성(score) vs UI 속성(displayName) 명확 구분***.
+- ***View 상수화의 경계*** — 반복 + 의미 + 변경 가능성.
+
+## 대표 인용
+
+> 이 부분의 *확장함수가 과연 enum에 view 로직을 끼어 넣는 것, 나아가 domain 로직에 view 로직을 끼어 넣는 것이 아닌가* 궁금합니다
+> — @oungsi2000 (학생 자가 의문) on `GameResultStatus.kt`
+
+> *DealerResult 제거*. *GameResultStatus에 Dealer가 이겼는지에 대한 값 추가*. *fun getResult(players: List<Player>, dealer...*
+> — @Gyuil-Hwnag (리뷰어 단계별 리팩토링 권고) on `GameResult.kt`
+
+> 자동차 경주, 로또에서 *테스트 불가능한 부분은 최대한 상위 계층으로 전파하여 주입하는 방식으로 진행하라는 내용*이 있었습니다. *블랙잭 또한 랜덤 요소로 인한 테스트 불가능한 부분이 있었기에 Controller에서 미리 섞은 후* ...
+> — @oungsi2000 (이전 미션 학습 적용) on `GameController.kt`
+
+> Card 객체에 *private constructor 키워드가 추가된 이유*가 궁금합니다!
+> — @Gyuil-Hwnag on `Card.kt`
+
+> 점수를 계산하는 부분을 *분리를 해볼 수 있을 것 같*다는 생각이 듭니다~💪
+> — @Gyuil-Hwnag on `Participant.kt`
+
+## 얻은 교훈
+
+- ***`val POOL: List<Card>` 반환 안전*** — Kotlin `List`는 *read-only 인터페이스*. `toList()` 호출은 *MutableList일 때만 필요*. **학생이 Java 어휘로 의심하는 흔한 오해**.
+- ***GameResult 가시성 비대칭 = 책임 분산 신호*** — *DealerResult 제거 + GameResultStatus에 dealer 결과까지 + getResult(players, dealer) 함수* 단계별 리팩토링.
+- ***enum 옆 확장 함수의 *학생 자가 의문 → View 이동*은 가장 명확한 자가 깨달음*** — *enum UI value 안티패턴*이 13개 PR 연속 등장 중 학생 자가 인식 도달.
+- ***예외 throw vs null 반환 = 재입력 루프의 위치*** — 재입력이 Controller 책임이면 null이 자연.
+- ***Elegant Objects 원칙 (*생성자에 코드 X*) vs 생성 시 invariant 계산 = 트레이드오프*** — 원칙 절대화 vs 맥락 판단. *생성자 = 복잡 로직*이면 위반, *invariant 보호 한 줄*이면 정당화.
+- ***Controller에서 미리 셔플 + Deck에 명시 주입 = lotto/racingcar `non-newable` 패턴 학습 적용*** — *비결정성 상위 전파*. 점진 학습의 모범 사례.
+- ***`getCard()` 함수명 모호 = 동작 동사*** — `drawUntilStop()`. PR #112와 같은 결.
+- ***DealerResult Int 필드 (win/lose/draw 별 var Int) = 카운트 추가 시 멤버 추가*** — Map 자료구조 또는 역집계로 단순화.
+- ***`Deck class` / `Card private constructor` 선택 근거*** — *상태 보유면 class*, *Flyweight 의도면 private constructor*. *선택 근거를 글로 남기는 습관* 권고.
+- ***`totalSum var private set + cards public mutable` 비대칭 = totalSum 동기화 깨짐*** — *cards도 private + addCard 메서드*만 노출. 학생 자가 발견.
+- ***enum의 도메인 속성(score) vs UI 속성(displayName) 명확 구분*** — *score는 도메인 = enum 속성*, *displayName은 UI = OutputView*.
+- ***View 상수화의 경계 = 반복 + 의미 + 변경 가능성*** — *일회용 + 자명한 표현*은 상수화 과잉.
+- ***학생이 자가 의문을 명시하는 PR은 *자가 답변에 도달*하기 쉬움*** — PR #111의 *GameResultStatus 확장 함수*가 *학생이 자가 답변 도출*. PR #135·#29와 같은 결.