oh-my-oop 0.2.0

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

@@ -0,0 +1,175 @@
+# PR #11 — [블랙잭 1단계] 토마스 미션
+
+- **Reviewee:** [@ki960213](https://github.com/ki960213)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/11
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 19 스레드 — *학생 자가 답변 풍부 + 책임 위치 자가 설명 + ReadValueSureModifier 자가 정당화 + reviewer 인정*
+- **신규 reviewee** (2023년 3월 코호트). PR #31·#66 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **`enum 적절한 활용`** — vagabond95: *"enum 의 적절한 활용 케이스인 것 같습니다 👍"* (ResultType). PR #137·#148·#90·#146·#26 결.
+- **`backing field` 활용** — vagabond95: *"backing field 를 이용하여 외부에 노출될 때는 read - only 로 동작하도록 신경써주신 점 좋습니다 👍"* (Participant). PR #46 (krrong *backing property*) / PR #16 (SeongHoonC) 결.
+- **`Card 숫자/모양 분리`** — vagabond95: *"카드를 숫자와 모양별로 잘 나눠주셨네요 👍"*.
+- **`내부 확장함수` 활용** — vagabond95: *"내부 확장함수 활용 👍 가독성 향상에 도움이 되겠네요!"* (Players).
+- **`InputView 책임 자가 학습`** — vagabond95 메타 질문 3 단계: *"ANSWER_YES 혹은 ANSWER_NO 가 전달되는 것이 '정상적인 상황이다.' 라는 것을 view 에서 판단할 필요가 있을까요?"* + *"InputView 의 핵심 역할은 무엇일까요?"* + *"view 가 '판단'을 하지 않을 때의 장점은 무엇이 있을까요?"* + 학생: *"InputView의 핵심 역할은 사용자의 입력을 읽는 것이라고 생각합니다. 이에 따라 사용자의 입력이 'y'나 'n'인지 판단하는 일은 InputView의 역할이 아니라고 생각합니다!"*. **3 단계 메타 질문 + 학생 자가 책임 정의 모범**.
+- **`Dealer.cards.size == INIT_CARD_SIZE` 비즈니스 로직 명시화 자가 정당화** — vagabond95: *"`cards.size == INIT_CARD_SIZE` 는 항상 true 이지 않을까요?"* + 학생 자가 답변: *"비즈니스 로직 상 딜러는 카드를 두 장을 가지고 있을 때 두 카드의 합이 16이하라면 히트해야 하는데, 만약 카드를 두 장 가지고 있지 않을 땐 카드의 합과 상관없이 히트하지 않아도 된다고 합니다. 제가 만드는 코드에서는 딜러의 카드가 두 장일 때만 shouldHit() 메서드를 호출하지만 비즈니스 로직을 코드로 명확히 표현하기 위해 카드 개수를 비교하는 과정을 추가했습니다!"* + reviewer 인정: *"설명해주신 포인트를 듣고나니 의미가 있는 코드네요!"*. **학생 자가 *비즈니스 룰을 코드로 명시* 의도 명시 + reviewer 인정 모범**.
+- **`ReadValueSureModifier` 자가 정당화 + reviewer 인정** — vagabond95: *"object 의 function 과 top level function 으로 선언하는 기준점도 같이 고민해보아요!"* + 학생 자가 매우 긴 답변: *"사용자의 입력값이 타입이 틀리거나 도메인 규칙에 맞지 않을 때, 계속해서 사용자의 입력값을 받는 함수를 호출함으로써 사용자에게 도메인 규칙에 맞는 값을 확실히 얻어오기 위한 코드가 한 클래스에 있으면 응집도가 높아진다고 생각해서 object에 선언했습니다. ... 한마디로 '도메인 규칙에 맞는 값을 사용자로부터 얻을 때까지 반복하는 기능'에 대한 책임을 특정 클래스에 위임하는 것이 좋다고 생각해서 ReadValueSureModifier 클래스에 위임했습니다. 이것은 불필요한가요?"* + reviewer: *"불필요하다고 생각하지 않습니다! 오히려 설명해주신 부분을 들어보니 reasonable 하다는 느낌을 받았씁니다 👍"*. **학생 자가 응집도 정당화 + reviewer 반박 후 인정 모범** — PR #43 (chws0508 *책임 위치 4 후보*) / PR #91 (murjune *논리적 오류 자가 정당화*) 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `InputView` "y"/"n" → Boolean 변환 책임 위치
+
+vagabond95: *"InputView 는 입력을 받거나 가공하는 것이 주요 역할인데요, 'y', 'n' 을 true / false 로 변환될 수 있는 것은 어디의 역할에 가깝다고 생각하실까요?"*
+
+학생: *"controller의 역할에 가깝다고 생각합니다!"*
+
+→ **InputView vs Controller 변환 책임**. PR #31·#66·#43·#107·#9 결의 *View 책임 명확* 결.
+
+### 2. `toKorean` 함수 다중 책임 — `enum-with-ui-value` 강화
+
+vagabond95 1차: *"1. 해당 함수를 보고 어떤 역할을 수행하는지 외부에서 쉽게 파악이 가능할까요? 2. 만약 카드를 또다른 언어로 출력해줘야하는 스펙이 추가 될 경우, 현재 함수는 어떤 문제점이 생길 수 있을까요?"*
+
+vagabond95 2차: *"설령 toKorean 이 모델을 한국어의 형태의 무엇을 만드는 함수라는 암묵적인 규칙이 있다고 하더라도, 아래 3가지 toKorean 함수의 역할은 저마다 조금씩 다른 포인트가 존재하는데, 이를 구별하기가 너무 어려울 것 같아요."*
+
+→ **다국어 확장 + `toKorean` 명명 한정성**:
+- *`toKorean()`* = *한국어 출력 한정* = 다른 언어 추가 시 *`toEnglish()`* 등 N 회 폭증.
+- 대안: *`toDisplayText()`* + locale 의존 / *Mapper 객체*.
+
+**MCP 룰 후보 — `single-locale-method-name`** = *언어 한정 명명 = 다국어 확장 어려움*. PR #137 (HamBeomJoon *Multi-platform 함정*) / PR #41·#151 의 *view-only-validation-cross-ui-fragility* 결.
+
+### 3. `Deck` object 싱글톤 자가 학습
+
+vagabond95: *"object 는 싱글턴으로 프로그램의 생명주기와 동일한 생명주기를 가지게 될텐데요. Deck 만 object 로 선언해주신 이유가 있을까요? Dealer 와 Participant 처럼 동일하게 게임에 참여하는 도메인들과 다른 생명주기를 가지게 되는 이유가 궁금합니다!"*
+
+학생: *"덱은 이 프로그램이 실행되는 동안 딱 한 개만 필요해서 object로 선언했습니다. 생각해보니 클래스로 만드는 것이 더 어울리는 것 같습니다!"*
+
+→ **싱글톤 생명주기 vs 인스턴스 생명주기**:
+- *Deck (싱글톤)* = *프로그램 시작-종료까지 유지* + *상태 변경 시 게임 간 누수*.
+- *Deck (인스턴스)* = *게임 시작마다 새로 생성*.
+
+PR #46 (krrong *Calculator object*) / PR #16 (SeongHoonC *object 어휘*) 결.
+
+### 4. `Deck.refill` 블랙잭 도메인 룰 미반영
+
+vagabond95: *"블랙잭의 비즈니스 로직을 기반으로 생각해보면, 카드를 다뽑아도 리필되면 안되는 것 아닐까요? 게임의 재시작을 염두에 두신 것이라면 다른 방식으로 접근해볼 수 있을 것 같아요."*
+
+→ **카드 리필 vs 게임 재시작**:
+- *블랙잭 룰* = *덱 소진 = 게임 종료 (1 벌 한정)*.
+- *재시작* = *새 Deck 인스턴스 (싱글톤 X + 게임 재시작 분리)*.
+
+PR #46·#26·#58·#74·#108 의 *카드 부족 시 게임 종료 UX* 결.
+
+### 5. `Players(Set vs List)` — 학생 자가 트레이드오프 명시
+
+vagabond95: *"중복되지 않다는 것을 좀 더 명시적으로 보장하고 드러내고 싶다면, List 가 아닌 Set 으로 선언해주는 것도 좋을 것 같아요."*
+
+학생 자가 답변 (장황):
+
+> *"만약 Set으로 선언한다면 사용자가 같은 이름을 중복해서 입력했을 때 명시적으로 잘못 입력되었다는 것을 보여주려면 Players 외부에서 검증 후 Player 객체들을 Set에 담고 Players를 생성해야 하지만, List로 선언한다면 Players를 생성하면서 사용자가 입력한 이름들이 중복인지 검증할 수 있어서 List로 생성할 수 있도록 만들었습니다. 그렇다고 생성자의 인자만 List로 선언하고 내부 프로퍼티를 Set으로 선언 후 인자로 들어온 List<Player>타입의 값을 Set으로 초기화하는 것도 이득이 없다고 생각해서 List로 선언했습니다! 저는 이러한 이유로 players 프로퍼티를 List로 선언했는데, 차라리 명시적으로 드러내기 위해 Set으로 선언 후 중복된 이름을 입력했을 때 에러 메세지를 보여주는 기능을 따로 구현하는 게 나을까요?"*
+
+vagabond95 답변:
+
+> *"히스토리를 들어보니, - 객체를 생성할 때의 사용성 - 객체의 의미를 드러내는 것 의 접근방식 차이인 것 같아요 ㅎㅎ 이 부분은 잘 고민해보시고, 선택해주시면 될 것 같아요. 저의 개인적인 경험으로 unique 해야하는 컬렉션이라면 Set 으로 선언이 되었을 때, 도메인의 의도를 좀 더 쉽게 파악할 수 있더라구요 :)"*
+
+→ **3 가지 학습**:
+
+#### 5.1. *Set vs List 양가성*
+
+- *Set* = *중복 차단 + 의도 명시* — 도메인 의미 강조.
+- *List* = *중복 입력 시 사용자 친화 에러 메시지 가능* — 검증 응집.
+
+#### 5.2. *내부 Set vs 인자 List 분리 자가 검토*
+
+학생이 *"인자만 List + 내부 Set"* 도 자가 검토 + *"이득이 없다"* 자가 결정.
+
+#### 5.3. *vagabond95 의 *"개인적인 경험으로"*** — *MCP `oh-my-oop` 개인 의견 메타*. PR #43·#23·#26·#46·#91·#107 결의 *9 reviewer 메타 어휘 합류*.
+
+PR #23 (멘델 *Set 여러 벌 카드 한계*) / PR #26 (chws0508 *List 자가 반영*) 결의 *반대 시점*.
+
+### 6. `Const.kt` 별도 파일 — 명명 일반성 시그널
+
+vagabond95: *"다른 상수들은 모두 필요한 곳에서 선언되었는데, 해당 상수들만 별도 파일로 두신 이유가 있을까요? 만약 이유가 있으시다면, 그 이유가 네이밍에 좀 더 잘 드러나면 좋을 것 같아요. 이름이 general 할 수록 어떠한 값/함수가 선언되어도 어색하지 않기 때문에, 쉽게 파일 / 클래스가 비대해질 수 있습니다!"*
+
+→ **명명 일반성 + 비대화 시그널**. PR #16 (SeongHoonC *BlackJackRule* / *misc*) 결. **MCP 룰 후보 `general-name-class-bloat`**.
+
+### 7. `Players.toList()` vs `value` 일관성
+
+vagabond95: *"일급 컬렉션의 용도로 클래스를 만들어주신 것 같아요! 원시값 포장 객체, 일급 컬렉션은 감싸고 있는 데이터의 형태가 다를 뿐 동일한 목적을 가지고 있다고 생각하는데요. 따라서 각 클래스의 접근법도 동일하면 좋다고 생각해요. 현재 ParticipantName, Card 는 데이터를 가져올 때 `value` 라는 형태로 제공이 되는데, Players 는 `toList()` 라는 함수를 호출해야 가져올 수 있습니다. 이 부분이 통일되면 사용자 입장에서 혼동이 덜하고, 같은 역할을 하는 클래스라고 이해하기 쉬울 것 같아요!"*
+
+→ **일관된 접근자 패턴** = *value vs toList vs cards 등 혼재 = 사용자 혼동*. **MCP 룰 후보 `inconsistent-accessor-pattern`**.
+
+PR #99 (s6m1n *Hand 일급 컬렉션*) / PR #74·#108·#133·#46 결.
+
+### 8. `BlackjackResult` 디미터 법칙
+
+vagabond95: *"players 값을 꺼내오지 말고, 스스로 내부에서 처리해볼수도 있지 않을까요?"*
+
+→ **Tell-Don't-Ask**. PR #66·#46·#43·#74·#98·#137·#148 결.
+
+### 9. `BlackjackResult` 명명 혼동
+
+vagabond95: *"실제 Dealer 와 혼동되지는 않을까요?"*
+
+→ **클래스명 혼동 방지**. PR #99 (s6m1n *Return enum*) 결.
+
+### 10. `if 문 내 복잡 연산` 변수 추출
+
+vagabond95: *"```return if (names.all { it.isNotBlank() }) names else getNames()``` 연산 결과를 별도 변수로 담고, 해당 변수를 이용하여 if 문 비교를 해보는 것은 어떨까요? if 문 내에 연산식이 들어가고 이것이 복잡해질수록, 코드를 이해하기 어려울 수 있을 것 같아요."*
+
+→ **변수 추출 = 가독성**. PR #39·#95 결.
+
+### 11. `view 가 getNames() 재호출 판단`
+
+vagabond95: *"아래 코멘트와 같은 맥락으로 view 에서 getNames() 를 재호출하는 판단을 하는 것이 적절할지, 고민해보면 좋겠어요!"*
+
+→ **View 의 재호출 판단 = 도메인 흐름 인식**. PR #91 (murjune *Result 위치*) 결. *학생이 ReadValueSureModifier 로 응집 (위 §잘한점)*.
+
+### 12. `각 단계 개행`
+
+vagabond95: *"각 주요 단계마다 개행을 주면 가독성이 좀 더 좋아질 것 같아요~!"*
+
+→ **공백 = 가독성**.
+
+## 리뷰어 의견 요지 (vagabond95)
+
+19 코멘트 특징 (PR #31·#66 와 동일 reviewer):
+
+- **메타 질문 다중 (3 단계)** — InputView 책임 정의 3 질문 → 학생 자가 답변 유도.
+- **`👍` 칭찬 분포 6 회 + 권고 13 회** — *균형 잡힌 분포*.
+- **개인 경험 메타 어휘** — *"저의 개인적인 경험으로"* — **MCP `oh-my-oop` 핵심 가치**. PR #43·#23·#26·#46·#91·#107 결.
+- **학생 자가 정당화 인정 후 반박 X** — `ReadValueSureModifier` *"reasonable 하다는 느낌"* 인정. **학생 결정 존중**. PR #43·#91·#107 결.
+- **메타 어휘** — *"히스토리를 들어보니"*, *"접근방식 차이인 것 같아요"* — *대화형 분석*.
+
+## 대표 인용
+
+> *"비즈니스 로직 상 딜러는 카드를 두 장을 가지고 있을 때 두 카드의 합이 16이하라면 히트해야 하는데, 만약 카드를 두 장 가지고 있지 않을 땐 카드의 합과 상관없이 히트하지 않아도 된다고 합니다. 제가 만드는 코드에서는 딜러의 카드가 두 장일 때만 shouldHit() 메서드를 호출하지만 비즈니스 로직을 코드로 명확히 표현하기 위해 카드 개수를 비교하는 과정을 추가했습니다!"* — ki960213 (비즈니스 룰을 코드로 명시 자가 의도)
+
+> *"한마디로 '도메인 규칙에 맞는 값을 사용자로부터 얻을 때까지 반복하는 기능'에 대한 책임을 특정 클래스에 위임하는 것이 좋다고 생각해서 ReadValueSureModifier 클래스에 위임했습니다. 이것은 불필요한가요?"* — ki960213 (책임 응집 자가 정당화)
+
+> *"불필요하다고 생각하지 않습니다! 오히려 설명해주신 부분을 들어보니 reasonable 하다는 느낌을 받았씁니다 👍"* — vagabond95 (학생 정당화 후 인정)
+
+> *"저의 개인적인 경험으로 unique 해야하는 컬렉션이라면 Set 으로 선언이 되었을 때, 도메인의 의도를 좀 더 쉽게 파악할 수 있더라구요 :)"* — vagabond95 (개인 경험 메타 어휘)
+
+## 얻은 교훈
+
+1. **`항상 true 인 조건문 = 비즈니스 룰을 코드로 명시 의도`** — *학생이 *항상 true 여도 비즈니스 룰 표현 가치*. **MCP 룰 후보 `business-rule-explicit-in-code`** = *항상 true 시그널이 *런타임 비효율* 이지만 *문서화 가치*. PR #91 (murjune *논리적 오류 자가 정당화*) 결.
+
+2. **`object 싱글톤 vs 인스턴스` 생명주기**. PR #46·#16 결.
+
+3. **`Set vs List` 일급 컬렉션 양가성** — *Set = 의도 명시 / List = 사용자 친화 검증*. PR #23·#26 의 *반대 시점*. **MCP 룰 후보 `set-vs-list-firstclass-collection`**.
+
+4. **`toKorean` 단일 locale 명명 = 다국어 확장 어려움**. **MCP 룰 후보 `single-locale-method-name`**.
+
+5. **`Const.kt` / `BlackJackRule.kt` 같은 *일반 명명 파일* = 비대화 시그널**. **MCP 룰 후보 `general-name-class-bloat`**.
+
+6. **`일관된 접근자 패턴`** — *value vs toList vs cards 혼재 = 사용자 혼동*. **MCP 룰 후보 `inconsistent-accessor-pattern`**.
+
+7. **`ReadValueSureModifier` 응집 = 학생 자가 책임 위임 모범** — *사용자 입력 재시도 + 도메인 규칙 검증을 한 클래스에 위임*. **MCP 룰 후보 `input-retry-cohesion`**.
+
+8. **`InputView` 핵심 역할 3 단계 메타 질문 → 학생 자가 답변** — *"무엇이 InputView 책임인가?"* 자가 정의. PR #66·#43·#107·#9 결.
+
+9. **`개인 경험 메타 어휘`** — vagabond95 의 *"저의 개인적인 경험으로"* — **MCP `oh-my-oop` 핵심 가치 완전 합류** (9 reviewer 모두 사용). PR #43·#23·#26·#46·#91·#107·#137 결.
+
+10. **`히스토리를 들어보니`** — *대화형 분석 메타 어휘* = *reviewer 가 학생 의도 파악 후 답변*. PR #46·#91·#107 결.