oh-my-oop 0.2.0

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

@@ -0,0 +1,348 @@
+# PR #113 — [블랙잭 1단계] 포르 미션
+
+- **Reviewee:** [@jiyuneel](https://github.com/jiyuneel)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/113
+- **단계:** 1단계
+- **리뷰어:** [@KwonDae](https://github.com/KwonDae) (제이든) — 2025 코호트 전담 reviewer (PR #117·#126·#129·#138·#139·#142·#143·#109·#113 분석 reviewer)
+- **라인 코멘트:** 22 스레드 — *2025 코호트 셀프 체크리스트 PR 본문 + 모든 22 스레드 학생 자가 답변 + commit SHA + 학생 자가 후속 의문 5+ 회 (Player.playGame 추상화 의문 + 인자 폭증 의문 + Controller 책임 의문) + Hit/Stay Boolean vs Action enum (PR #117·#126 결과 반대 시점) + Deck null vs 예외 + companion → 인스턴스 + 고차함수 활용 + canHit 추상화 자가 학습 + Result enum 도메인 vs 뷰 + abstract vs open vs interface 자가 학습 + Participants 일급 컬렉션 자가 적용 + playGame 추상화 → Participants 역할 (reviewer 자가 수정)*
+- **신규 reviewee** (2025년 코호트 — 모바일 안드로이드 7기, PR #117·#129·#130·#126·#138·#142·#143·#109·#113 = **2025 코호트 9 PR 코퍼스 성장**).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 의문 + 셀프 체크리스트 + 학생 자가 입장 명시 (2025 코호트 정점)
+
+PR 본문 + 라인 자가 입장 (Thread 2 인용):
+
+> *"`controller`를 게임의 중재자 또는 카지노라고 생각했습니다. 참가자가 처음에 뽑아야 하는 카드의 수(2장)는 게임의 룰에 해당하며, 이를 `controller`가 관리하는 것이 가장 바람직하다고 판단했습니다..!*
+>
+> *참가자에게 카드를 뽑으라는 메시지를 두 번씩 던져서 참가자는 카드 뽑기의 주체가 되지만, 몇 번 뽑아야 하는지는 게임의 흐름을 조율하는 `controller`가 결정하는 것이 적절하다고 생각했는데 어떻게 생각하시나요..?!"*
+
+→ **학생 자가 입장 명시 + reviewer 의견 요청** = PR #35·#126 (hyemdooly·doabletuple *학생 자가 입장 명시*) 결 합류.
+
+reviewer 후속 (Thread 15):
+
+> *"BlackJackGame 이라는 도메인 모델이 존재한다면 보다 명확해질 수 있을까요?"*
+
+학생 자가 적용 → *BlackjackGame 도메인 객체 자가 생성*. 
+
+**MCP 룰 `controller-as-game-mediator-vs-domain-game-object` 후보** — *Controller 가 게임 흐름 vs BlackjackGame 도메인 객체* 트레이드오프.
+
+### 2. `Hit/Stay Boolean` vs `Action enum` — PR #117·#126 결과 반대 시점
+
+reviewer (Thread 1):
+
+> *"Hit or Stay를 Boolean으로 구분할 수 있지 않을까요? 처음에 Action 이라는 키워드를 보고 어떤 의미인지 판단하기 쉽지 않을 것 같습니다."*
+
+학생 자가 적용: `readPlayerHit(player): Boolean`.
+
+→ **`Action enum` (PR #117·#126) vs `Boolean` (PR #113)** = **2 reviewer 의 *반대 시점 자가 적용*** = *MCP `oop_propose_alternatives` 핵심 가치 합류*:
+
+- **PR #117·#126** (reviewer KwonDae·woowahan-dino): *String → Action enum (Stringly-typed 회피)*.
+- **PR #113** (reviewer KwonDae): *Action → Boolean (의미 직관)*.
+
+→ **같은 reviewer (KwonDae) 의 *다른 학생에 다른 권유*** = *학생 컨텍스트 별 트레이드오프*.
+
+**MCP 룰 `enum-vs-boolean-context-dependent` 후보** — *enum vs Boolean = 의미 명시 vs 직관성 트레이드오프*.
+
+### 3. `BlackjackGame` 도메인 객체 자가 적용 + 룰 응집
+
+reviewer (Thread 15): *"BlackJackGame 이라는 도메인 모델이 존재한다면 보다 명확해질 수 있을까요?"*
+
+학생 자가 적용:
+
+```kotlin
+fun distributeInitialCards() {
+    repeat(INITIAL_CARD_COUNT) {
+        participants.drawCard(deck)
+    }
+}
+```
+
+→ **게임 룰 도메인 응집 + Controller 가벼움** = PR #129·#126·#142 결 합류.
+
+### 4. 학생 자가 *현실 메타포 = Controller = 게임 중재자/카지노* (Thread 2)
+
+§1 인용. 학생이 자가 *Controller = 카지노* 메타포 사용 → reviewer *Controller 가 흐름 조율 vs 참가자 자가 뽑기* 권유.
+
+→ **현실 메타포 양가성** = PR #117·#129·#130·#143·#109 결의 *현실 메타포 정합* 어휘 누적 12+ PR ⭐⭐⭐.
+
+다만 *PR #129 reviewer = 참가자 자가 / PR #113 학생 자가 = Controller 중재자* = **메타포 양가**.
+
+### 5. `abstract class Participant` + canHit/getResult 추상 메서드 자가 학습
+
+학생 자가 답변 (Thread 16):
+
+> *"`interface`는 상태를 가질 수 없으며, `open class`는 하위 클래스에서 공통 메서드를 구현하도록 강제할 수 없습니다. 딜러와 플레이어의 공통된 상태와 역할을 제공하면서, 일부 구체적인 로직은 각 클래스에서 구현하도록 하기 위해 `abstract class`를 사용했습니다!"*
+
+→ **abstract class vs open vs interface 3 분류 학생 자가 학습** = PR #129·#126·#138·#142·#143 결 합류 누적 6+ PR.
+
+### 6. 학생 자가 후속 의문 + reviewer 자가 권유 수정 (Thread 20·21)
+
+학생 자가 의문 (Thread 20):
+
+> *"플레이어는 'y'를 입력하면 카드를 추가로 뽑을 수 있고, 딜러는 점수가 16 이하이면 카드를 추가로 뽑을 수 있습니다. 이처럼 카드를 뽑는 공통 역할이 있어 `Player`와 `Dealer`의 `playGame`를 추상화하고 싶었습니다.*
+>
+> *하지만 각 클래스의 `playGame`에서 필요로 하는 파라미터가 달라 다소 복잡해졌는데, 제이든이 보시기에는 어떠신지, 더 나은 추상화 방법이 있는지 피드백 부탁드립니다..! 🙏🏻"*
+
+reviewer 자가 수정 (Thread 20):
+
+> *"이 부분은 수정할게요. playGame의 내용은 각 참가자별로 게임을 진행하는 로직으로 Participant로의 추상화 보다는 Participants에서 역할을 할 수 있지 않을까 생각이 들었습니다. 현재 참가자의 결과를 계산하는 `getPlayerResults` 처럼 playGame은 Player 와 Dealer의 추상화 보다는 이미 추상화된 `canHit(), drawCard()` 를 사용하면 지금 하고 계신 고민들에 도움이 될 것 같아요"*
+
+→ **시그니처 차이 추상화 한계 + reviewer 자가 권유 수정 + 이미 추상화된 메서드 활용 권유** = PR #126 (abstract-method-blocked-by-signature-divergence) 결 강화 + PR #142·#109 (reviewer 자가 한계 인정/수정) 결 합류.
+
+**MCP 룰 `reviewer-self-suggestion-revision` 후보** — *reviewer 가 자가 권유 수정 + 더 나은 안 제시*.
+
+### 7. 학생 자가 ShuffledCardGenerator + Deck(cards) DI 자가 적용
+
+reviewer (Thread 8): *"Deck이 항상 랜덤으로 생성될 경우 해당 도메인은 테스트가 어려워집니다."*
+
+학생 자가 적용:
+
+```kotlin
+class ShuffledCardGenerator {
+    fun generate(): List<Card> = ...
+}
+
+class Deck(cards: List<Card>) {
+    val cards: ArrayDeque<Card> = ArrayDeque(cards)
+    fun pick(): Card = cards.removeLast()
+}
+```
+
+→ **DI + 카드 생성 분리** = PR #138·#143 (Deck DI) 결 합류. **MCP 룰 `interface-for-test-substitution` 강화** 누적 6+ PR.
+
+### 8. 추가 칭찬
+
+- Thread 19: *"공통 로직 추상화 잘해주셨어요 👍"*.
+- Thread 22: *"참가자들을 관리하여 역할을 분리할 수 있게 되었네요! 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Deck.pick(): Card?` nullable 반환 — null vs 예외
+
+reviewer (Thread 4): *"만약 덱이 비어있으면 어떤 일이 발생할까요?"*
+
+학생 자가 답변:
+
+> *"덱이 비어있는 경우에 예외를 던질지 고민했는데, 카드가 없는 것도 정상적인 게임 상황이라고 판단하고 게임을 결과를 출력하도록 했습니다! 덱이 비어있으면 null을 반환하고, `controller`에서 null을 확인하여 프로그램을 종료하고 결과를 출력합니다."*
+
+→ **null 반환 정공** = PR #35 (galcyurio Kotlin 예외 처리 4 원칙) 결의 *논리 오류 X = null 반환* 정공. **MCP 룰 `kotlin-exception-handling-strategy` 강화** 누적 4+ PR (#129·#138·#35·#113).
+
+### 2. Deck companion → 인스턴스 변경 (학생 자가 자가 정정)
+
+reviewer (Thread 5): *"Deck의 변수와 함수들을 모두 companion object에 구현한 배경은 무엇이었을까요? 🧐"*
+
+학생: *"여기저기서 `Deck`에 접근할 수 있을 것 같아 현재는 인스턴스를 만들어 사용하도록 변경했습니다!"*
+
+→ **Singleton 자가 회피 + 인스턴스 정공** = PR #130·#138·#143 (Singleton Deck 안티패턴) 결 누적 20+ PR ⭐⭐⭐.
+
+### 3. Players 일급 컬렉션 사용자 입력 한계 학생 자가 의문
+
+reviewer (Thread 7): *"만들어주신 Players 일급컬렉션의 역할을 제대로 하고 있는걸까요?"*
+
+학생 자가 의문:
+
+> *"`Players` 일급컬렉션을 활용하는 방법을 고민해보았지만, 플레이어는 매번 카드를 뽑을지 여부를 view에서 입력받아야 해서 해당 로직을 도메인으로 옮기는 것이 쉽지 않았습니다. 😢 현재 구조에서는 사용자의 입력이 필요한 부분이 존재하여 `Players` 내부에서 구현하기에 한계가 있는데, 이를 해결할 수 있는 방법이 있을까요..?"*
+
+reviewer 답변 (Thread 14): *"입력받는 로직을 domain으로 옮겨야만 해결이 가능할까요? hint. kotlin에는 [고차함수](https://kotlinlang.org/docs/lambdas.html)라는게 존재합니다."*
+
+학생 자가 적용 + 자가 한계 인정:
+
+> *"고차함수를 활용하여 참가자들이 각자 게임을 진행하도록 변경해봤습니다! 다만, 아직 고차함수가 익숙하지 않아 적절하게 사용하였는지는 잘 모르겠습니다..! 😢"*
+
+→ **사용자 입력 vs 도메인 = 고차함수 정공 + 학생 자가 학습 한계 인정** = PR #87·#129·#138·#126 결.
+
+### 4. Result enum 도메인 vs 뷰 (PR #126·#143 결과 같은 어휘)
+
+reviewer (Thread 10): *"승, 패, 무 는 도메인 로직일까요?"*
+
+학생 자가 답변:
+
+> *"해당 값은 출력을 할 때만 필요한 정보이므로 뷰 로직이라고 생각합니다! `OutputView`에서 처리하도록 수정했습니다."*
+
+→ **String 출력 = View 책임** = PR #126·#130·#143 결 강화 누적 4+ PR.
+
+### 5. Rank 기호 표시 = 도메인 vs 뷰 (변경 가능성 지표)
+
+reviewer (Thread 12): *"만약 A 대신 기호로 표시해달라는 요구사항이 온다면 도메인 로직을 수정해야 할까요?"*
+
+→ **변경 가능성 = View 책임 지표** = PR #126 (KwonDae 동일 어휘) 결 강화 누적 2+ PR.
+
+### 6. 인자 폭증 (4 람다 인자) — 학생 자가 의문
+
+학생 코드 (Thread 21):
+
+```kotlin
+fun playTurns(
+    onPlayerResponse: (Player) -> Boolean,
+    onPlayerDraw: (Player) -> Unit,
+    onDealerDraw: (Dealer) -> Unit,
+) {
+    participants.playGame(deck, onPlayerResponse, onPlayerDraw, onDealerDraw)
+}
+```
+
+학생 자가 의문:
+
+> *"`participants`에게 메세지를 던지는 방식으로 변경했습니다! 다만, 이렇게 변경하니 인자를 너무 많이 넘겨주는 건 아닌가 싶긴 하네요.. 😅"*
+
+→ **콜백 람다 폭증 학생 자가 인지** = PR #36·#142·#35 (`callback-lambda-explosion`) 결 합류. 
+
+### 7. 결과 계산 책임 분배 + 학생 자가 의문 2 가지 (Thread 11)
+
+학생 자가 의문:
+
+> *"1. 플레이어는 `승 or 패`의 결과가 나오는 반면, 딜러는 모든 플레이어와 비교하여 `n승 n패` 형식의 결과가 나옵니다. 그렇기에 controller에서 딜러의 결과를 계산하는 로직은 아직 남아있습니다.*
+>
+> *2. 변경되기 전의 코드는 모든 플레이어의 결과를 계산한 후, 그 결과를 바탕으로 딜러의 결과를 계산했습니다. 플레이어의 결과에 따라서 딜러의 결과가 결정된다고 생각해서 이렇게 구현했었습니다. 다른 참가자와 비교하여 결과를 계산하도록 변경하면서 동일한 비교를"*
+
+→ **Player 1대1 결과 vs Dealer n승n패 형식 비대칭 + 동일 비교 반복** = PR #142 (doabletuple 자가 코드 예시 + 자가 의문) 결 합류. **MCP 룰 `symmetric-compare-bidirectional-call` 강화** 누적 3+ PR (#142·#143·#113).
+
+### 8. `Players.players` 2 depth 일급 컬렉션 → Participants 자가 적용
+
+reviewer (Thread 17): *"2 depth로 들어가는 `players.players` 으로도 일급컬렉션의 용도가 생기는 부분 같아요..!"*
+
+학생 자가 적용: *Participants 클래스 추가 (딜러 + 플레이어 관리)*.
+
+→ **PR #129 (compile-time-singleton + Participants 생성자 타입 분리) 결 합류**.
+
+### 9. `Hand` 생성자 vs emptyList 기본값
+
+reviewer (Thread 3): *"현재 생성자가 사용되는곳은 Participant 뿐이어서 생성자로 받지 않아도 차이는 없어보이네요!"*
+
+학생 자가 적용: `Hand` 기본 `emptyList()`.
+
+→ **불필요한 생성자 인자 제거** — PR #109·#138 (test fixture 생성자) 결과 같은 어휘. 
+
+### 10. 확장 함수 위치 (Controller 내부 vs Domain)
+
+reviewer (Thread 18): *"Participant 확장함수가 Controller 내부에 있는게 자연스러울까요? 🧐"*
+
+학생: *"덱에 카드가 비어있으면 다시 카드를 넣어주도록 변경하여 해당 확장함수는 삭제했습니다!"*
+
+→ **확장 함수 위치 = 도메인 위치 정공**. **MCP 룰 `extension-function-locator` 후보**.
+
+### 11. `Dealer.canHit() = score <= 16` + `Player.canHit() = score <= 21`
+
+```kotlin
+abstract fun canHit(): Boolean
+```
+
+→ **각자 다른 기준 자가 적용** = PR #129·#126·#138·#142·#143 결.
+
+다만 *Player canHit `score <= 21`* — *21 시 hit 가능* = PR #129·#138·#139·#126·#130·#142·#143 결과 동일 (21 시 hit 가능 모델). PR #35 (21 시 stop) 반대 시점.
+
+### 12. `getResult` 추상 메서드 + Player/Dealer override
+
+```kotlin
+abstract fun getResult(other: Participant): Result
+```
+
+→ **Tell-Don't-Ask 정공 + 양쪽 자가 비교** = PR #142·#143·#109 결.
+
+### 13. 한 도메인 객체 (`BlackjackGame`) 다른 도메인 객체 (`Participants`) 동시 보유 — 책임 중첩
+
+학생 코드: *BlackjackGame + Participants 동시 존재* = PR #142·#143 (Game/Scoreboard 분리) 결 합류. *Controller → BlackjackGame → Participants 3 단계 메시지*.
+
+### 14. 모든 22 스레드 학생 자가 답변 + commit SHA + 자가 후속 의문 5+ 회 — 2025 코호트 정점
+
+## 리뷰어 의견 요지
+
+- **Hit/Stay Boolean 권유 (PR #117·#126 반대 시점)**.
+- **Controller 흐름 vs 참가자 자가 분배 (학생 자가 입장 + reviewer 양방향)**.
+- **Hand 생성자 제거 + emptyList 기본값**.
+- **Deck null 반환 vs 예외**.
+- **Deck companion → 인스턴스 변경**.
+- **canHit 공통 로직 자가 학습**.
+- **Players 일급 컬렉션 사용자 입력 한계 학생 자가 의문 + 고차함수 권유**.
+- **테스트 가능성 = Deck DI + ShuffledCardGenerator 분리**.
+- **Result enum 도메인 vs 뷰**.
+- **getResult 추상 메서드 + 학생 자가 의문 2가지 (Player 1대1 vs Dealer n승n패)**.
+- **Rank 기호 표시 = 도메인 vs 뷰 (변경 가능성)**.
+- **고차함수 입력받기 + 학생 자가 한계 인정**.
+- **BlackjackGame 도메인 객체 권유 + 학생 자가 적용**.
+- **abstract vs open vs interface 자가 학습**.
+- **Players.players 2 depth + Participants 일급 컬렉션 자가 적용**.
+- **playGame 추상화 → Participants 역할 (reviewer 자가 수정)**.
+- **확장 함수 위치 (Controller vs Domain)**.
+
+## 대표 인용
+
+> [KwonDae Thread 1]
+> *"Hit or Stay를 Boolean으로 구분할 수 있지 않을까요? 처음에 Action 이라는 키워드를 보고 어떤 의미인지 판단하기 쉽지 않을 것 같습니다."*
+
+→ **enum vs Boolean = 의미 명시 vs 직관성** — *PR #117·#126 정공 (enum) 반대 시점*.
+
+> [jiyuneel Thread 2]
+> *"`controller`를 게임의 중재자 또는 카지노라고 생각했습니다. 참가자가 처음에 뽑아야 하는 카드의 수(2장)는 게임의 룰에 해당하며, 이를 `controller`가 관리하는 것이 가장 바람직하다고 판단했습니다..!"*
+
+→ **학생 자가 *Controller = 카지노* 현실 메타포** — *PR #129 (참가자 자가) 반대 시점 양가*.
+
+> [KwonDae Thread 20]
+> *"이 부분은 수정할게요. (...) playGame은 Player 와 Dealer의 추상화 보다는 이미 추상화된 `canHit(), drawCard()` 를 사용하면 지금 하고 계신 고민들에 도움이 될 것 같아요"*
+
+→ **reviewer 자가 권유 수정 + 이미 추상화 활용** — *PR #142·#109 결 합류*.
+
+> [jiyuneel Thread 21]
+> *"`participants`에게 메세지를 던지는 방식으로 변경했습니다! 다만, 이렇게 변경하니 인자를 너무 많이 넘겨주는 건 아닌가 싶긴 하네요.. 😅"*
+
+→ **학생 자가 콜백 람다 폭증 인지** — *PR #36·#142 결 합류*.
+
+## 얻은 교훈 (보편)
+
+1. **enum vs Boolean = 의미 명시 vs 직관성 트레이드오프 (PR #117·#126 반대 시점)** — **MCP 룰 `enum-vs-boolean-context-dependent` 후보**.
+
+2. **Controller = 게임 중재자/카지노 vs 참가자 자가 (현실 메타포 양가)** — *PR #129 결과 반대 시점*. **MCP 룰 `controller-as-game-mediator-vs-domain-game-object` 후보**.
+
+3. **reviewer 자가 권유 수정 + 이미 추상화 활용** — **MCP 룰 `reviewer-self-suggestion-revision` 후보**.
+
+4. **사용자 입력 vs 도메인 = 고차함수 정공 + 학생 자가 한계 인정** — PR #87·#129·#138·#126 결.
+
+5. **결과 비대칭 (Player 1대1 vs Dealer n승n패) + 동일 비교 반복** — **MCP 룰 `symmetric-compare-bidirectional-call` 강화** 누적 3+ PR.
+
+6. **Players 일급 컬렉션 사용자 입력 한계 학생 자가 의문 + 고차함수 답변** — *학생 자가 학습 정점*.
+
+7. **null 반환 = 정상 게임 상황 (Kotlin 예외 처리 4 원칙)** — **MCP 룰 `kotlin-exception-handling-strategy` 강화** 누적 4+ PR.
+
+8. **현실 메타포 양가 (Controller 카지노 vs 참가자 자가)** — **MCP 룰 `metaphor-fidelity-locator` 강화** 누적 12+ PR ⭐⭐⭐.
+
+9. **abstract vs open vs interface 학생 자가 3 분류** — *PR #129·#126·#138·#142·#143·#113 결 합류 누적 6+ PR*.
+
+10. **확장 함수 위치 (Controller vs Domain)** — **MCP 룰 `extension-function-locator` 후보**.
+
+11. **변경 가능성 = View 책임 지표 (PR #126 결)** — *Rank 기호 표시*.
+
+12. **모든 22 스레드 학생 자가 답변 + commit SHA + 자가 후속 의문 5+ 회** — *2025 코호트 정점 유지*.
+
+## 얻은 교훈 (도메인)
+
+1. **Dealer canHit `score <= 16` + Player canHit `score <= 21`** — *각자 기준 자가 적용*.
+
+2. **카드 N장 뽑기 = 도메인 룰 (학생 자가 *카지노* 메타포 + reviewer *참가자 자가* 메타포 양가)**.
+
+3. **Player 1대1 결과 vs Dealer n승n패 결과 비대칭** — *학생 자가 의문*.
+
+## MCP 룰 후보 신규 + 강화 (PR #113)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `enum-vs-boolean-context-dependent` | 신규 | 1 (#113) |
+| `controller-as-game-mediator-vs-domain-game-object` | 신규 | 1 (#113) |
+| `reviewer-self-suggestion-revision` | 신규 | 1 (#113) |
+| `symmetric-compare-bidirectional-call` | 강화 | 3+ (#142·#143·#113) |
+| `metaphor-fidelity-locator` | 강화 | 12+ ⭐⭐⭐ |
+| `kotlin-exception-handling-strategy` | 강화 | 4+ |
+| `extension-function-locator` | 신규 | 1 (#113) |
+| `interface-for-test-substitution` | 강화 | 6+ |
+| `string-formatting-view-responsibility` | 강화 | 4+ |
+| `singleton-deck-via-companion` | 강화 | 20+ ⭐⭐⭐ |
+| `abstract-without-abstract-method` | 강화 | 6+ |
+
+## 메타 어휘 (14 reviewer + MCP 핵심 가치 합류 정점 유지)
+
+- ***학생 자가 *Controller = 카지노* 현실 메타포*** — jiyuneel PR #113 — *현실 메타포 양가성*.
+- ***reviewer 자가 권유 수정 + 이미 추상화 활용*** — KwonDae PR #113 — *PR #142·#109 결 합류*.
+- ***Hit/Stay enum vs Boolean = 같은 reviewer 의 다른 학생 다른 권유*** — KwonDae PR #117·#126 (enum) vs PR #113 (Boolean) — *학생 컨텍스트 별 트레이드오프*.
+- ***학생 자가 콜백 람다 폭증 인지*** — jiyuneel PR #113 — *PR #36·#142 결 합류*.
+
+→ **14 reviewer + MCP 핵심 가치 어휘 합류 정점 유지**. **2025 코호트 9 PR 코퍼스 성장**.

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

@@ -0,0 +1,265 @@
+# PR #140 — [블랙잭 2단계] 포르 미션
+
+- **Reviewee:** [@jiyuneel](https://github.com/jiyuneel)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/140
+- **단계:** 2단계
+- **리뷰어:** [@KwonDae](https://github.com/KwonDae) (제이든) — 1단계 #113 동일 reviewer
+- **라인 코멘트:** 16 스레드 — *PR 본문 자가 의문 + 학생 자가 의문 5+ 회 + 람다 4개 인자 폭증 자가 의문 (PR #142 결과 동일) + 고차함수 = View 의존 X 학생 자가 학습 + 다형성 compare 추상화 학생 자가 코드 예시 + 수익률 = GameResult 책임 (PR #142 결) + abstract → sealed class 학생 자가 변경 + sealed 라이브러리 배포 시 제약 reviewer 메타 어휘 + Profit 팩토리 메서드 자가 적용 + thisScore 외부 의존 → 본인 점수 자가 (Tell-Don't-Ask) + tailrec 자가 적용*
+- **양 단계 완성 reviewee** (1단계 #113 batch 21 분석 완료 + 2단계 #140 = batch 22 추가).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 자가 학습 의식 + 학생 자가 의문 5+ 회
+
+PR 본문:
+
+> *"제이든, 안녕하세요 :) 2단계 미션을 진행하면서 고민한 부분이 많아서 조금 늦어진 것 같아요 😂 이전 피드백도 #113 모두 반영하고자 노력했습니다!"*
+
+→ **학생 자가 학습 적극성 + 1단계 → 2단계 사이 학습 시간성** = PR #138·#142·#143 결 합류.
+
+### 2. 람다 4개 인자 폭증 학생 자가 의문 (PR #142 결과 동일)
+
+학생 자가 의문 (Thread 1):
+
+> *"하지만 변경해보니 고차함수를 `controller` → `BlackjackGame` → `Participants`로 넘기게 되었고, 너무 많이 넘겨주는 건 아닌가 싶어 해결할 방법도 고민해봤지만 방법을 찾지 못했습니다.. 😢 또한 4개의 매개변수도 많지 않나 싶었지만 플레이어와 딜러가 게임을 하려면 모두 필요한 정보여서 이렇게 구현하게 되었습니다."*
+
+reviewer 답변 (Thread 5):
+
+> *"여러 가지 방법이 있을 것 같아요*
+> *- onDraw 를 하나의 람다로 사용할 수 없을까?*
+> *- 불가능하다면 람다 매개변수를 묶어서 활용해볼 수 있을까?"*
+
+학생 자가 적용:
+
+```kotlin
+// onPlayerDraw + onDealerDraw 통합
+when (participant) {
+    is Player -> ...
+    is Dealer -> ...
+}
+```
+
+→ **람다 통합 = 타입 체크로 분기** + **`abstract class` → `sealed class` 학생 자가 변경 (when exhaustive)**. PR #142 (lambda-multiple-args-tuple-leak) 결 합류.
+
+### 3. 고차함수 = View 의존 X 학생 자가 학습
+
+reviewer (Thread 2):
+
+> *"고차함수는 View에 대한 직접적인 의존성을 제거하고, 추상화된 동작(람다)만을 전달받아 실행합니다. 따라서 도메인은 View의 구체적인 구현을 알 필요가 없기에 의존한다고 볼 수 없습니다. 고차함수를 사용함으로써 어떤 이점이 있었을까요?*
+> *- 특정 행동 추상화*
+> *- 전달받은 action 만 실행하므로 실제 내부 구현은 관심 X*
+> *- 테스트"*
+
+학생 자가 답변:
+
+> *"고차함수를 사용하면 도메인은 추상화된 행동만 전달받기 때문에 구체적인 구현을 알 수 없습니다! `Participant`의 입장에서는 단순히 `카드를 뽑았을 때 어떠한 행동을 해야 돼` 정도만 알 뿐, 그 행동이 어떤 것인지는 알지 못합니다. 또한, 테스트 코드에서는 `{ true }`와 같이 전달하면 되므로 view와 무관하게 테스트를 할 수 있고 테스트가 비교적 용이해집니다!"*
+
+→ **고차함수 = 추상화된 행동 + 테스트 용이성** = PR #109 (5 라운드 양방향 토론 + reviewer 자가 정정) 결 합류. **MCP 룰 `higher-order-function-as-domain-view-decoupling` 후보**.
+
+### 4. `abstract class` → `sealed class` 학생 자가 변경 (when exhaustive)
+
+학생 자가 적용 (Thread 5):
+
+> *"또한 이 과정에서 when 문에서 모든 하위 클래스를 처리할 수 있도록 `abstract class`였던 `Participant` 클래스를 `sealed class`로 변경했습니다."*
+
+reviewer (Thread 7): 외부글 (codestates 다형성 + stackoverflow interface/abstract/sealed 비교).
+
+학생 자가 답변:
+
+> *"`sealed class`로 구현하면 `Participant`를 상속하는 새로운 타입이 추가되었을 때, 컴파일 타임에 모든 하위 타입을 확인할 수 있어 더 안전하다고 생각했습니다..! 특히 `when` 문에서 모든 타입을 처리하도록 강제하고 예상치 못한 타입을 방지할 수 있다는 장점이 있다고 생각했는데, 혹시 제가 고려하지 못한 점이 있을까요..? 😯"*
+
+reviewer 메타 어휘 (Thread 13):
+
+> *"맞아요 sealed class 는 compiler 가 나머지 분기에 대해 처리하지 않아도 된다는 장점이 존재합니다. 그렇다면 포르가 이 블랙잭 미션을 라이브러리로 배포한다고 했을 때, 사용자들에게 Paricipant를 확장할 수 있도록 제공한다고 가정해본다면 어떤 일이 발생할 수 있을지 고민해볼까요?*
+>
+> *hint. 직접 패키지를 새로 만들어 Participant 를 확장해보기"*
+
+→ **sealed class 라이브러리 배포 시 사용자 확장 제약** = *sealed = 모듈 한정 = 외부 확장 X*. **MCP 룰 `sealed-class-library-extension-constraint` 후보**.
+
+PR #129·#126·#138·#142·#143·#113 결의 *sealed vs abstract vs open* 결 합류 정점.
+
+### 5. `Profit` 팩토리 메서드 + 자가 계산 (PR #142 cashOut 결 합류)
+
+```kotlin
+fun from(bettingAmount: BettingAmount, gameResult: GameResult): Profit =
+    Profit(bettingAmount * gameResult.rate)
+```
+
+→ **Profit 자가 계산 + 팩토리 메서드** = PR #142 `GameResult.cashOut(player)` 결 합류.
+
+### 6. operator overloading `times` 자가 적용
+
+```kotlin
+operator fun times(rate: Double): Double = value * rate
+```
+
+→ **value class + operator times** = PR #142·#36 결 합류.
+
+### 7. tailrec 자가 적용 + 학생 자가 어휘
+
+학생 자가 답변 (Thread 10):
+
+> *"새로 알게 된 `tailrec` 키워드를 활용하여 변경해보았습니다! 재귀로 호출하여 코드의 가독성을 높이면서, 컴파일 과정에서 while 문으로 변환하여 성능도 최적화할 수 있어 좋은 것 같습니다 👍🏻"*
+
+```kotlin
+tailrec fun playGame(draw: () -> Card, shouldContinue: ..., onDraw: ...) {
+    if (canHit() && shouldContinue(this)) {
+        receiveCard(draw())
+        onDraw(this)
+        playGame(draw, shouldContinue, onDraw)
+    }
+}
+```
+
+→ **`tailrec` 자가 학습 + 적용** = PR #138·#142 (rosemin928·doabletuple) 결 합류 누적 3+ PR.
+
+### 8. compare 공통 로직 추상화 + 학생 자가 코드 예시 (Thread 3)
+
+```kotlin
+// Participant.kt
+protected fun compare(thisScore: Score, otherScore: Score): GameResult =
+    when {
+        thisScore > otherScore -> GameResult.WIN
+        thisScore < otherScore -> GameResult.LOSE
+        else -> GameResult.DRAW
+    }
+```
+
+→ **공통 비교 로직 추출** = PR #142 (super 키워드) 결 합류.
+
+### 9. 추가 칭찬
+
+- Thread 8: *"중복 로직이 깔끔하게 없어졌네요 👍"*.
+- Thread 14: *"연산자 오버로딩을 잘 활용해주셨어요 👍"*.
+- Thread 15: *"입력받는 곳에서도 재귀를 잘 활용해주셨습니다 👍"*.
+- 모든 16 스레드 학생 자가 답변 + commit SHA.
+
+## 못한 점 (설계 관점)
+
+### 1. `thisScore` 외부 의존 → 본인 점수 자가 (Tell-Don't-Ask)
+
+reviewer (Thread 12):
+
+> *"thisScore 라는 값을 외부로 부터 받아야 할까요? 참가자는 본인의 점수를 알고 있습니다. '나'의 점수와 '상대방' 점수를 비교하면 되는 로직일거에요. 그렇다면 나의 점수도 외부 값에 의존해야 할까요? 또는 비교해야 할 대상이 늘어난다면 그만큼 함수 또는 파라미터가 늘어나야 할까요?.?*
+>
+> *자식클래스는 다른 참가자를 받는데 왜 부모클래스는 두 참가자를 받아야만 하는걸까요?"*
+
+→ **부모 클래스 두 점수 vs 본인 점수 자가** = *Tell-Don't-Ask 정공*. **MCP 룰 `parameter-vs-self-state-access` 후보**.
+
+### 2. sealed class 라이브러리 확장 제약 — §4 참조
+
+reviewer 의 메타 어휘 (Thread 13) = *sealed class 의 라이브러리 외부 확장 X 제약 = 사용자 확장 가능성 의식*.
+
+→ **라이브러리 사용자 시점 어휘** = PR #87·#76·#107·#82 (maintainer perspective locator) 결 + **사용자 확장 의식** 어휘 합류.
+
+**MCP 룰 `sealed-class-library-extension-constraint` 후보** — *sealed = 모듈 내부 + 라이브러리 배포 시 사용자 확장 X*.
+
+### 3. else 분기 처리 = 논리 오류 (Thread 6)
+
+reviewer (Thread 6):
+
+> *"현재 else 분기처리로 들어온다는 것은 어떤 오류에 해당할까요? 또한 어떤 방법으로 오류 대응을 할 수 있을까요?"*
+
+학생: *"추상 클래스를 사용했을 때 `else` 분기처리로 들어오는 상황은 예상하지 못한 타입이 들어왔을 때 발생하는 논리적 오류입니다. 이때 `IllegalArgumentException`와 같은 예외를 던져 대응할 수 있을 것입니다."*
+
+→ **else 분기 = 논리 오류** = PR #35 (Kotlin 예외 처리 4 원칙 - 논리 오류 시 예외) 결 합류.
+
+### 4. 테스트 범위 (Thread 16) — 역할 중심
+
+학생 자가 의문:
+
+> *"테스트 코드를 작성하는 과정에서, 어느 정도까지 테스트를 해야 하는지에 대한 의문이 생겼습니다. 현재 제 코드에서 게임 실행이 controller → BlackjackGame → Participants → Player 순서로 호출하여 진행됩니다. 테스트 코드를 전부 작성하지는 못했지만,, 각 클래스에서 게임 실행에 대한 테스트가 중복될 것 같은데, 어떤 범위까지 테스트를 작성해야 할지에 대한 조언을 구하고 싶습니다..!"*
+
+reviewer 답변:
+
+> *"먼저 각 클래스와 객체별로 역할을 중심으로 테스트를 작성하면 됩니다. (...) BlackjackGame: 게임 규칙과 진행을 관리하는 역할 → 게임 규칙과 주요 로직. Participants 및 Player: 개별 [...]"*
+
+→ **테스트 = 역할 중심 (PR #87·#129·#142·#109 결 합류)** = *MCP `oh-my-oop` 핵심 가치 (역할·책임·협력) 어휘 정점*.
+
+**MCP 룰 `test-by-role-not-by-flow` 후보** — *역할 중심 테스트 vs 흐름 중심 테스트*.
+
+### 5. `super` 키워드 학생 자가 답변 (Thread 8)
+
+reviewer: *"중복 로직이 깔끔하게 없어졌네요 👍 그렇다면 super 키워드에 대해 찾아보시면 더 도움이 될 것 같습니다 🙃"*
+
+학생 자가 답변:
+
+> *"부모 클래스인 `Participant`의 `compare` 함수는 두 참가자의 점수를 비교하는 연산을 하고, 자식 클래스의 `resultAgainst` 함수는 다른 참가자를 받아와 결과를 계산합니다. 두 함수의 함수 시그니처가 달라 super 키워드를 사용하지 않아도 되었던 것 같습니다..!"*
+
+→ **시그니처 차이 = super 활용 불필요** + *PR #142 결의 *시그니처 차이 추상화 한계* 어휘 합류*.
+
+### 6. `BlackjackResult` 클래스 - 게임 결과 + 수익 계산
+
+```kotlin
+// BlackjackResult - 수익 계산
+```
+
+→ **결과 통계 + 수익 계산 책임 분리** = PR #142 (Scoreboard) 결 합류. **MCP 룰 `result-aggregation-locator` 강화** 누적 3+ PR (#126·#142·#140).
+
+### 7. 모든 16 스레드 학생 자가 답변 + commit SHA — 2025 코호트 정점 유지
+
+## 대표 인용
+
+> [KwonDae Thread 2]
+> *"고차함수는 View에 대한 직접적인 의존성을 제거하고, 추상화된 동작(람다)만을 전달받아 실행합니다."*
+
+→ **고차함수 = 도메인 ↔ View 의존 X** — PR #109 결과 합류.
+
+> [KwonDae Thread 13]
+> *"그렇다면 포르가 이 블랙잭 미션을 라이브러리로 배포한다고 했을 때, 사용자들에게 Paricipant를 확장할 수 있도록 제공한다고 가정해본다면 어떤 일이 발생할 수 있을지 고민해볼까요?"*
+
+→ **라이브러리 배포 시점 메타 어휘** — *사용자 확장 의식*.
+
+> [KwonDae Thread 12]
+> *"thisScore 라는 값을 외부로 부터 받아야 할까요? 참가자는 본인의 점수를 알고 있습니다."*
+
+→ **Tell-Don't-Ask 어휘**.
+
+> [jiyuneel Thread 4]
+> *"참가자는 각자의 승패를 판단하고, `BlackjackResult`는 게임 결과를 바탕으로 수익 계산을 함으로써 각 객체의 책임이 분리되었습니다!"*
+
+→ **학생 자가 책임 분리 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **람다 4개 인자 폭증 학생 자가 의문 + reviewer 람다 통합 권유** — PR #142·#143 결 합류 + sealed class 변경.
+
+2. **고차함수 = 도메인 ↔ View 의존 X** — **MCP 룰 `higher-order-function-as-domain-view-decoupling` 후보**.
+
+3. **`abstract class` → `sealed class` 학생 자가 변경 (when exhaustive + 라이브러리 제약)** — **MCP 룰 `sealed-class-library-extension-constraint` 후보**.
+
+4. **`thisScore` 외부 의존 → 본인 점수 자가 (Tell-Don't-Ask)** — **MCP 룰 `parameter-vs-self-state-access` 후보**.
+
+5. **테스트 = 역할 중심** — **MCP 룰 `test-by-role-not-by-flow` 후보**.
+
+6. **tailrec 자가 적용** — 누적 3+ PR.
+
+7. **Profit 팩토리 메서드 자가 계산** — PR #142 결 합류.
+
+8. **operator overloading 자가 활용** — PR #36·#142 결.
+
+9. **else 분기 = 논리 오류** — PR #35 결.
+
+10. **결과 통계 + 수익 계산 책임 분리 (BlackjackResult)** — **MCP 룰 `result-aggregation-locator` 강화** 누적 3+ PR.
+
+## MCP 룰 후보 신규 + 강화 (PR #140)
+
+| 룰 | 신규 / 강화 | 누적 PR |
+|---|---|---|
+| `higher-order-function-as-domain-view-decoupling` | 신규 | 1 (#140) |
+| `sealed-class-library-extension-constraint` | 신규 | 1 (#140) |
+| `parameter-vs-self-state-access` | 신규 | 1 (#140) |
+| `test-by-role-not-by-flow` | 신규 | 1 (#140) |
+| `tailrec-optimization-applicability` | 강화 | 3+ (#138·#142·#140) |
+| `result-aggregation-locator` | 강화 | 3+ (#126·#142·#140) |
+| `super-keyword-for-shared-logic` | 강화 | 3+ (#138·#142·#140) |
+| `sealed-vs-abstract-vs-open-locator` | 강화 | 7+ |
+| `kotlin-exception-handling-strategy` | 강화 | 5+ |
+
+## 비교 (PR #113 → #140)
+
+- **1단계 #113 22 thread → 2단계 #140 16 thread**.
+- **1단계 #113 Hit/Stay Boolean → 2단계 #140 sealed class 학생 자가 변경**.
+- **1단계 #113 Players 일급 컬렉션 사용자 입력 한계 자가 의문 → 2단계 #140 고차함수 자가 학습**.
+- **1단계 #113 BlackjackGame 도메인 객체 자가 적용 → 2단계 #140 BlackjackResult + Profit 책임 분리**.
+- **2단계 #140 학생 자가 학습 정점 유지** (commit SHA + 자가 의문 5+ 회).