oh-my-oop 0.2.0

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

@@ -0,0 +1,194 @@
+# PR #120 — [블랙잭 1단계] 채넛 미션
+
+- **Reviewee:** [@yrsel](https://github.com/yrsel)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/120
+- **단계:** 1단계
+- **리뷰어:** @Gyuil-Hwnag
+- **라인 코멘트:** 30 (리뷰어 16 / 리뷰이 14)
+
+## 잘한 점 (설계 관점)
+
+- **`BlackjackGame` 명명 적절** — *Game이라는 도메인 어휘 잘 활용* (리뷰어 명시).
+- **`DrawChoice` enum** — 도메인 어휘로 입력 처리.
+- **`Player`/`Dealer` + `ResultType` enum** — 추상 + 결과.
+- **`@BeforeEach`로 DealerTest 격리** + 리뷰어 "잘 작성" 명시.
+- **후속 반영 — `GameManager` 객체 분리 + `DeckFactory + Deck` 분리 + Player에서 *점수 계산 객체* 분리 + companion object 위치 정리**.
+- **학생이 *각 권고에 자가 답변 + 근거 설명*** — *기능 사용 근거*를 글로 남김.
+
+## 못한 점 (설계 관점)
+
+### 1. `Controller`에 *카드 뽑기 + 더 뽑기 로직* 노출 (재귀)
+
+```kotlin
+class BlackjackController {
+    private fun pickPlayerTurn(player: Player) {
+        // 재귀 호출로 카드 뽑기
+        if (player.isMoreCard() && askMoreCard(player)) {
+            player.draw(Deck.dealCard())
+            pickPlayerTurn(player)
+        }
+    }
+}
+```
+
+리뷰어: "*재귀 형식으로 함수를 구성하셨군요~* 현재 *Controller 에 플레이어가 `카드를 뽑는다 -> 더 뽑을지를 정한다`등 로직이 드러나 있는데, Controller 에서 로직이 드러나는 것을 줄여보게 해볼 수 있을까요?*🤔"
+
+학생 자가 인정: "*컨트롤러에서 어떤 방식으로 기능이 작동하는 지 보이는 부분을 GameManager 내부로 숨겨 메시지를 통해 기능을 수행하도록 수정*하였습니다!" — *Controller god-object* → `GameManager`로 분리. PR #20·#25·#33·#92와 같은 결.
+
+### 2. `Card data class` 사용 이유 — 학생 자가 답변
+
+```kotlin
+data class Card(val shape: Shape, val number: CardNumber)
+```
+
+리뷰어: "*Card를 data class를 활용하셨군요~ data class 와 class는 어떠한 차이점이 있을까요?*"
+
+학생 자가 답변: "*data class는 `equals()`, `hashCode()`, `toString()`, `componentN()`, `copy()`메서드를 제공하는 이점이 있다고 생각합니다!* *현재 `Card`클래스는 data class에서 제공하는 메서드를 활용하지 않아서 class로 선언했어도 상관없었을 것 같아요..*😅" — **`data class`의 *목적*은 *equals/hashCode/copy* 같은 *값 객체 메서드*. *모두 안 쓰면 일반 class 또는 immutable class***. 학생 자가 깨달음.
+
+### 3. `Dealer.isMoreCard()` 함수명 — 결과 동사 부재
+
+```kotlin
+class Dealer { fun isMoreCard(): Boolean = ... }
+```
+
+리뷰어: "*isMoreCard 라는 네이밍도 좋긴 한데, `어떤 동작을 할 수 있다!`라는 이름이 드러나게 지어볼 수도 있겠다는 생각이 듭니다~*"
+
+학생: "*뽑을 수 있는 가능성 여부를 반환하는 것을 고려해 반영*해보았습니다" — `canDraw()` / `mustDraw()`. PR #29·#24·#114·#119·#34와 같은 결.
+
+### 4. `Dealer`의 `companion object` 위치 — Kotlin 컨벤션
+
+리뷰어: "*별건 아니고, 보다가 살짝 눈에 들어와서 코멘트 남겨두었습니다~*😅 *정해진 형식이 있는건 아니고, companion object의 활용 용도를 고려해서 companion object의 경우 중간보다는 최하단 또는 최상단에 위치를 많이 하긴 합니다!*" — PR #128·#8과 같은 *Kotlin Class Layout* 컨벤션.
+
+### 5. `Deck` `object` Singleton — class vs object 토론
+
+```kotlin
+object Deck {
+    private val CARDS: List<Card> = ...   // 대문자
+    private const val INITIAL_HAND_OUT_CARD_COUNT = 2
+    private var cardIndex = 0
+    fun dealCard(): Card { ... }
+}
+```
+
+리뷰어: "*object 키워드의 활용 좋습니다~ obejct , class 는 어떠한 차이점이 있을까요?*"
+
+학생 자가 답변: "*`object`는 매번 인스턴스를 생성하지 않고 한 번만 생성해서 사용하기에 메모리를 효율적으로 사용할 수 있습니다.* 다만, *인스턴스를 단 한 번만 생성하고 여러 군데에서 호출할 수 있기에 공유 변수를 둘 경우 파급효과가 발생*..."
+
+→ **학생이 *Singleton의 trade-off* 자가 인식**. *공유 변수의 파급 효과*를 고려한 후 *후속에 `DeckFactory + Deck` 분리* — Singleton 회피.
+
+### 6. `Deck` 상수 *companion object* 분산 vs object 직접
+
+```kotlin
+object Deck {
+    private val CARDS: List<Card> = ...     // object 안에 직접
+    private const val INITIAL_HAND_OUT_CARD_COUNT = 2   // object 안에 직접
+}
+```
+
+리뷰어: "*상수들의 경우 companion object 에서 선언하신 것이 있고 아닌것이 있는데, 이유가 있을까요?*"
+
+학생 자가 답변: "*Deck을 object로 선언했어서 변수, 상수는 최상단에 위치해야 된다고 생각*했습니다! 위의 두 변수 중 *INITIAL_HAND_OUT_CARD_COUNT 은 카드를 뽑는 정보가 Deck에 있으면 좋을 것 같다는 생각과 초기 카드를 n장 뽑는다와 같이 n이 바뀔* ..." — *Object는 companion object 불필요* (이미 싱글톤). *내부 상수는 직접 선언* 자연.
+
+### 7. `Deck.CARDS` 대문자 — 변수처럼 사용
+
+리뷰어: "*해당 내용은 Cards 라는 변수처럼 사용을 하는데 대문자로 선언을 하신 이유가 있을까요?*🤔"
+
+학생 자가 답변: "*현재 52장의 카드를 한 번만 생성해서 사용하다보니 상수 객체로 사용했다는 것을 변수명으로 표현하고 싶어서 대문자로 선언*해보았습니다!" — **`val + 대문자 = 상수성 강조*** (Java/Kotlin 관례). *`const val`이 진짜 상수*이지만 *List는 compile-time constant 불가*. **표현 의도** 명확.
+
+### 8. `Deck.dealCard()` 카드 소진 시 게임 폭파
+
+리뷰어: "*더이상 뽑을 카드가 없을때는 게임을 폭파 시키는데, 더이상 뽑을 카드가 없을 경우에 어떻게 하는것이 좋을까요?*🤔"
+
+학생 자가 답변: "*현재 `Deck`이 `object`로 선언하고 내부 구현이 한 번만 카드 뭉치(52장)를 생성할 수 있는 구조로 되어 있었습니다.* *더 이상 뽑을 카드가 없을 때를 고려하다보니 덱을 생성해주는 객체인 `DeckFactory`(object)와 덱의 카드를 사용하는* ..." — **DeckFactory + Deck 분리로 *덱 재생성 가능***. PR #81·#61·#92와 같은 결.
+
+### 9. `DrawChoice.isStay()` — 동사 부재
+
+```kotlin
+enum class DrawChoice { HIT, STAY; fun isStay(): Boolean = this == STAY }
+```
+
+리뷰어: "*isStay 라는 네이밍도 좋긴 한데, 뽑지 않는다는 네이밍이 좀 더 드러날 수 있는 네이밍이 있을 것 같다는 생각이 듭니다!*" — `isNotDrawing` 또는 *상태 동사*. 학생 후속: *DrawChoice → DRAW/STAY* 명명 변경.
+
+### 10. `Player`가 *점수 계산* 책임
+
+리뷰어: "*Player에서 점수를 계산하지 않고, 계산을 하도록 하는 객체로 분리를 해보는 것은 어떨까 라는 생각이 듭니다!*"
+
+학생 자가 답변: "*계산하는 객체를 생성해서 점수 계산 책임을 부여*했습니다." — PR #29·#114·#92·#119·#10·#28·#65·#79와 같은 결.
+
+### 11. `ResultType`에 *블랙잭 룰 비교*
+
+리뷰어: "*위에 Player에 남겨둔 코멘트처럼 점수를 계산해주는 객체가 있다면, 해당 내용도 추가를 시켜볼 수 있겠군요!*"
+
+학생: "*해당 객체에 추가*했습니다!" — *Score 객체*에 *블랙잭 룰*까지. 학생 후속.
+
+### 12. `InputView` `class` vs `object` — 학생 자가 토론
+
+```kotlin
+class InputView { ... }
+```
+
+리뷰어: "*InputView 에 대해서 object 키워드를 사용해도 될 것 같아보이는데, class로 선언을 하신 이유가 궁금합니다!*"
+
+학생 자가 토론: "*`InputView`에 대한 추상화 진행 가능성을 고려해서 `class`로 선언*하였습니다. *`InputView`라는 인터페이스가 있다면 한국어View, 영어View, … 으로 만든다면 controller에 알맞은 View를 주입시킬 수 있지 않을까* 했습니다. 하지만 현재..."
+
+→ ***확장성 고려*가 *현재 미사용*과 결합 = YAGNI 토론**. *학생이 *미래 확장성*을 위해 class 선택*. 리뷰어는 *현재 상태*에서 *object 충분*함을 제안. 학생 *근거 글로 남김*.
+
+### 13. `OutputView` 빈칸 출력 반복
+
+```kotlin
+fun printSomething() { println(); /* ... */; println() }
+```
+
+리뷰어: "*빈칸을 출력한다는 내용들이 많이 있는데, 이를 하나의 함수로 만든다면, 어떤 기능을 하는지 더 구분이 더 잘될 수 있겠다는 생각이 듭니다~*"
+
+학생: "*내용을 구분해준다는 의미를 담아보았습니다.*" — `printNewLine()` 또는 *섹션 구분 함수*. *반복 코드 = 의도 명명* 신호.
+
+### 14. *블랙잭 룰 누락* (Ace+10 두 장만 블랙잭)
+
+리뷰어가 이전 다른 PR (#20)에서 권고한 *블랙잭 룰*은 이 PR에서 명시되지 않았으나, *ResultType에 블랙잭 비교 룰*이 미반영. 학생 후속 *Score 객체*에 *블랙잭 추가*가 *부분 해결*.
+
+## 리뷰어 의견 요지
+
+- ***`BlackjackGame` 명명 좋음***.
+- ***Controller에 진행 로직 노출 = Game/Manager로 이전***.
+- ***data class의 목적 (equals/hashCode/copy) 활용 안 하면 일반 class*** (학생 자가 깨달음).
+- ***`isMoreCard` 함수명 = 동작 동사 부재***.
+- ***companion object 위치 (상/하단)***.
+- ***Object Singleton의 공유 변수 파급 효과***.
+- ***Object에는 companion object 불필요*** — 직접 선언.
+- ***`val + 대문자`로 상수성 강조*** = Java/Kotlin 관례.
+- ***Deck 소진 시 게임 폭파 = DeckFactory + Deck 분리로 해결***.
+- ***`isStay` < 동사*** — `isNotDrawing`.
+- ***Player의 점수 계산 책임 분리***.
+- ***ResultType에 블랙잭 룰***.
+- ***`class InputView` 확장성 고려 vs `object` 현재 충분*** — YAGNI 토론.
+- ***빈칸 출력 반복 = 함수로 의도 명명***.
+
+## 대표 인용
+
+> data class는 `equals()`, `hashCode()`, `toString()`, `componentN()`, `copy()`메서드를 제공하는 *이점이 있다고 생각*합니다! 현재 *`Card`클래스는 data class에서 제공하는 메서드를 활용하지 않아서 class로 선언했어도 상관없었을 것 같아요*..😅
+> — @yrsel (학생 자가 깨달음) on `Card.kt`
+
+> `object`는 매번 인스턴스를 생성하지 않고 한 번만 생성해서 사용하기에 *메모리를 효율적으로 사용*할 수 있습니다. 다만, 인스턴스를 단 한 번만 생성하고 *여러 군데에서 호출할 수 있기에 공유 변수를 둘 경우 파급효과가 발생*...
+> — @yrsel (학생 자가 토론) on `Deck.kt`
+
+> `InputView`에 대한 추상화 진행 가능성을 고려해서 `class`로 선언하였습니다. *한국어View, 영어View, … 으로 만든다면 controller에 알맞은 View를 주입*시킬 수 있지 않을까 했습니다.
+> — @yrsel (학생 YAGNI 자가 토론) on `InputView.kt`
+
+> 컨트롤러에서 어떤 방식으로 기능이 작동하는 지 보이는 부분을 *GameManager 내부로 숨겨 메시지를 통해 기능을 수행*하도록 수정하였습니다!
+> — @yrsel on `BlackjackController.kt`
+
+## 얻은 교훈
+
+- ***data class의 목적 (equals/hashCode/copy) 활용 안 하면 일반 class*** — 학생 자가 깨달음. 모든 *값 객체*가 *data class*일 필요는 없음.
+- ***Singleton (`object`)의 공유 변수 = 파급 효과*** — 학생 자가 인식 후 *Factory 분리*. PR #81·#61·#92와 같은 결.
+- ***Object에는 companion object 불필요*** — 이미 *싱글톤이므로 직접 선언*이 자연.
+- ***`val + 대문자` = 상수성 강조의 표현 의도*** — Java/Kotlin 관례. *진짜 상수는 `const val`*.
+- ***Deck 소진 시 게임 폭파 = DeckFactory + Deck 분리로 *재생성 가능****.
+- ***확장성 고려 (`class InputView`) vs YAGNI*** — *추상화의 미래 가치 vs 현재 비용*. **학생이 *글로 근거 남기는 습관* = 학습의 가시화**.
+- ***Controller god-object → GameManager로 이전*** — *Controller는 진행 흐름의 큰 그림만*.
+- ***`isMoreCard()` 함수명 < `canDraw()` 동작 동사*** — *결과 + 의미*가 함수명에.
+- ***`isStay()` < `isNotDrawing()`*** — *명확한 의미*.
+- ***`OutputView` 빈칸 출력 반복 = 함수로 의도 명명*** — *반복 코드 = 의도 명시 부재* 신호.
+- ***점수 계산 = Score 객체로 분리*** — Player의 책임 X.
+- ***학생이 자가 답변 + 근거 글로 남기는 PR 패턴*** — *기능 선택의 이유*가 *학습 가시화*. PR #128·#135·#111과 같은 결.