oh-my-oop 0.2.0

package/lessons/STYLE_GUIDE.md

@@ -0,0 +1,304 @@
+# OOP 설계 스타일 가이드
+
+`woowacourse/kotlin-racingcar` 133개 PR 리뷰에서 추출한 보편 원칙 모음. MCP의 자동 검증(`oop_design_validate`)이 잡지 못하지만 **워크숍/리뷰에서 안내할 만한** 규칙들.
+
+자세한 사례는 [lessons/woowacourse-racingcar/SUMMARY.md](woowacourse-racingcar/SUMMARY.md) 참고.
+
+---
+
+## 1. 명명 원칙
+
+### 1-1. 함수 이름 = 동사 하나만
+
+- 안 됨: `executeInputTryNumber()`, `setRacingResult()`, `runOrStop()`
+- 됨: `inputTryNumber()`, `tryMove()`, `stop()`
+
+> "이 함수에는 동사가 2개가 존재합니다. (input, try) 함수에는 하나의 동사만 포함시켜보면 어떨까요?" — @BeokBeok ([PR #68](woowacourse-racingcar/hyemdooly/68-1단계-자동차-경주.md))
+
+### 1-2. 이름의 *오해 비용* 최소화
+
+- `XxxException` 접미사는 **Exception 타입**을 의미. 검증 객체에 붙이면 동료 혼란.
+- `XxxValidator` / `XxxValidation` 으로.
+- `Manager`, `Helper`, `Util`은 거의 항상 god-object 신호 (자동 검증 `vague-class-name` 룰로도 잡힘).
+
+### 1-3. 상수 이름 = 의미, 값이 아님
+
+- 안 됨: `","`, `STANDARD_NUMBER`, `MAX = 5`
+- 됨: `NAME_DELIMITER`, `MOVEMENT_THRESHOLD`, `MAX_NAME_LENGTH`
+
+> "STANDARD_NUMBER는 자동차 경주 게임에 대한 지식이 없는 사람이 보았을 때도 한 번에 알아볼 수 있는 의미를 담은 이름일까요?" — @malibinYun ([PR #145](woowacourse-racingcar/etama123/145-2단계-자동차-경주.md))
+
+### 1-4. 메서드명에 컨텍스트 중복 금지
+
+- 안 됨: `NumberGenerator.generateNumber()` (Generator + generateNumber → 동어반복)
+- 됨: `NumberGenerator.generate()`
+
+---
+
+## 2. 메시지와 에러
+
+### 2-1. 메시지 상수에 매직넘버 박지 말 것
+
+```kotlin
+// 안 됨 — 요구사항 변경 시 두 곳 수정
+const val ERROR = "이름은 1~5글자여야 합니다"
+
+// 됨 — 한 줄 수정으로 끝
+const val MIN_LEN = 1
+const val MAX_LEN = 5
+val errorMsg = "이름은 $MIN_LEN~${MAX_LEN}글자여야 합니다"
+```
+
+> "1, 5와 같은 내용이 상수 문자열에 포함될 경우, 요구사항의 변경에 따라 항상 수정이 필요하게 됩니다." — @vagabond95
+
+### 2-2. 에러 메시지에 *입력값*을 담아라
+
+운영 디버깅의 거의 무료 정보. "잘못된 입력" 대신 "잘못된 입력 'foo bar baz'".
+
+### 2-3. 에러 케이스별로 구분된 메시지
+
+같은 공통 메시지로 통합하면 어느 경로 실패인지 모름.
+
+---
+
+## 3. 검증 책임의 3분류
+
+> **이 원칙은 MCP의 `validation-misplacement` 룰로도 자동 검증된다.**
+
+| 검증 종류 | 자리 | 예시 |
+|---|---|---|
+| UI 형식 검증 | Interfacer (View) | 빈 문자열, 숫자 아님, 형식 |
+| 사용자 입력 정책 | Coordinator | 재입력 흐름, 종료 조건 |
+| 도메인 무결성 invariant | InformationHolder / Structurer init | 이름 길이, 자동차 두 대 이상, 중복 |
+
+`require()` / `check()`를 도메인 init에 두면 invariant 보호가 자동.
+
+---
+
+## 4. 의존 방향
+
+> **MCP의 `dependency-direction` 룰로 자동 검증.**
+
+- **Domain은 UI/Interfacer를 모른다.** Validator가 OutputView를 의존하면 의존 역전.
+- Coordinator만 Interfacer 협력 허용.
+- 더 엄격: 인터페이스를 Domain에서 정의, Interfacer가 구현 (DIP).
+
+---
+
+## 5. 책임의 3층 구조 (체스 비유)
+
+> @KwonDae ([PR #125](woowacourse-racingcar/Hogu59/125-2단계-자동차-경주.md))
+
+- **유저(Controller)** = 명령만 (이 말을 저기로)
+- **체스판(RacingGame)** = 상태 + 명령 해석 (체스판 위에서 일어나는 모든 일)
+- **말(Car)** = 자기 위치 + 자기 행위 (앞으로 한 칸)
+
+Controller가 "이 말이 어디로 가야 할지" 판단하면 체스판의 책임이 Controller로 누수된 것.
+
+---
+
+## 6. 자가 점검 질문
+
+설계 결정마다 던질 질문 (실제 리뷰어들이 던진 질문):
+
+### 6-1. "이 클래스의 책임을 한 문장으로 적어보세요"
+
+> "단일 책임 원칙이 어긋나 있는지 확인하는 좋은 방법 중 하나는, 이 클래스의 역할과 책임이 무엇인지 한 문장으로 적어보는 것입니다." — @ghojeong
+
+문장이 모호하거나 길면 SRP 위반.
+
+### 6-2. "휴가 가도 동료가 일할 수 있는 코드인가?"
+
+함수명 + 시그니처만 보고 동료가 같은 일을 할 수 있는가 = SRP 검사법.
+
+> "업계에 떠도는 맨날 야근하는 개발 조직 괴담이 역할과 책임이 명확하지 않은 함수, 클래스, 혹은 모듈로 인해서 생긴다고 생각해주세요." — @ghojeong
+
+### 6-3. "이 분리가 테스트를 더 명확하게 만드는가?"
+
+> **MCP의 `propose_alternatives`가 모든 대안에 이 질문을 첨부함.**
+
+분리해도 테스트가 더 명확해지지 않으면 분리할 이유 없음. 분리의 정당화는 테스트 개선이 와야 한다.
+
+### 6-4. "도메인이 N배로 늘면 이 구조가 견디는가?"
+
+> **MCP의 `propose_alternatives`가 모든 대안에 이 질문을 첨부함.**
+
+확장 시나리오 압박 시뮬레이션. KoreanCar/EnglishCar로 늘어도, 상수 1000개로 늘어도, 자동차 1000대로 늘어도.
+
+### 6-5. "무슨 객체가 개선되었나?"
+
+> "객체지향 패러다임에 들어맞느냐라는 질문에는 제가 아니라 심지님 스스로, 무슨 '객체' 가 개선되었는지 답할 수 있으면 됩니다." — @ghojeong ([PR #115](woowacourse-racingcar/sh1mj1/115-2단계-자동차-경주.md))
+
+---
+
+## 7. Tell-Don't-Ask 응용
+
+### 7-1. 외부에서 getter로 묻고 비교하지 말 것
+
+```kotlin
+// 안 됨 — feature-envy
+val maxPos = cars.maxOf { it.position }
+cars.filter { it.position == maxPos }.map { it.name }
+
+// 됨 — 일급 컬렉션에 메시지
+cars.findWinners().map { it.name }
+```
+
+### 7-2. element가 스스로 상태 변경하면 컬렉션은 immutable
+
+```kotlin
+// 안 됨 — 매번 새 컬렉션
+class Cars(val value: List<Car>) {
+    fun moveAll() = Cars(value.map { it.copy(position = it.position + ...) })
+}
+
+// 됨 — element가 자기 상태 변경
+class Cars(val value: List<Car>) {
+    fun moveAll() = value.forEach { it.move(...) }
+}
+```
+
+> @vagabond95 ([PR #92](woowacourse-racingcar/kmkim2689/92-1단계-자동차-경주.md))
+
+### 7-3. depth 줄이기 = 함수 분리 ≠ 재귀로 indentation 감추기
+
+> "depth 를 이야기할 때, 쉬운 설명을 위해서 indentation 을 이야기하지만, 엄밀히 이야기하면 abstraction level 을 뜻합니다." — @ghojeong
+
+재귀로 들여쓰기만 줄이면 abstraction level은 그대로. **함수 분리**로 abstraction level을 낮춰야 SRP가 살아남.
+
+---
+
+## 8. 외부 비결정성 분리
+
+> **MCP의 `non-newable` 룰로 자동 검증.**
+
+`Random`, `Clock`, `System` 같은 외부 자원은 *도메인에 직접 의존*하지 말 것.
+
+**패턴:**
+1. `interface NumberGenerator { fun generate(): Int }` 또는 `fun interface MoveStrategy { fun isMovable(): Boolean }`
+2. 도메인은 인터페이스만 의존
+3. 프로덕션은 `RandomNumberGenerator` 구현체 주입
+4. 테스트는 `FakeGenerator(values: List<Int>)` 같은 결정적 fake 주입
+
+함수형 인터페이스 (Kotlin `fun interface`)는 람다로도 구현 가능해 경량.
+
+---
+
+## 9. 캡슐화 패턴
+
+### 9-1. `var position; private set`
+
+```kotlin
+class Car(val name: String) {
+    var position: Int = 0
+        private set
+    fun move() { position++ }
+}
+```
+
+원시값은 이게 가장 간결. backing property는 컬렉션의 mutable/immutable 분리 시에만.
+
+### 9-2. data class + var는 위험
+
+`equals/hashCode`가 주생성자 프로퍼티만 보는데 var면 동치성이 깨질 수 있음. data class는 immutable VO가 본업.
+
+### 9-3. 단일 값 wrapper = value class
+
+```kotlin
+@JvmInline value class Position(val value: Int) {
+    init { require(value >= 0) }
+}
+```
+
+data class보다 인라인되어 런타임 오버헤드 없음.
+
+### 9-4. 정규화는 팩토리 함수, 주 생성자는 검증된 값만
+
+```kotlin
+class CarName private constructor(val value: String) {
+    init { require(value.isNotBlank() && value.length <= 5) }
+    companion object {
+        fun of(raw: String) = CarName(raw.trim())
+    }
+}
+```
+
+주 생성자가 trim까지 하면 "객체 생성 시 입력이 어떻게 변형되는가"가 불투명.
+
+---
+
+## 10. 테스트
+
+### 10-1. 테스트 함수명 = 시나리오 + 결과
+
+- 안 됨: "정상 동작한다", "예외가 발생한다"
+- 됨: `randomNumber가 4 이상이면 자동차가 움직인다`, `자동차 이름은 5자를 초과할 수 없다`
+
+### 10-2. 테스트 setup은 우회 메서드 없이
+
+Car의 위치를 5로 만들기 위해 `tryMove()`를 5번 호출하지 말 것. 생성자에 직접 받기.
+
+### 10-3. 분기 들어가면 두 테스트로 쪼개라
+
+테스트 코드에 `if/when`이 나오면 그건 두 케이스를 한 함수에 담은 것.
+
+### 10-4. 자기가 구현 안 한 부분은 자기가 테스트 안 한다
+
+`Random.nextInt`, `String.split` 같은 표준 라이브러리는 단위 테스트 대상이 아님.
+
+### 10-5. 테스트가 *깨지지 않게* 보편화하는 것 vs 요구사항 바뀌면 갈아엎기
+
+> "제 입장에서 테스트 코드란 구현해야할 요구 사항이지, 요구사항에 대한 구현체가 아니기 때문입니다." — @ghojeong
+
+지나친 보편화 ("기준 숫자 이하")는 미래의 자기 통제권을 줄임. 요구사항 바뀌면 테스트도 바꿔라.
+
+### 10-6. Controller는 단위 테스트 X (통합 테스트로)
+
+> "컨트롤러는 UI나 콘솔과 같이 실행에 밀접한 관련이 있기 때문에 일반적으로 단위 테스트를 작성하지는 않습니다." — @laco-dev
+
+도메인 테스트에 집중.
+
+---
+
+## 11. 객체 vs 함수
+
+> **MCP의 `function-not-object` 룰로 자동 검증.**
+
+- **객체 = 메서드 + 멤버 둘 다**. 멤버 없이 함수 하나만 가진 클래스는 객체 아님 → top-level fun 또는 object의 메서드로.
+- **상태 없는 클래스 = object**. 인스턴스마다 다른 상태가 필요할 때만 class.
+
+---
+
+## 12. DI는 키워드가 아니라 역할-책임-협력
+
+> "DI 라는 키워드에 집착하기 보다는, NumberGenerator 와 의존관계를 가질 class 가 누가 되어야 하는지, 역할과 책임 관점에서 생각을 해보시면 좋을 것 같습니다." — @ghojeong ([PR #107](woowacourse-racingcar/sh1mj1/107-1단계-자동차-경주.md))
+
+조영호 "객체지향의 사실과 오해" 3요소 = **역할, 책임, 협력**. DI는 그 결과.
+
+---
+
+## 13. 커밋과 PR
+
+- 커밋 단위 = 의미 단위. "스켈레톤 코드 작성" 같은 무의미한 커밋 회피.
+- 같은 메시지의 중복 커밋 = 책임 단위 모호의 신호.
+- 자가 의문/결정 이유를 PR 본문에 명시. 리뷰어가 더 깊은 토론으로 응답.
+- 페어 프로그래밍의 가치 = 토론이 PR에 보임.
+
+---
+
+## 14. 출력 책임
+
+- **toString이 도메인에 출력 형식 보유 X** — OutputView 책임 침범. (단, 안드로이드 UI 모델은 회색지대)
+- **enum의 데이터에 UI 표현(`"-"`) 박지 말 것** — UI 변경이 도메인 변경. (MCP의 `side-effect-in-holder` 룰이 잡음)
+- **출력 책임 일원화** — Service/도메인/Controller 어디든 출력 문구가 생기면 OutputView로 옮기기.
+
+---
+
+## 부록: 리뷰어 명언 베스트
+
+1. *"객체지향 패러다임은 사실 별로 안 중요합니다. 불편함을 스스로 인지하고, 인지한 부분을 다시 스스로 해결하는 과정이 제일 중요합니다."* — @ghojeong
+2. *"네이밍이 모호하다는 것은 곧 해당 클래스/함수의 역할이 모호하거나 모호해질 수 있다는 신호입니다."* — @vagabond95
+3. *"객체에게 메시지만 던져 자동차 스스로 판단해 움직일지 말지 역할을 부여하세요."* — @KwonDae
+4. *"테스트하기 쉬운가?를 기준으로 객체를 쪼개고 합칩니다."* — @ghojeong
+5. *"객체는 메서드 뿐만 아니라 멤버로도 구성된다는 사실을 잊지 말아주세요."* — @ghojeong
+6. *"처음에 최대한도로 세분화하라는 조언은, 보통 합쳐진것을 쪼개는 리팩토링 보다, 쪼개진 것을 합치는 리팩토링이 더 쉽기 때문입니다."* — @ghojeong

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

@@ -0,0 +1,293 @@
+# PR #33 — [블랙잭 1단계] 멧돼지 미션
+
+- **Reviewee:** [@2chang5](https://github.com/2chang5)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/33
+- **단계:** 1단계 (페어)
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 30 (리뷰어 19 / 리뷰이 11)
+
+## 잘한 점 (설계 관점)
+
+- **`CardBunch private constructor + vararg`** + `validateSize()`로 초기 카드 수 invariant.
+- **`Set<Card>` 중복 차단 — `validateSize` + `addCard` 중복 검사**.
+- **`Participant` 인터페이스 + `Player`/`Dealer` 구현** — 공통 추상화.
+- **`Shape.korean` 분리 (`OutputView`에서 직접 매핑)** — 카드 출력 책임이 OutputView로.
+- **`Participants` 일급 컬렉션 + `progressPlayersAddCard(getDecision, printPlayerCard)` callback** — 진행 로직 응집 (못한 점 §10 참고).
+- **후속 반영 — `CardNumber.value: Int?` (Ace null) → 명시 처리 / Ace 보정 단순화 / Set 중복 허용 / OutputView when 단순화**.
+
+## 못한 점 (설계 관점)
+
+### 1. `CardNumber.value: Int?` Ace를 null로 표현 — 직관성 ↓
+
+```kotlin
+enum class CardNumber(val value: Int?) {
+    ACE(null),
+    TWO(2), THREE(3), ..., KING(10);
+}
+```
+
+리뷰어: "*ACE의 value를 null처리되는 구현부를 보기전에는 예상하지 못하고, 직관적이지 않은거 같아요* ㅠ,ㅠ *점수 계산할때 isAce로 체크해서 따로 관리하는게 좀더 직관적*이지 않을까요?"
+
+학생 자가 인정: "*뭔가 null 을 새롭게 이용해보자는 목표를 가져봤는데 오히려 직관적이지 못했던것 같네요*🐗 수정해보겠습니다!!!!" — **`null = 특수 케이스 표현`은 호출자가 매번 `?:` 처리**. `value: Int = 1` + `isAce: Boolean` 가 의도 명확. *기능 시도 욕구*가 *가독성 비용*을 만든 패턴 (PR #29·#65·#135와 같은 결).
+
+### 2. `CardBunch.getTotalScore()` — `sortedBy + reversed + checkAceValue` 복잡
+
+```kotlin
+fun getTotalScore(): Int {
+    var result = 0
+    val sortedCards = cards.sortedBy { it.cardNumber.value }.reversed()
+    sortedCards.forEach {
+        result += it.cardNumber.value ?: checkAceValue(result)
+    }
+    return result
+}
+```
+
+리뷰어: "*순서에 따라 checkAceValue에 파라미터가 변경되기 때문에, 몇몇 케이스에서는 실패할 가능성도 있어요!* Ace,Ace,King. *ace를 1 계산하고, Sum의 결과값에 따라 +10 추가 하는방식*등으로 단순화할수 있을거 같아요!" — **순서 의존 알고리즘이 *Ace 두 장 케이스*에서 실패**. 정렬 후 Ace를 마지막에 두는 트릭은 *Ace 두 장이면 첫 Ace가 11, 둘째 Ace도 11로 결정 → Bust*. *Ace 합 계산 알고리즘*은 *순서 무관 단일 룰*(*Ace 있으면 +10이 21 이하면 +10*)이 정답. PR #10·#79·#114·#28과 같은 결.
+
+### 3. `Player.consequence: lateinit var` — *상태 캐싱 + 사이드 이펙트*
+
+```kotlin
+class Player(val name: String, override val cardBunch: CardBunch) : Participant {
+    lateinit var consequence: Consequence
+    fun chooseWinner(score: Int) {
+        val playerScore = cardBunch.getTotalScore()
+        consequence = if (playerScore > MAX_SCORE_CONDITION) Consequence.LOSE
+        else if (playerScore > score) Consequence.WIN
+        ...
+    }
+}
+```
+
+리뷰어: "*consequence를 초기화하지 않았는데 접근하거나, cardBunch에 따라 결정되는 값으로, chooseWinner가 실행시점에 다라 다른값을 캐싱*할수 있을 것 같아요. *상태값을 불필요하게 들고 있기보다, 결과값을 반환*해주면 어떨까요?" — **`lateinit + 사이드 이펙트 setter`는 *호출 순서 invariant 누락*** + *cardBunch가 변하면 consequence가 stale*. `fun chooseWinner(score: Int): Consequence` 반환이 자연. PR #114·#29·#92와 같은 결.
+
+### 4. `Player.chooseWinner` 다중 `if/else if` — when 활용 미흡
+
+```kotlin
+consequence = if (playerScore > MAX_SCORE_CONDITION) Consequence.LOSE
+else if (playerScore > score) Consequence.WIN
+else if (playerScore == score) Consequence.DRAW
+else if (score > MAX_SCORE_CONDITION) Consequence.WIN
+else Consequence.LOSE
+```
+
+리뷰어: "*if else 문외에 when을 활용해보면 어떨까요?* when, if-else는 어느경우에 쓰는게 좋을까요? 가볍게 읽어보면 좋을거같아요! https://kotlinlang.org/docs/coding-conventions.html#if-versus-when"
+
+학생 자가 변호: "*조건이 비교연산자가 들어있는 식이라 when을 사용할수 있는 방법을 찾지못하여* if문을 사용하였습니다 ㅠㅠㅠ. [...] 단순 *else문이 안들어갔다 뿐 차이점이 전혀 없다고 생각*하여 이또한 문제가 있는 코드라고 생각합니다."
+
+리뷰어: "*비교연산자도 when 을 활용할 수 있습니다!* ```when { playerScore > MAX_SCORE_CONDITION -> Consequence.LOSE; playerScore > dealerScore -> Consequence.WIN; ... else -> ... }```" — **Kotlin `when` 조건문 = if/else 분기의 표현력 향상**. *비교 연산자도 가능*함을 학생이 몰랐던 *문법 미숙*.
+
+### 5. `CardDeck` 정적 메서드 + 그 외 멤버 없음
+
+```kotlin
+class CardDeck() {
+    companion object {
+        private val Cards: List<Card> = Shape.values().fold(listOf()) { cards, shape -> cards + makeCard(shape) }
+        private fun makeCard(shape: Shape): List<Card> = CardNumber.values().map { Card(shape, it) }
+        fun drawCard(): Card = Cards.shuffled().first()
+    }
+}
+```
+
+리뷰어: "*내부에 companion object밖에없는 클래스라면, 객체화가 의미가 없을거 같아요! object 를 사용해보면 어떨까요?*" / "*카드를 뽑게되면, 뽑은 카드는 줄어들어야하지 않을까요?*"
+
+→ **세 가지 문제 한꺼번에**:
+1. `class CardDeck()` no-arg + 모든 멤버 companion = *object 또는 top-level fun*이 자연.
+2. `Cards.shuffled().first()` = *매 호출마다 셔플 + 첫 카드*. **카드 소진 X** → 동일 카드 무한 반복 가능.
+3. 학생이 *덱 = 정적 상수* 가정으로 *상태 변화 부재*.
+
+PR #65 (kmkim2689) Singleton + 재귀 / PR #79 (ii2001) Singleton과 같은 결.
+
+### 6. `CardDeck` Singleton + `Participants`가 직접 호출 — 강한 의존
+
+```kotlin
+class Participants(names: List<String>) {
+    val dealer: Dealer = Dealer(makeCardBunch())
+    private fun makeCardBunch(): CardBunch = CardBunch(CardDeck.drawCard(), CardDeck.drawCard())   // ⚠ static call
+    private fun positiveGetCard(player: Player, ...) {
+        player.cardBunch.addCard(CardDeck.drawCard())   // ⚠ static call
+    }
+}
+```
+
+리뷰어: "*CardDeck을 싱글턴으로 접근하게 되면, 어떤 단점이 있을까요?* *CardDeck을 싱글턴으로 사용하는 Participants에서 CardDeck에 대한 강한 의존이 생긴것 같아요!*"
+
+학생 자가 인정: "*테스트하기도 힘들고 변화에 대응하기도 힘들것같습니다.* 이부분에서 *테스트를 아직 진행하지않아서 필요성에의해서 추상화와 분리를 시도해보려 했는데 떄가 된것 같습니다!!!*" — **Singleton = 의존성 주입 못 함 = 테스트 격리 ↓**. 학생 자가 깨달음.
+
+### 7. `Controller`가 `player.cardBunch`에 직접 접근
+
+```kotlin
+private fun makeCardBunch(): CardBunch = CardBunch(cardDeck.drawCard(), cardDeck.drawCard())
+private fun askGetCard(player: Player) { ... player.cardBunch.addCard(cardDeck.drawCard()) ... }
+```
+
+리뷰어: "*player의 cardBunch에게 접근하지 말고, player에게 카드를 받을수 있는 상태인지 확인*하면 어떨까요? *좀더 객체지향적인 코드*가 될거같아요!" — *Tell-Don't-Ask*. `player.canReceiveCard()` + `player.receiveCard(card)`. PR #29·#114·#92·#65·#28과 같은 결.
+
+### 8. `Participants` 책임 비대 — *진행자 역할까지 흡수*
+
+```kotlin
+class Participants(names: List<String>) {
+    val dealer: Dealer = ...
+    val players: List<Player> = ...
+    fun progressPlayersAddCard(getDecision, printPlayerCard) { ... }
+    fun progressEachPlayerAddCard(...) { ... }
+    fun progressEachTurn(...) { ... }
+    fun positiveGetCard(...) { ... }
+}
+```
+
+리뷰어: "*Participants에 대한 책임이 많이 모여있는것으로 보여요!* 참가자를 관리하는것 외에도, *각자의 턴을 진행하고, 카드를 뽑는등 사실상 BlackJack게임에 대한 전반적인 책임 또한 있는*것 같아요! *책임을 분리하는 방법을 고민*해보아도 좋을거 같아요! 해당 *클래스들의 테스트코드를 작성해보셔도* 좋을거같아요!" — *Participants*가 *컬렉션 일급* + *진행자 역할*까지 흡수. `BlackJackGame` 같은 *진행자 별도 객체*가 자연. PR #92 `runBlackJackGame` 흐름 응집과 같은 결.
+
+### 9. `Participants`의 *callback 인자 폭증*
+
+```kotlin
+fun progressPlayersAddCard(getDecision: (Player) -> Boolean, printPlayerCard: (Player) -> Unit) { ... }
+fun progressEachTurn(player, getDecision: (Player) -> Boolean, printPlayerCard: (Player) -> Unit): Boolean { ... }
+```
+
+PR #65 (kmkim2689)·#28과 같은 *callback 폭증*. *도메인 함수가 View 함수 reference를 받음* = *도메인 → View 의존*.
+
+### 10. `Dealer.compareScore(playerScore: Int): Consequence` — *Int 비교*
+
+```kotlin
+class Dealer(override val cardBunch: CardBunch) : Participant {
+    fun compareScore(playerScore: Int): Consequence {
+        val dealerScore = cardBunch.getTotalScore()
+        if (playerScore > MAX_SCORE_CONDITION) return Consequence.LOSE
+        ...
+    }
+}
+```
+
+`compareScore(playerScore: Int)`는 *Int를 받음*. PR #125·#10·#28과 같은 *상대를 Int로 받음 = 동일 추상에 메시지 못 보냄*. `dealer.compareScore(player: Player)` 또는 *Tell-Don't-Ask로 `player.match(dealer)`*.
+
+### 11. `Dealer`와 `Player` 추상화 공유 부족
+
+리뷰어: "*플레이어와 딜러가 어떤 공통점이 있고, 어떤 부분을 추상화하면 좋을지 고민*해보셔도 좋을거같아요!" — `Participant` 인터페이스에 *cardBunch*만 있고 *행위*는 거의 없음. *공통 행위 (점수 계산, 카드 받기)*를 추상화하면 *Participants가 균등 처리*.
+
+### 12. `OutputView`에 *카드 출력 매핑 + 결과 카운트 + 승패 계산* 혼재
+
+```kotlin
+private fun printDealerResult(participants: Participants) {
+    val result = mutableListOf(0, 0, 0)
+    participants.players.forEach { player ->
+        result[decideDealerResult(participants.getConsequence(player))]++
+    }
+}
+```
+
+리뷰어: "*딜러 승패를 계산하는것은 View가 아닌 도메인의 책임으로 볼수도 있을것 같아요!*" — *View 안에서 결과 집계*. *View = 표현만*. *집계는 도메인* (`Map<Player, Consequence>` + groupBy).
+
+또 `DEALER_WIN = 0` / `DEALER_LOSE = 1` / `DRAW = 2` 같은 *인덱스 상수*로 *3원소 리스트* 다루기 = *enum + map 자연 표현* 회피.
+
+### 13. `CardBunchTest` 케이스명 — *given/when/then 부재*
+
+```kotlin
+@Test fun `같은 카드를 받으면 에러가 발생한다`() { ... }
+```
+
+리뷰어: "*케이스명도 구체적으로 작성*해보면 어떨까요? 저는 *GIVEN,WHEN,THEN으로 분리*하여 사용하곤합니다. *"서로 다른 카드로, 카드 뭉치를 생성하면, 에러가 발생하지 않는다" "(Given), (When), (Then)"* 좀더 직관적이고 명확한 테스트 케이스" — *시나리오 라벨 → 시나리오 + 결과 + 조건*.
+
+### 14. `CardBunch.constructor(vararg cards: Card)` *초기 2장 invariant* — *2장만 강제* 과잉
+
+```kotlin
+constructor(vararg cards: Card) : this(cards.toMutableSet()) {
+    validateSize()
+}
+private fun validateSize() {
+    require(_cards.size == INITIAL_CARD_SIZE) { INITIAL_SIZE_ERROR }
+}
+```
+
+리뷰어: "*이부분도 개인적인 생각이니 참고만해주셔도 되요, player의 게임시작 후, 카드 2장을 받게되는것으로, 초기값이 2장일수 있지만, 2장의 카드로만 초기화할수 있는 부분은 불필요한거 같단 생각이 들어요*" — `CardBunch`가 *2장으로만 초기화*면 *테스트 시 다른 시나리오*(예: 1장 받은 시점)가 *생성 불가*. *초기 2장 invariant*는 *Player/Dealer 생성 흐름*에 두는 것이 자연. `CardBunch` 자체는 *0~∞장* 허용.
+
+### 15. `DealerTest`에서 *Player 함수 검증*
+
+```kotlin
+class DealerTest {
+    @Test fun `플레이어가 카드를 추가로 받을지 결정한다`() { ... }
+}
+```
+
+리뷰어: "*dealerTest에서는 dealer 테스트에 집중*해보아요! *player 함수는 PlayerTest에서 검증*해보아요!" — *테스트 대상 ≠ 테스트 시나리오*. PR #116 `HandsTest`에 Player 등장과 같은 결.
+
+### 16. *Set 중복 차단*과 *카지노 룰* 충돌
+
+```kotlin
+class CardBunch ... {
+    fun addCard(card: Card) {
+        val originSize = _cards.size
+        _cards.add(card)
+        require(originSize != _cards.size) { DUPLICATE_ERROR }
+    }
+}
+```
+
+리뷰어: "*블랙잭은 보통 여러 카드덱 세트를 혼합하여 사용하기 때문에, 중복된 카드도 허용*할수 있긴해요!" / "*카드Deck의 종류에 따라서는, 카드뭉치도 같은 카드를 받을수 있지않을까요?* 실제 카지노에서 *블랙잭은 보통 3~4개의 카드 세트를 덱*으로 ..."
+
+학생 자가 인정: "중복을 허용하도록 변경하였습니다!!!" — **현실 블랙잭 룰 정확 이해**. *학생의 invariant*가 *도메인 룰을 좁게 해석*. *카지노 = 6~8덱 슈*. PR #112·#128 *블랙잭 룰 오해*와 같은 결.
+
+### 17. `Dealer.compareScore`에 *블랙잭 룰 누락* — Ace + 10 두 장만 블랙잭
+
+리뷰어: "*BlackJack승패에 대한 조건에 Ace와 10 ( = 10,K,Q,J) 단 두장으로만 21이 되면, 블랙잭이 됩니다. 블랙잭과 3장 이상의 조합으로 21의 숫자와 승패를 결정하면 블랙잭이 승리를 하게됩니다.* 이런 룰을 추가해보셔도 좋을거같아요!" — **블랙잭의 핵심 룰**: 21점 == 블랙잭이 아님. *2장으로 21 = 블랙잭*, *3장 이상으로 21 = 일반 21*. 학생 코드는 *21점이면 모두 동치*. PR #128·#10·#92와 같은 결.
+
+### 18. `CardBunch.getTotalScore`에 *Ace 단 1회 +10* 룰 미적용
+
+리뷰어: "*Ace가 여러장 있더라도, ACE_SCORE_GAP은 단 1회만 체크하여 추가*해주면 될거같아요! *Ace가 두장이상일 경우에도 11로 두번이상 계산된다면 22가 되기떄문이예요!*" — 학생 후속: 적용. PR #10·#79 권고와 동일.
+
+## 리뷰어 의견 요지
+
+- ***`CardNumber.value: Int?` Ace null = 직관성 ↓, 호출자 매번 `?:`*** — `isAce: Boolean` 분리.
+- ***Ace 보정 순서 의존 알고리즘 = Ace 두 장 케이스 실패*** — *Ace 있으면 +10이 21 이하*면 단일 룰.
+- ***`lateinit consequence` + 사이드 이펙트 setter < 결과 반환***.
+- ***Kotlin when 조건문은 비교 연산자도 가능***.
+- ***`CardDeck` companion만 있는 class = object 또는 top-level fun***.
+- ***`Cards.shuffled().first()` = 카드 소진 X = 무한 반복***.
+- ***Singleton → 강한 의존*** — 테스트/변화 대응 ↓.
+- ***Controller가 `player.cardBunch.addCard`에 직접 접근*** — Tell-Don't-Ask.
+- ***`Participants`가 진행자 역할까지 = 책임 비대*** — `BlackJackGame` 별도.
+- ***Callback (`getDecision`, `printPlayerCard`) 폭증 = 도메인 → View 의존***.
+- ***`compareScore(Int)` < `compareTo(player: Player)`*** — 동일 추상 메시지.
+- ***Dealer/Player 공통 추상 = `Participant` 행위 보강***.
+- ***View가 승패 계산 = 도메인 책임 누수***.
+- ***테스트 케이스명 = GIVEN/WHEN/THEN 또는 시나리오 + 결과***.
+- ***`CardBunch` *2장만 강제 invariant*는 다른 시점 생성 불가***.
+- ***DealerTest에 Player 함수 = 테스트 대상 ≠ 시나리오***.
+- ***블랙잭 = Ace + 10 두 장만 (3장 이상 21은 일반 21)***.
+- ***Set 중복 차단 = 카지노 6~8덱 룰과 충돌***.
+
+## 대표 인용
+
+> *순서에 따라 checkAceValue에 파라미터가 변경되기 때문에, 몇몇 케이스에서는 실패할 가능성도 있어요!* Ace,Ace,King. *ace를 1 계산하고, Sum의 결과값에 따라 +10 추가 하는방식*등으로 단순화할수 있을거 같아요!
+> — @namjackson on `CardBunch.kt`
+
+> *consequence를 초기화하지 않았는데 접근하거나, cardBunch에 따라 결정되는 값으로, chooseWinner가 실행시점에 다라 다른값을 캐싱*할수 있을 것 같아요. *상태값을 불필요하게 들고 있기보다, 결과값을 반환*해주면 어떨까요?
+> — @namjackson on `Player.kt`
+
+> *CardDeck을 싱글턴으로 접근하게 되면, 어떤 단점이 있을까요?* CardDeck을 *싱글턴으로 사용하는 Participants에서 CardDeck에 대한 강한 의존*이 생긴것 같아요!
+> — @namjackson on `Participants.kt`
+
+> Participants에 대한 *책임이 많이 모여있는것으로 보여요!* 참가자를 관리하는것 외에도, *각자의 턴을 진행하고, 카드를 뽑는등 사실상 BlackJack게임에 대한 전반적인 책임 또한 있는*것 같아요!
+> — @namjackson on `Participants.kt`
+
+> *BlackJack승패에 대한 조건에 Ace와 10 ( = 10,K,Q,J) 단 두장으로만 21이 되면, 블랙잭*이 됩니다. *블랙잭과 3장 이상의 조합으로 21의 숫자와 승패를 결정하면 블랙잭이 승리*를 하게됩니다.
+> — @namjackson on `Dealer.kt`
+
+## 얻은 교훈
+
+- ***`null = 특수 케이스 표현`은 호출자가 매번 `?:` 처리*** — `isAce: Boolean` + 정수값 분리가 의도 명확. *기능 시도 욕구가 가독성 비용*을 만든 패턴 (PR #29·#65·#135 결).
+- ***Ace 보정 = 순서 무관 단일 룰*** — *Ace 1 시작 + 합 ≤ 11이면 +10*. PR #10·#79·#114·#28 모두 같은 권고.
+- ***`lateinit + 사이드 이펙트 setter` = 호출 순서 invariant 누락 + stale*** — `fun chooseWinner(score: Int): Consequence` 반환.
+- ***Kotlin when은 비교 연산자도 가능*** — *문법 미숙*이 *if/else if 폭증*. https://kotlinlang.org/docs/coding-conventions.html#if-versus-when
+- ***companion만 있는 class = object*** — *no-arg + 정적 멤버*면 object/top-level.
+- ***`Cards.shuffled().first()` = 카드 소진 부재 = 무한 반복*** — *덱 = mutable 상태 + 셔플 한 번 + pop*.
+- ***Singleton 강한 의존 = 테스트 격리 X + 변화 대응 X*** — 학생 자가 인정. *주입형 인스턴스*가 자연.
+- ***`player.cardBunch.addCard(card)` 직접 접근 < `player.receiveCard(card)`*** — Tell-Don't-Ask. *공통 안티패턴*.
+- ***Participants 일급 컬렉션 ≠ 진행자*** — `BlackJackGame` 별도 객체로 *진행 책임 분리*. PR #92와 같은 결.
+- ***도메인 함수가 View callback을 받으면 도메인 → View 의존*** — *State 변경 또는 결과 반환*으로 *View 호출*은 호출자 책임.
+- ***`compareScore(Int)` = 동일 추상 메시지 못 보냄*** — `match(player: Player)` Tell-Don't-Ask.
+- ***View가 승패 카운트 = 도메인 책임 누수*** — *집계는 도메인* (`Map<Player, Consequence>` + groupBy).
+- ***`CardBunch` 2장 invariant는 다른 시점 생성 불가*** — *Player 생성 흐름*에 두기.
+- ***DealerTest에 Player 함수 = 테스트 대상 ≠ 시나리오*** — *대상의 책임만 테스트*. PR #116과 같은 결.
+- ***블랙잭 룰 = Ace + 10 두 장만 블랙잭, 3장 이상 21 = 일반 21*** — *현실 블랙잭 룰 정확 이해*. **반복 패턴: 학생들의 블랙잭 룰 부정확 이해**. PR #10·#92·#128·#116·#10도 같은 결.
+- ***Set 중복 차단 = 카지노 6~8덱 룰과 충돌*** — *학생의 invariant가 도메인 룰을 좁게 해석*. *현실 도메인 조사*가 *과잉 invariant 방지*.