oh-my-oop 0.2.0

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

@@ -0,0 +1,210 @@
+# PR #66 — [블랙잭 1단계] 예니 미션
+
+- **Reviewee:** [@JoYehyun99](https://github.com/JoYehyun99)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/66
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 18 스레드 — *학생 자가 답변 부재 + reviewer 일방향 진단 + 디미터 법칙 명시*
+- **신규 reviewee** (2024 코호트). PR #31 (no1msh) 와 동일 reviewer. **PR 본문 짧음 (인사) + 학생 코멘트 응답 없음** = *피드백 반영 명시 X 시나리오*.
+
+## 잘한 점 (설계 관점)
+
+- **deck 재사용 자가 시도** — vagabond95: *"deck 재사용 시도 👍 그런데, shuffled 된 deck 을 저장하고 이를 그대로 리턴할 경우 결과적으로는 매번 똑같이 shuffled 된 deck 이 리턴될 것 같아요. shuffled 해주는 순서를 변경해보면 어떨까요?"*. **자가 시도는 인정 + 추가 권고 결합** (재사용 + 셔플 순서) — PR #46·#74·#108·#133·#136·#23·#26·#77 의 *카드 캐싱* 결.
+- **`Hit` 상태 스스로 다음 상태 결정** — vagabond95: *"Hit 에서 처리해주신 것처럼, 상태가 스스로 다음 상태를 결정하도록 리펙토링해볼 수 있을까요~?"* — *State 패턴 부분 자가 적용 인정 + 확장 권유*. PR #98·#39·#43·#152·#93·#136 의 *State.compareTo 다형성* 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `setUp` / `init` 함수명 모호 — vagueName 4 회
+
+vagabond95 1차: *"함수 네이밍이 너무 모호한 것 같아요. 무엇을 초기에 세팅한다는 것인지 구체적으로 명시해주면 좋겠습니다!"* (Controller)
+
+vagabond95 2차: *"마찬가지로 무엇을 초기화하는 것인지 의미가 모호해요. 좀 더 구체적인 이름을 지어주면 좋겠어요."* (State)
+
+vagabond95 3차: *"무엇을 더한것인지 구체적으로 드러나면 좋을 것 같아요."* (Hand.sum)
+
+vagabond95 4차: *"또한 calculate 와 sum 은 비슷한 의미를 가지고 있기 때문에 하나로 줄여도 좋겠습니다!"* (calculateSum)
+
+→ **명명 모호 다중 발생**:
+- *`setUp()`* = *무엇을 setup?* 의도 모호.
+- *`init()`* = *State 초기화? 게임 초기화?*.
+- *`sum()`* = *카드 점수 합? 배팅 금액 합?*.
+- *`calculateSum()`* = *calculate + sum 중복 의미*.
+
+**MCP 기존 룰 `vagueName`** — *명사형 vs 동사+명사 구체화*. PR #99·#26·#23·#39·#46·#16·#9·#43·#77·#31 결의 *공통 안티패턴*.
+
+### 2. `BlackjackGame` Model 이 display 알 수 없음
+
+vagabond95: *"BlackjackGame 은 model 이므로, display 가 될거라는 사실은 알 수 없지 않을까요~?"*
+
+→ **MVC 경계** — *Model 이 View 의 표현 책임 알기 X*. PR #26·#23·#16·#77·#39·#46 의 *enum-with-ui-value* 결의 *역방향* (model 이 view 인식).
+
+### 3. `askForPlayerAction` Boolean 반환 의미 모호
+
+vagabond95: *"askForPlayerAction 라는 네이밍을 봤을 때, 리턴되는 boolean 값이 무엇을 의미하는지 알기 어려울 것 같아요."*
+
+→ **부울 명명 = 기준점 명시 누락**:
+- *`askForPlayerAction(): Boolean`* — *true 면 Hit? Stay? 동작 계속?*.
+- 대안: *`shouldHit(): Boolean`* / *`isContinue(): Boolean`* — *true 의 의미 명시*.
+
+PR #98 (chaehyuns *isWin/isLose 기준점*) / PR #151 (jerry8282 *canHit/isBust 의미 통일*) 결.
+
+### 4. `calculateResult` public 호출 순서 의존
+
+vagabond95: *"calculateResult 함수는 public 이므로 언제든 호출이 가능한데요, play 하지 않고 먼저 호출할 경우 의도하지 않은 결과가 리턴될 것 같아요. 외부에서는 함수를 어떤 순서로 호출할지 알 수 없으므로 특정 함수들의 호출 순서가 보장되어야한다면, 리펙토링이 필요할 것 같습니다!"*
+
+→ **호출 순서 의존 = invariant 결함**:
+- *`play()` 전에 `calculateResult()` 호출 가능* = *내부 상태 미완성 + 무의미 결과*.
+- 해결:
+  - (A) **State 분기 + 예외** = *Play 안 된 상태에서 호출 시 Exception* (PR #91 murjune *논리적 오류*).
+  - (B) **결과 객체 반환** = *`play().result()` 체이닝 강제*.
+  - (C) **builder 패턴** = *play() 후 result() 단계*.
+  - (D) **State 패턴** = *Finished 상태에서만 result() 노출*.
+
+PR #91 (murjune *finishState 미할당 시 예외*) / PR #9 (BeokBeok *Builder 호출 순서*) / PR #16 (SeongHoonC *init 블록 invariant*) 결.
+
+### 5. `딜러 승패 조건식 버그` — suggestion 첨부
+
+vagabond95: *"현재의 조건식으로 딜러의 승리/패배를 판단하기에는 버그를 유발할 가능성이 있어보여요. 예를들어 만약 아래와 같은 상태라면, 어떻게 카운트가 되어야할까요?"*
+
+```kotlin
+val dealerWinCount = outcomes.values.count { it.wins == 1 && it.losses == 2 }
+```
+
+→ **도메인 룰 정확성 = 결정적 테스트로 검증**:
+- *학생 조건식*: *현재 코드의 *비일관 케이스* 미고려*.
+- 결정적 테스트 = *Bust 양측 / 무승부 / 다중 플레이어* 시나리오.
+
+PR #26·#46·#16·#23 의 *블랙잭 룰 정확성* 결.
+
+### 6. `WinningState` participants 책임
+
+vagabond95: *"WinningState 를 구하는 로직들은 dealer 와 개별 player 를 모두 알고 있는 participants 에서 스스로 처리할 수 있을 것 같습니다!"*
+
+→ **Tell-Don't-Ask + 일급 컬렉션**:
+- *외부 (BlackjackGame) 가 dealer + player 데이터 꺼내 비교* → *Participants 일급 컬렉션이 자기 책임*.
+
+PR #99·#74·#108·#133·#137·#46 의 *일급 컬렉션 자가 학습* 결.
+
+### 7. `Dealer 스스로 처리`
+
+vagabond95: *"해당 구현은 딜러가 스스로 처리할 수 있을 것 같습니다!"*
+
+→ **Tell-Don't-Ask + 책임 위치**. PR #98·#39·#43 의 *Dealer 책임 자가 적용* 결.
+
+### 8. `디미터 법칙 (Law of Demeter)` 명시
+
+vagabond95: *"score 를 구하기 위해 알아야하는 domain depth 가 깊어보여요. `디미터 법칙`을 활용하여, API 를 개선해볼 수 있을까요?"*
+
+→ **디미터 법칙 = 친구의 친구의 친구 X**:
+- *`participant.hand.cards.calculateSum()`* = *3 단계 의존 = 디미터 위반*.
+- *`participant.score()`* = *1 단계 메시지*.
+
+**MCP 기존 룰 `god-object` 변형 + 디미터 법칙 명시**. PR #93·#133·#146·#137 의 *디미터 법칙 어휘* 결.
+
+### 9. `CardDeck.initial~` public 함수 호출 시기
+
+vagabond95 1차: *"외부에서 함수를 꼭 한번만 호출한다고 보장이 불가능하기 떄문에, initial~ 과 같이 최초에만 호출되기를 기대하는 함수를 public 함수로 제공하는 것은 고민해봐야 할 문제인 것 같아요."*
+
+vagabond95 2차 (메타 어휘): *"접근제한자나 함수의 호출시기 검토가 필요하거나, 해당 함수가 이 클래스에 어울리지 않는다는 신호일 수도 있습니다 :)"*
+
+→ **3 가지 학습**:
+
+#### 9.1. *Public 함수 = 호출 횟수 무관*
+
+- *`initial()` public + 외부 1 회만 호출 기대* = *외부가 N 회 호출 가능 = invariant 결함*.
+
+#### 9.2. *접근제한자 = 호출 제한*
+
+- *private / internal / protected* 활용.
+
+#### 9.3. *"클래스에 어울리지 않는다는 신호"* — 메타 어휘
+
+- *함수 잘못 위치 시그널 = 책임 재배치 권유*. **MCP `oh-my-oop` 의 *책임 잘못 배치 시그널* 어휘**.
+
+PR #9 (BeokBeok *Builder 호출 순서*) / PR #16 (SeongHoonC *init 블록*) / PR #91 (murjune *finishState invariant*) 결.
+
+### 10. `OutputView` 책임 외 정보 + 계산 + 승패 판단
+
+vagabond95 1차: *"이러한 기준은 view 에서 몰라도 되는 정보일 것 같아요."*
+
+vagabond95 2차: *"2 라는 숫자가 무엇인지 좀 더 의미가 드러나면 좋겠습니다."*
+
+vagabond95 3차: *"View 에서 계산할 필요가 없는 부분 같아요!"*
+
+vagabond95 4차: *"View 는 승리/패배 상태를 어떻게 출력할지만 고민할 뿐, 승리 패배 그 자체를 판단해서는 안될 것 같아요."*
+
+→ **View 책임 = 표현 + 입출력 + 도메인 로직 X**:
+- *View 가 점수 비교, 승패 판단, 계산 = 도메인 로직 누수*.
+- *상수 (`2`) 매직 넘버 = vagueName + 의미 모호*.
+
+PR #28·#79·#16·#26·#9 의 *View 로직 누수* 결.
+
+### 11. `Card 묶음 재활용` 권유
+
+vagabond95: *"Card 묶음 자체는 변경이 없을것이므로, 객체를 재활용해봐도 좋겠네요!"*
+
+→ **불변 객체 + 재활용**. PR #74·#108·#133·#136·#23·#26·#46 의 *Card 캐싱* 결.
+
+### 12. `Controller` 코드 단계별 분리
+
+vagabond95: *"코드를 단계별로 나눠보면 좋을 것 같아요. 현재 코드는 가독성이 조금 떨어지는 것 같습니다 😢"*
+
+→ **함수 추출 + 단계별 의미 명시**. PR #46 (말리빈 *라면 비유*) / PR #99 (KwonDae *Controller god-object*) 결.
+
+### 13. `shuffled() 순서` — 매번 동일 셔플 결과
+
+vagabond95: *"shuffled 된 deck 을 저장하고 이를 그대로 리턴할 경우 결과적으로는 매번 똑같이 shuffled 된 deck 이 리턴될 것 같아요. shuffled 해주는 순서를 변경해보면 어떨까요?"*
+
+→ **셔플 위치 = 재사용 시 매번 vs 1 회 결정**:
+- *덱 캐싱 + shuffled() 1 회 = 매번 동일 결과*.
+- *덱 캐싱 + shuffled() 매 호출 = 매번 다른 결과 + 캐시 의미 약함*.
+- *덱 캐싱 + draw() 시 random 인덱스 = 캐시 + 다양성*.
+
+PR #77 (murjune *Deck shuffle 생성 시 1회 vs 매번*) / PR #74·#26·#23 결.
+
+## 리뷰어 의견 요지 (vagabond95)
+
+18 코멘트 특징 (PR #31 와 동일 reviewer):
+
+- **간결 + 명명 의문 위주** — 명명 모호 진단 4 회 = *vagueName 다중 발생 = 학생 자가 학습 갭 시그널*.
+- **`👍` 칭찬 1 회** (deck 재사용 시도) + 권고 17 회 = *피드백 위주 분포*.
+- **디미터 법칙 명시** — *원칙 약어 직접 명시*. PR #16 (BeokBeok *SRP/LSP*) / PR #137·#148·#151·#146 의 *조영호 어휘* 결의 *디미터 법칙 어휘*.
+- **suggestion 블록 1 회** (딜러 승패 조건식). PR #26·#39·#43·#77 결.
+- **메타 어휘** — *"클래스에 어울리지 않는다는 신호"* — *시그널 어휘 = 책임 재배치 진단*.
+- **학생 코멘트 응답 부재** — *학생 자가 답변 + 자가 학습 가시화 부족*. PR #43·#46·#91 (학생 자가 토론 풍부) 와 *대조적*.
+
+## 대표 인용
+
+> *"score 를 구하기 위해 알아야하는 domain depth 가 깊어보여요. `디미터 법칙`을 활용하여, API 를 개선해볼 수 있을까요?"* — vagabond95 (디미터 법칙 명시)
+
+> *"접근제한자나 함수의 호출시기 검토가 필요하거나, 해당 함수가 이 클래스에 어울리지 않는다는 신호일 수도 있습니다 :)"* — vagabond95 (책임 재배치 시그널 어휘)
+
+> *"calculateResult 함수는 public 이므로 언제든 호출이 가능한데요, play 하지 않고 먼저 호출할 경우 의도하지 않은 결과가 리턴될 것 같아요."* — vagabond95 (호출 순서 invariant)
+
+> *"View 는 승리/패배 상태를 어떻게 출력할지만 고민할 뿐, 승리 패배 그 자체를 판단해서는 안될 것 같아요."* — vagabond95 (View 책임 명확)
+
+## 얻은 교훈
+
+1. **`명명 모호 다중 (vagueName 4 회)` = 학생 자가 학습 갭 시그널** — *setUp / init / sum / calculateSum* — *동일 PR 에서 4 회 명명 모호 진단 = 학생의 *명명 어휘 미숙* 시그널*. **MCP `vagueName` 강화 가치**.
+
+2. **`함수 호출 순서 의존 = invariant 결함`** — *Public 함수 + 호출 순서 의존 = 외부가 N 회/잘못 순서 호출 가능*. 해결 = *State 분기 + Exception / 결과 객체 반환 / Builder / State 패턴*. PR #91·#9·#16·#46·#39 결.
+
+3. **`디미터 법칙 (Law of Demeter)` 명시** — *친구의 친구의 친구 X = `a.b.c.d` 금지*. PR #93·#133·#146·#137 의 *어휘* 결의 *원칙 명시 강화*.
+
+4. **`Public + 'initial~' 명명 = 호출 시기 검토 시그널`** — *최초 1 회 호출 기대 함수 = private 또는 init 블록* + *"클래스에 어울리지 않는다는 신호"* 메타 어휘. **MCP 룰 후보 `initial-method-public-leak`**.
+
+5. **`부울 명명 기준점 명시 누락`** — *`askForPlayerAction(): Boolean`* — *true 의 의미 명시 X*. PR #98·#151 결.
+
+6. **`Model 이 View 알기 X`** — *MVC 경계 + Model 자기 책임만*. PR #26·#23·#16·#77·#39·#46 결.
+
+7. **`View 책임 = 표현 + 입출력 + 도메인 X`** (4 회 진단) — *학생이 *View 에 도메인 로직* 누수*. PR #28·#79·#16·#26·#9 결.
+
+8. **`shuffled() 위치 = 캐싱 + 다양성 양립 어려움`** — *덱 캐싱 + shuffled 1회 = 매번 동일 / 매 호출 셔플 = 캐시 의미 약함*. PR #77 (murjune *Deck shuffle 위치*) 결.
+
+9. **`Tell-Don't-Ask + participants 일급 컬렉션 자기 책임`** — *외부가 dealer + player 데이터 꺼내 비교 → Participants 가 자기 책임*. PR #99·#74·#108·#133·#137·#46 결.
+
+10. **`학생 자가 답변 부재 시 학습 가시화 ↓`** — *PR #66 = 학생 코멘트 응답 0 회* — *PR #43·#46·#91·#77 의 *학생 자가 토론 풍부* 와 대조*. **PR 본문 자가 의문 / 학생 코멘트 응답 = 학습 가시화 핵심 매개**.
+
+11. **`vagabond95 reviewer 패턴 일관성`** — *PR #31·#66 동일 reviewer = 간결 + 메타 질문 + 디미터 법칙 명시 + 시그널 어휘*. *2023년 3월 + 2024 코호트 모두 활동*.
+
+12. **`도메인 룰 정확성` (딜러 승패 조건식 버그)** — *학생 코드의 비일관 케이스 미고려*. PR #26·#46·#16·#23 의 *블랙잭 룰 정확성* 결.

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

@@ -0,0 +1,191 @@
+# PR #101 — [블랙잭] 호두 2단계 미션
+
+- **Reviewee:** [@Junyoung-WON](https://github.com/Junyoung-WON) (호두)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/101
+- **단계:** 2단계
+- **리뷰어:** [@vagabond95](https://github.com/vagabond95) (제리)
+- **라인 코멘트:** 9 스레드 — *학생 자가 답변 8 thread 매우 풍부 + PR 본문 1단계 리팩터링 4개 적용 진화 명시 / Tell-Don't-Ask 학생 자가 정점 자각 (\"객체의 자유에 맡기고 메시지로 요청만\") + 디미터 적용 후 *역할/책임 명확화* 학생 자가 자각 + 주석 제거 가능성 자가 자각 + 한 번의 순회로 양측 승패 계산 + 본인 중심 명명 (winOverOpponent/defeatByOpponent) + companion object function 재사용*
+- **Junyoung-WON 양 단계 완성** (1단계 #80 — `callback-naming-view-coupling` printX/showX View 동사 PR).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 1단계 리팩터링 4개 적용 진화 명시 정점
+
+PR 본문:
+
+> *"이전에 `State`에 대한 리팩터링을 잘 진행했던 덕분에 2단계 미션은 비교적 수월하게 구현할 수 있었던 것 같습니다."*
+>
+> *## 추가 및 변경 사항*
+>
+> *### `State` 리팩터링*
+> *### 수익금 원시값 포장*
+> *### `State`에 따라 수익금이 자동으로 계산되도록 구현*
+> *### 승패 결정 로직 일부 수정 — 한 번의 비교로 양측 결과 동시 계산*
+
+→ **PR 본문 변경 사항 명시 학습 모범** = PR #154·#134 결 합류 누적 3 PR.
+
+→ **`single-traversal-for-mutual-result`** ⭐⭐⭐ 신규 — *한 번의 순회로 양측 승패+수익 계산*. PR #102 (gaeun5744)·PR #148 (참가자 vs 참가자) 결 합류.
+
+### 2. 학생 자가 답변 매우 풍부 (8 thread 모두)
+
+모든 thread 학생 자가 답변 + 자가 학습 인용 + *역할/책임* 어휘 자가 자각.
+
+## 못한 점 (설계 관점)
+
+### 1. Tell-Don't-Ask 학생 자가 정점 자각 (Thread 6) — 정점
+
+reviewer: *"하나로 묶어볼 수 있지 않을까요?"*
+
+학생 자가 답변 정점:
+
+> *"승패를 결정하고 상대로부터 얻거나 잃은 수익금을 계산하는 것을 승리(`win`), 패배(`defeat`), 무승부(`push`) 라는 메서드 안에서 동시에 처리할 수 있도록 묶어보았습니다.*
+>
+> *처음에는 한번에 묶게 되면 어떤 동작을 하는지 의미 전달이 잘 안 될 것 같았는데, **게임에서 이겼다(승리했고 돈을 얻었다), 졌다(패배했고 돈을 잃었다) 라고 표현하는 것으로 받아들일 수 있겠네요.***
+>
+> ***그리고 무엇보다 객체가 내부에서 무엇을 하고 어떻게 처리하는지는 객체의 자유에 맡기고, state에서는 한번의 메시지로 요청만 보내도록 하면 더욱 객체지향적이겠군요!***"*
+
+→ **MCP 룰 `tell-dont-ask-student-self-realization-vocabulary`** ⭐⭐⭐ **신규 정점** — *학생 자가 *객체 자유 + 메시지 요청* Tell-Don't-Ask 어휘 자가 자각*. PR #38 (BeokBeok *"내 X 넘겨줄테니 Y 알려줘"*)·PR #154 (`getter-setter-naming-as-missed-object` 학생 자가 자각) 결 합류 누적 3 PR → ***Tell-Don't-Ask 어휘 정점 강화*** ⭐⭐⭐.
+
+→ ***도메인 어휘 의미 묶기*** — *승리 = 이겼고+돈 얻음 / 패배 = 졌고+돈 잃음* 묶기 학생 자가 어휘.
+
+### 2. 디미터 적용 → 역할/책임 명확화 학생 자가 자각 (Thread 0·1)
+
+reviewer Thread 0: *"디미터 법칙의 관점에서 좀 더 개선해볼 수 있을까요~?"*
+
+학생 자가 답변 Thread 0:
+
+> *"디미터 법칙을 적용하여 `Participants` 에 `betBeforeSetting` 메서드를 만들어 `playerGroup`이 `placeBettingMoney`를 수행하도록 구현하였습니다. **이로써 `BlackJackGame`이 `Participants`에게 게임 세팅 전 플레이어에게 베팅금을 걷으라는 메시지를 날릴 수 있게 되었습니다!**"*
+
+학생 자가 답변 Thread 1 정점:
+
+> *"이전 PR에서 딜러와 플레이어 간의 승패 연산을 한 번의 순회 만으로 가능하도록 구현했었는데, 이를 활용하여 수익금에 대한 연산도 함께 수행하도록 구현이 가능할 것 같았습니다!*
+>
+> *우선 디미터 법칙을 적용하여 `BaseHolder`가 상대 수익금에 따라 현재 수익금을 변경하라는 메시지를 `state`에게 날리고, `state`는 `profit`에게 수익금을 계산하라는 메시지를 날리도록 리팩터링을 진행했습니다.*
+>
+> ***디미터 법칙을 적용하니 이전보다 코드가 많이 간결해지고 가독성이 좋아졌고, 코드 상에서 객체가 어떤 역할과 책임을 가지고 있는지 더욱 명확해진 것 같습니다.***"*
+
+→ **MCP 룰 `responsibility-clarity-via-demeter`** ⭐⭐⭐ **신규** — *학생 자가 *디미터 적용 후 역할/책임 명확화* 자가 자각*. PR #38 (`dot-2-or-fewer-rule`) 결 합류 누적 2 PR.
+
+→ **MCP 룰 `message-vocabulary-student-self-narration`** ⭐⭐⭐ — *"메시지를 날린다" 어휘 학생 자가 자가 narrate*. MCP `oh-my-oop` 핵심 가치 (책임-역할-협력) 학생 측 어휘 정점.
+
+### 3. 주석 제거 가능성 자가 자각 (Thread 3)
+
+reviewer: *"주석을 활용하는 것 자체가 나쁜 것은 아니지만, 주석이 없더라도 이해가 쉽도록 코드를 작성하도록 연습해보면 좋다고 생각해요!"*
+
+학생 자가 답변:
+
+> *"디미터 법칙을 적용하고 자주 사용되는 로직을 메서드로 묶어 활용하니 승패 결정 로직이 더욱 간결해지고 이해가 잘 되는 것 같습니다. 주석을 제거해도 코드의 동작 과정이 이전보다 잘 보이는 것 같아, 남아있었던 모든 주석을 제거하였습니다.*
+>
+> ***이렇게 리팩터링을 잘만 한다면 주석이 없더라도 충분히 이해하기 쉬운 코드를 보여줄 수 있군요!***"*
+
+→ **MCP 룰 `comment-removal-as-refactoring-feedback`** ⭐⭐⭐ **신규** — *학생 자가 *리팩터링 후 주석 불필요 자가 자각*. PR #144 (m6z1 셀프 코드 리뷰) 결의 *학생 자가 코드 평가* 다른 축.
+
+### 4. `init` 함수 재사용 vs 최초 초기화 (Thread 2)
+
+reviewer: *"init 함수는 매번 재사용 하는 것을 고려하신걸까요~? 재사용이 아니라 최초 초기화가 목적이라면, 매번 함수를 호출할 수 없도록 구조를 변경해봐도 좋을 것 같아요."*
+
+학생 자가 답변:
+
+> *"해당 함수를 구현한 이유는 재사용의 목적도 일부 있었습니다. 하지만 최초 초기화를 진행하지 않았던 가장 큰 이유는, **프로그램의 전체적인 흐름에서 보았을 때 플레이어가 얼마를 베팅하겠다는 것은 블랙잭 게임의 과정 중 일부라고 생각**했기 때문입니다. 그래서 `BlackJackGame`의 내부 로직에서 베팅금을 입력받고 설정(초기화)하는 것이 자연스럽다고 판단했기 때문에, 일부러 초기화를 진행하는 init 함수를 따로 구현하였습니다."*
+
+→ **MCP 룰 `init-fn-reusable-vs-init-only`** ⭐⭐ 신규 — *init 함수 = 재사용 vs 최초만 + 흐름 정합 학생 자가 정당화*. PR #12 (`init-name-implies-no-return`) 결 합류.
+
+### 5. `fromPlayer` 이름 vs 의도 일치 (Thread 4)
+
+reviewer: *"함수 네이밍은 fromPlayer 지만, dealer 의 값을 넣더라도 이를 검증할 수 없는 구조인데요. 어떻게 개선해볼 수 있을까요?"*
+
+학생 자가 답변: *"수익금을 계산하는 코드의 로직을 수정하여, Dealer만이 사용할 수 있는 함수가 아니라 Player에게도 적용하여 사용할 수 있는 함수가 되도록 리팩토링을 해보았습니다! 이에 따라 함수의 이름도 의도에 맞게 Player가 아닌 Opponent로 리네이밍하였습니다."*
+
+→ **함수명 = 구현 의도 일치** = 누적 16+ PR.
+
+### 6. 생성자 함수 재사용 (Thread 5)
+
+```kotlin
+// 권장
+GameResult.win()
+fun win = GameResult(win = 1)
+```
+
+reviewer: *"다음과 같이 생성자 함수를 제공하면, 코드 재사용이 용이할 것 같아요. 어떤 측면에서 재사용이 용이한지도 같이 고민해보시면 좋겠습니다 :)"*
+
+학생 자가 답변:
+
+> *"이전 구현에서는 `GameResult`의 파라미터에서 `win`, `push`, `defeat`의 값을 각각 지정하여 구현하였습니다. (...) **하지만 생성자 함수를 활용하여 승패를 생성해서 반환받게 된다면 승리, 무승부, 패배에 따라 생성자 함수를 호출하기만 하면 되기에 가독성 측면과 개발 및 유지보수 측면에서 이점이 생길 것 같습니다...!**"*
+
+→ **MCP 룰 `factory-fn-for-named-state-reuse`** ⭐⭐ 신규 — *win()/push()/defeat() 생성자 함수 = 가독성 + 재사용*. PR #47·#42 (팩토리 메서드) 결 합류.
+
+### 7. 본인 중심 명명 일관 (Thread 7)
+
+reviewer: *"상대방보다, 본인을 중심으로 함수 네이밍을 지어보면 어떨까요? 다른 함수는 모두 본인 중심인데 해당 함수들만 상대방을 중심으로 기술되는 것이 조금 어색해보여요."*
+
+학생 자가 답변: *"`winOverOpponent`, `defeatByOpponent` 처럼 \"(자신이) 상대에게 이겼다/졌다\" 를 표현하도록 리네이밍 해보았습니다!"*
+
+→ **MCP 룰 `naming-from-self-perspective-consistency`** ⭐⭐⭐ 신규 — *명명 일관 = 본인 중심 (상대 X)*. PR #15 (`on` 전치사 콜백)·PR #42 (`callback-name-from-domain-perspective`) 결의 *명명 관점 일관* 다른 축.
+
+### 8. companion object function — 인스턴스화 불필요 (Thread 8)
+
+```kotlin
+// 변경 전 - 매번 객체 생성
+class GameResult(val win: Int = 0, val push: Int = 0, val defeat: Int = 0) {
+    fun win(): GameResult = GameResult(win = 1)
+}
+
+// 권장 - companion object function
+companion object {
+    fun win(): GameResult = GameResult(win = 1)
+}
+```
+
+reviewer: *"이 부분은 companion object funtion 으로 제공해도 되지 않을까요? 굳이 객체를 만들고 함수를 호출할 이유가 없어보여요."*
+
+학생 자가 답변:
+
+> *"말씀대로 승리, 무승부, 패배를 1씩 증가시키기 위해 매번 객체를 새로 생성할 필요가 없어보입니다. companion object 내부에서 승리, 패배, 무승부 시의 `result`를 정의하였고 companion object function으로 해당 `result`들을 반환하도록 바꾸어보았습니다."*
+
+→ **MCP 룰 `companion-object-fn-for-reuse-instead-of-instantiation`** ⭐⭐⭐ 신규 — *companion object function = 인스턴스화 없는 재사용 어휘*. PR #154 (`reviewer-kotlin-tip-vocabulary`)·PR #18 (`enum-companion-init-order`) 결 합류 누적 3 PR.
+
+## 대표 인용
+
+> [Junyoung-WON Thread 6]
+> *"객체가 내부에서 무엇을 하고 어떻게 처리하는지는 객체의 자유에 맡기고, state에서는 한번의 메시지로 요청만 보내도록 하면 더욱 객체지향적이겠군요!"*
+
+→ **Tell-Don't-Ask 학생 자가 자각 어휘 정점**.
+
+> [Junyoung-WON Thread 1]
+> *"디미터 법칙을 적용하니 이전보다 코드가 많이 간결해지고 가독성이 좋아졌고, 코드 상에서 객체가 어떤 역할과 책임을 가지고 있는지 더욱 명확해진 것 같습니다."*
+
+→ **디미터 적용 후 역할/책임 명확화 자가 자각 어휘**.
+
+> [Junyoung-WON Thread 0]
+> *"이로써 `BlackJackGame`이 `Participants`에게 게임 세팅 전 플레이어에게 베팅금을 걷으라는 메시지를 날릴 수 있게 되었습니다!"*
+
+→ **학생 자가 *메시지를 날린다* narrate 어휘 정점**.
+
+> [Junyoung-WON Thread 3]
+> *"이렇게 리팩터링을 잘만 한다면 주석이 없더라도 충분히 이해하기 쉬운 코드를 보여줄 수 있군요!"*
+
+→ **학생 자가 주석 제거 가능성 자가 자각 어휘**.
+
+> [vagabond95 마지막 review]
+> *"이번 미션에서 조금이라도 얻어간 것이 있으셨길 바랍니다 ㅎㅎ"*
+
+→ **reviewer 마무리 격려 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **Tell-Don't-Ask 학생 자가 자각 (객체 자유 + 메시지 요청)** — **MCP 룰 `tell-dont-ask-student-self-realization-vocabulary` 후보** ⭐⭐⭐ 정점. PR #38·#154 결 누적 3 PR.
+2. **디미터 적용 후 역할/책임 명확화 학생 자가 자각** — **MCP 룰 `responsibility-clarity-via-demeter` 후보** ⭐⭐⭐.
+3. **학생 자가 *메시지를 날린다* narrate 어휘** — **MCP 룰 `message-vocabulary-student-self-narration` 후보** ⭐⭐⭐ — MCP `oh-my-oop` 핵심 가치 어휘 정점.
+4. **주석 제거 가능성 자가 자각** — **MCP 룰 `comment-removal-as-refactoring-feedback` 후보** ⭐⭐⭐.
+5. **한 번의 순회로 양측 승패+수익** — **MCP 룰 `single-traversal-for-mutual-result` 후보** ⭐⭐⭐.
+6. **본인 중심 명명 일관** — **MCP 룰 `naming-from-self-perspective-consistency` 후보** ⭐⭐⭐.
+7. **companion object function = 인스턴스화 불필요** — **MCP 룰 `companion-object-fn-for-reuse-instead-of-instantiation` 후보** ⭐⭐⭐. 누적 3 PR.
+8. **`init` 흐름 정합 학생 자가 정당화** — **MCP 룰 `init-fn-reusable-vs-init-only` 후보** ⭐⭐.
+9. **생성자 함수 재사용 (win/push/defeat)** — **MCP 룰 `factory-fn-for-named-state-reuse` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **Junyoung-WON 양 단계 완성 (1단계 #80 → 2단계 #101)** — 1단계 *콜백 명명 View 동사* PR #80 → 2단계 *Tell-Don't-Ask 학생 자가 자각 정점 + 디미터 후 역할/책임 명확화 자가 자각*. **메타 케이스 — 학생 자가 메시지 어휘 narrate 학습 정점**.
+- **vagabond95 reviewer 어휘** — *"이번 미션에서 조금이라도 얻어간 것이 있으셨길 바랍니다"* — MCP 핵심 가치 어휘.
+- **메타 케이스 11번째** — *Junyoung-WON 학생 자가 메시지 어휘 학습 정점*.
+- **Tell-Don't-Ask 어휘 누적 3 PR 정점** (PR #38 reviewer + PR #154 학생 자가 + PR #101 학생 자가) — *학생 측 메시지 어휘 자가 자각 정점*.