oh-my-oop 0.2.0

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

@@ -0,0 +1,253 @@
+# PR #80 — [블랙잭 1단계] 호두 미션
+
+- **Reviewee:** [@Junyoung-WON](https://github.com/Junyoung-WON)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/80
+- **단계:** 1단계
+- **리뷰어:** @vagabond95
+- **라인 코멘트:** 19 스레드 — *PR 본문 변경사항 정리 풍부 (BaseHuman 제거 + 콜백 함수명 변경 + 콜백헬) + BaseHuman 추상화 자가 인정 + value class 활용 기준 자가 학습*
+- **신규 reviewee** (2024 코호트). PR #66·#82·#31 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 변경사항 자가 정리 풍부** — **3 가지 변경사항 자가 명시**:
+  1. *"불필요한 상속 제거 — BaseHuman 클래스를 제거하여 불필요한 클래스 상속을 없앴습니다. (...) 이름이란 특성이 필요하지 않은 Dealer는 humanName 속성을 제거하였습니다."*
+  2. *"콜백 함수명 변경 — DM으로 다시 답변주신 내용들을 바탕으로, 콜백 함수의 네이밍이 결국 Model과 View가 서로 의존적인 관계를 갖도록 만든다고 이해했습니다. (...) 콜백 함수명을 `print`, `show`라는 이름에서 `return`, `get`이 들어간 이름으로 변경하여 View와 Model 사이의 연관성을 퇴색시켜보았습니다."*
+  3. *"콜백헬 문제 일부 개선"*
+  
+  **PR 본문 변경사항 자가 정리 = 학습 가시화 매개체**. PR #46·#107·#145·#82·#76·#39 결.
+- **`BaseHuman` 추상화 자가 인정 + 자가 제거** — vagabond95: *"인터페이스 구현이 아닌 상속으로 구현해야 할 이유가 있을까요? 한번뿐인 상속 기회를 사용할 때는 신중한 검토가 필요합니다!"* + 학생 자가 답변:
+
+> *"지금 다시 확인해보니, 리뷰어님의 말씀대로 BaseHuman은 상당히 불필요한 분리라고 생각이 드네요. BaseHuman의 구현의 목적은.. 1. 단순히 플레이어/딜러라는 객체가 인스턴스 변수를 사용하는 개수를 줄이기 위함 2. 추후 2단계 미션 진행에서 배팅금을 가지고 활용하는 타입. 이렇게 두 가지였습니다.*
+>
+> *하지만 추상화를 하여 일반화를 했다면 그를 상속받는 두 가지 이상의 하위 타입들은 그들 각자만의 특수성이 존재해야 하는데, 현재 구현은 BaseHolder가 있고 그것을 다시 상속받는 Dealer와 Player만이 존재하네요. 다형성의 요소로 활용하지 않는다는 말씀을 이제서야 이해했습니다."*
+
+vagabond95 칭찬: *"스스로 잘 고민해주셨네요! 공통적인 기능을 묶고자 할 때, 인터페이스/추상클래스를 떠올리고 구현하는 것은 좋은 접근 방식이라고 생각됩니다. 다만, 이것은 불필요하게 추상화 계층을 만들거나 상속 기회를 써버리는 경우도 있으므로 해당 케이스처럼 다형성의 요소로 잘 활용할 수 있는지 같이 고민이 되면 더 좋을 것 같습니다 ㅎㅎ"*
+
+**MCP 룰 후보 `unnecessary-abstraction-without-polymorphism`** = *다형성 X = 추상화 불필요*. PR #145·#76·#39·#31·#77·#100 의 *pattern-applied-without-need* 결.
+
+- **`plus operator` Kotlin 어휘 활용** — vagabond95: *"plus operator 활용 👍"*. PR #46·#86·#23·#100 결.
+- **`Finished` 종료 상태 한번 더 구분** — vagabond95: *"Finished 로 종료 상태 한번 더 구분 👍"*. PR #98·#39 결.
+
+## 못한 점 (설계 관점)
+
+### 1. `model.print` View 의존 → `alert` 콜백 명 변경 자가 학습
+
+vagabond95: *"print 는 controller 를 넘어 view 가 수행해야할 일인데, 어떻게 model 이 미리 알고 있을 수 있을까요?"*
+
+학생: *"콜백 함수의 이름을 `printDealerDrawCard` 에서 `alert` 로 변경하였습니다. 그리고 Dealer의 drawDealerCard 메서드까지 콜백 함수가 호출될 필요성은 없다고 생각하여 딜러가 카드를 뽑은 횟수를 반환 받아 해당 횟수를 콜백 함수를 통해 전달하도록 구성을 바꾸어 보았습니다."*
+
+vagabond95 추가: *"콜백의 네이밍을 바꾸는 시도 👍 그런데 alert 의 대상이 구체적으로 명시되어야 할 것 같아요."*
+
+학생: *"`alert`라는 함수명이 조금 모호한 것 같네요. 어떤 값을 전달하는지를 명시하기 위해서 `alertCountOfDraw`로 함수명을 바꾸어보았습니다."*
+
+→ **3 가지 학습**:
+
+#### 1.1. *콜백 명명 = Model 의 View 의존 시그널*
+
+- *`printX`, `showX`* = View 동사 → Model 이 View 알기.
+- *`alertX`, `returnX`, `getX`* = 일반 동사 → Model 무관.
+
+**MCP 룰 후보 `callback-naming-view-coupling`**. PR #82 (Hevton *Answer 도메인 vs View*) / PR #107 결.
+
+#### 1.2. *콜백 명명 = 대상 명시*
+
+*`alert`* (대상 모호) → *`alertCountOfDraw`* (대상 명시) — 학생 자가 학습.
+
+#### 1.3. *Dealer.drawDealerCard 콜백 X + 횟수 반환*
+
+- *콜백 = 매번 호출* → *횟수 반환 = 결과 전달 + 호출자가 횟수만 받음*.
+- *side effect 감소 + 함수형 정공*.
+
+### 2. `displayName` enum 영역 누수 (다수)
+
+vagabond95 1차 (CardNumber): *"displayName 은 view 에서 활용되는 값인데, model 에서 알 필요가 있을까요~?"*
+
+학생 자가 학습: *"이번 피드백과 수업에서 배운 내용들을 다시 고민해보니, view가 메시징을 통해 model에게 값을 요청하면, model은 약속된 메시지(메서드)를 받았을 때 적절한 값을 주도록 구현하는 것으로 이해하였습니다. 그렇다면 model이 굳이 알 필요가 없는 `displayName`이라는 이름을 변경하거나, 각각의 요소(ACE, FIVE, KING 등)에 따라 적절한 문자로 반환해주는 메서드를 생성한다면 model과 view의 역할 분리가 잘 이뤄진 것으로 볼 수 있을까요?"*
+
+학생 자가 적용: *"CardNumber의 `displayName` 속성을 제거하고, `display()` 라는 확장 함수를 작성해서 카드에 따라 출력할 문자를 반환하도록 구현해보았습니다!"*
+
+vagabond95 2차 (Pattern): *"마찬가지로 displayName 은 모델에서 알 필요가 없는 값으로 보입니다~!"*
+
+학생: *"`Pattern` 에서의 `displayName` 도 `CardNumber` 와 마찬가지로 `display()` 확장함수를 작성하여 각 패턴에 따라 출력 문자열을 반환하도록 구현해보았습니다!"*
+
+vagabond95 3차 (확장 함수 위치): *"확장 함수 활용 👍 함수를 잘 분리해주셨네요, 그런데 해당 함수가 model 패키지에 있는 것이 적절할 지 고민해보면 좋겠습니다."*
+
+학생 자가 답변 + 외부 자료 조사:
+
+> *"처음에는 model 뿐 아니라 view에서도 활용될 수 있는 일종의 도구의 책임을 다하는 함수라 생각했습니다. 그래서 단순히 해당 함수를 util 패키지를 만들어서 그곳으로 옮길 생각이었습니다. 그런데 util 패키지가 정확하게 무슨 용도인지 알고 활용하는 것 같지 않다 생각해서 util이란 패키지에 대해 조금 더 알아보았습니다.*
+>
+> *> util 패키지는 프로젝트 전역에서 사용되며, 비즈니스 로직에 의존하지 않는 특정 로직이나 기능을 모아놓은 패키지이다.*
+>
+> *일반적으로 문자열 생성/수정이나 랜덤값 생성, 날짜나 시간 처리에 관련된 클래스 또는 메서드를 util 패키지에서 관리하고 사용한다고 합니다. 특정 도메인이나 계층에..."*
+
+→ **5 가지 학습**:
+
+#### 2.1. *enum displayName 도메인 누수 — 다수 발생 패턴*
+
+- *CardNumber, Pattern, Suit 등 다수 enum 에 displayName 누수*.
+
+**MCP 기존 룰 `enum-with-ui-value`** 강화. PR #137·#77·#23·#26·#16·#9·#11·#13·#82·#22·#86·#100 결.
+
+#### 2.2. *학생 자가 *학습한 내용 정리* 명시*
+
+*"이번 피드백과 수업에서 배운 내용들을 다시 고민해보니, view가 메시징을 통해 model에게 값을 요청하면..."* — **수업 학습 + reviewer 피드백 + 자가 학습 통합**.
+
+#### 2.3. *`display()` extension function 자가 적용*
+
+학생이 *displayName 제거 + display() extension function*. PR #13 (vagabond95 *Kotlin 어휘 사용 기준*) / PR #9 (Choisehyeon *확장 함수 4 분면*) 결.
+
+#### 2.4. *util 패키지 자가 정의*
+
+학생이 *외부 자료 조사 후 util 패키지 정의 자가 인용*. PR #13 (vagabond95 *etc 패키지 안티패턴*) / PR #16·#11 결.
+
+#### 2.5. *학생 자가 *util 패키지 활용 의문* + 외부 자료 조사*
+
+**학생 자가 학습 + 외부 자료 모범**. PR #46·#107·#22·#91·#77 결.
+
+### 3. `deepCopy → setResultTo` 명명 자가 학습
+
+vagabond95: *"기존에 있던 값에 새로운 값을 더해주는 것이므로 copy 라고 보기 어렵지 않을까요?"*
+
+학생: *"처음에는 단순히 깊은 복사를 하여 result를 새로 생성해서 deepCopy로 이름을 지었는데, 지금 보았을 때는 새로운 값을 더해주는 행위를 하니 deepCopy라는 이름은 적절하지 않은 것 같네요. 행위에 알맞은 다른 이름으로 바꿔보겠습니다!"* + *"`deepCopy` 메서드 명을 `setResultTo` 로 바꾸어 사용하는 용도와 의미가 잘 와닿도록 변경하였습니다!"*
+
+vagabond95 후속: *"이전에 활용해주셨던 plusOperator 를 활용해주셔도 좋을 것 같아요. setResultTo 는 기존의 값에 새로 덮어씌우는 것으로 오해의 소지가 생길 수도 있어보입니다."*
+
+학생: *"`Hand` 에서 활용했었던 plus operator처럼 `GameResult` 에서도 plus operator를 적용해보았습니다! plus operator를 활용하니 `data class` 로서 활용했던 `copy` 메서드의 사용 이유가 사라진 것 같아, `GameResult` 클래스를 일반 클래스로 변경하였습니다."*
+
+→ **4 가지 학습**:
+
+#### 3.1. *deepCopy 명명 = 실제 동작과 불일치*
+
+- *학생 deepCopy = 새 값 + 더하기*.
+- *실제 deepCopy = 깊은 복사 (재귀적 동일 객체 복제)*.
+
+PR #39 (rhthrhrl0 *deepCopy 정말?*) 결.
+
+#### 3.2. *setX 명명 = 덮어쓰기 추정*
+
+*setResultTo* — *덮어쓰기 추정*. *plus operator* 가 더 정확.
+
+#### 3.3. *plus operator 활용 = data class copy 불필요*
+
+학생 자가 *data class → 일반 class* 변경 자가 학습.
+
+#### 3.4. *학생 자가 *명명 → operator → data class 제거* 3 단계 진화*
+
+PR #46 (krrong *operator times*) / PR #100 (Hevton *plus operator + data class 제거*) 결.
+
+### 4. `Hand` 일급컬렉션 역할 + state 분리
+
+vagabond95: *"hand 는 유저가 소지한 카드를 관리하는 일급컬렉션의 역할 하나만 해보는 것은 어떨까요?"*
+
+학생 자가 의문: *"그렇다면 리뷰어님의 말씀은 Hand와 현재 Hand가 갖고 있는 카드의 상태(BUST, BLACKJACK 등)를 분리하는 것으로 리팩터링을 해보라는 말씀이신가요?"*
+
+학생 자가 적용: *"`Hand`가 갖고있던 `state: UserState` 프로퍼티를 `Hand`로부터 분리하였고, `Hand`와 `State`를 갖는 `Status` 클래스를 생성하여 `Player`가 멤버 변수로 사용하도록 변경해보았습니다."*
+
+→ **일급 컬렉션 = 단일 책임**. PR #99·#74·#108·#133·#46·#39·#82·#107 결.
+
+### 5. `value class` 활용 기준 자가 학습
+
+vagabond95: *"value class 를 활용하시는 기준은 무엇이신지 궁금합니다!"*
+
+학생: *"value class가 객체 생성 시 발생하는 비용을 줄여주는 것으로 알고 있습니다. 원시값을 포장할 때에 활용하며 런타임에서 해당 객체를 사용하는 객체에게 Property로 원시타입 값만을 넘겨주어, 메모리와 성능 면에서 이점이 있다고 생각했습니다. 이번 구현에서는 플레이어의 이름을 프로퍼티로 갖는 BaseHuman에서 활용하기에 좋을 것 같아 사용해보았습니다."*
+
+→ **value class 자가 학습 + 활용 기준 명시**. PR #77 (murjune *value class 활용*) 결.
+
+### 6. `Participants.check` 함수명 = 부수 효과
+
+vagabond95: *"check 라고 하기엔 상태를 저장하는 일들도 수행하고 있으므로, 해당 함수의 네이밍이 개선되어야 할 것 같아요."*
+
+학생: *"네, 플레이어와 딜러의 카드 상태를 확인 후 승패 결과인 result를 변경하는 일을 하니 다른 이름으로 바꾸는 것이 좋을 것 같네요...! checkBust 뿐 아니라 checkBlackJack 등 다른 메서드의 이름도 좀 더 고민해서 바꿔보도록 하겠습니다~"*
+
+→ **함수명 = 동작 + 부수 효과 명시**. PR #76·#99·#9·#39 결.
+
+### 7. `GameDeck` 카드 재사용 자가 학습
+
+vagabond95: *"해당 값은 바뀌지 않으므로 재사용해봐도 좋겠습니다 :)"*
+
+학생: *"카드의 종류와 장 수는 변하지 않고 그대로이니, 최초 한 번 생성한 카드 리스트를 재사용할 수 있겠군요. companion object 키워드를 활용해서, GameDeck을 생성하거나 재사용할 때 마다 처음 생성했던 카드 리스트를 불러오도록 해보겠습니다!"*
+
+→ **불변 카드 재사용**. PR #74·#108·#133·#23·#26·#46·#77·#22 결.
+
+### 8. `model.show` View 의존 자가 학습
+
+vagabond95: *"model 이 show 라는 행위를 어떻게 미리 알 수 있을까요? View 에 의존적인 코드로 보여요."*
+
+학생 자가 의문: *"앞서 주신 피드백과 같은 피드백이네요...! 아직 view와 model의 역할 분리가 익숙하지 않은 것 같습니다. 😭 model에서 직접적으로 InputView와 OutputView를 활용하지 않기에, 구현 당시에는 view와 model의 분리가 이루어졌다고 생각했었습니다. 이번에 해주신 피드백들을 보고서, view와 model 둘을 분리하는 것에는 callback으로 호출할 함수의 네이밍에도 신경을 써야하는 것도 포함되어있다고 이해했는데, 제가 잘 이해한 것인지 한번 더 확인받고 싶습니다!"*
+
+→ **콜백 명명 = 의존성 정의**. PR #82 (Hevton *Answer 도메인 vs View*) / PR #137·#107 결.
+
+### 9. `Player.show` 콜백헬 vs 콜백 명명 변경
+
+학생: *"콜백 함수를 사용하지 않고서 구현하는 방법을 좀 더 고민을 해보았는데, 사용자 입력('y', 'n')에 따라 카드 정보를 출력하도록 동작하려면 지금 상황에서는 콜백 이외의 방법 밖에 없다는 생각이 들었습니다. 그래서 해당 코드에서는 중첩된 콜백 함수를 그대로 사용했고, 대신 콜백 함수의 이름을 바꾸어서 model이 view에 의존한다는 의미를 퇴색시켜보았습니다."*
+
+→ **콜백헬 vs 콜백 명명 양가성**. PR #145·#107·#82·#100·#13 결.
+
+### 10. `State` 스스로 다음 상태 결정
+
+vagabond95: *"State 가 '스스로' 다음 상태를 결정해보도록 리펙토링 해볼 수 있을까요? 이렇게 리펙토링 되었을 때의 이점은 무엇이 있을까요?"*
+
+→ **State 다형성 + 자기 책임**. PR #98·#39·#43·#152·#93·#136·#90·#66 결.
+
+### 11. `네이밍 = 구체적 대상 명시`
+
+vagabond95: *"앞으로도 네이밍을 지을 때 동사만 있는 것보다, 구체적인 대상을 명시해주도록 신경쓰는 습관을 들이면 좋습니다!"*
+
+→ **명명 일반 권유**. PR #11·#66·#99·#9·#39 결.
+
+### 12. `addResult` 명명 (증감 연산자)
+
+vagabond95: *"증감 연산자를 사용한다면 addResult 가 더 적절하지 않을까요? :)"*
+
+→ **명명 = 동작 명시**.
+
+### 13. `BaseHolder` 클래스명 (부모 명명 자가 변경)
+
+학생: *"BaseHuman을 제거하였고, BaseHuman에 있던 name 속성을 Player만이 갖는 속성으로 바꾸었습니다. 딜러는 사용자에게 따로 이름을 입력받지 않으므로, 현재 구현에서는 Dealer라는 모델이 이름 속성을 가질 필요가 없는 것 같습니다."*
+
+→ **부모 추상화 제거 + 자식 특수성 명시**. PR #95 (송핑크 *Dealer 는 Player 의 변종?*) / PR #46 (krrong *Dealer → Participant*) / PR #16 (SeongHoonC *Dealer 이름*) 결.
+
+## 리뷰어 의견 요지 (vagabond95)
+
+19 코멘트 특징 (PR #66·#82·#31·#11·#13 와 동일 reviewer):
+
+- **메타 질문 어휘** — *"~ 이유가 있을까요?"*, *"~ 어떻게 model 이 미리 알고 있을 수 있을까요?"*, *"~ 활용하시는 기준은 무엇이신지 궁금합니다"* — 학생 자가 답변 유도.
+- **간결 + 짧은 권유** — *대다수 1-2 문장* + *상세는 학생 자가 답변에 위임*.
+- **`👍` 칭찬 분포** — *plus operator, 확장 함수, Finished 종료* 다수.
+- **`~!`, `:)` 어조** — 친밀한 표현.
+
+## 대표 인용
+
+> *"콜백 함수의 네이밍이 결국 Model과 View가 서로 의존적인 관계를 갖도록 만든다고 이해했습니다."* — Junyoung-WON (콜백 명명 = 의존성 시그널 자가 학습)
+
+> *"하지만 추상화를 하여 일반화를 했다면 그를 상속받는 두 가지 이상의 하위 타입들은 그들 각자만의 특수성이 존재해야 하는데, 현재 구현은 BaseHolder가 있고 그것을 다시 상속받는 Dealer와 Player만이 존재하네요. 다형성의 요소로 활용하지 않는다는 말씀을 이제서야 이해했습니다."* — Junyoung-WON (BaseHuman 추상화 자가 인정)
+
+> *"공통적인 기능을 묶고자 할 때, 인터페이스/추상클래스를 떠올리고 구현하는 것은 좋은 접근 방식이라고 생각됩니다. 다만, 이것은 불필요하게 추상화 계층을 만들거나 상속 기회를 써버리는 경우도 있으므로 해당 케이스처럼 다형성의 요소로 잘 활용할 수 있는지 같이 고민이 되면 더 좋을 것 같습니다 ㅎㅎ"* — vagabond95 (추상화 + 다형성 양립 메타)
+
+> *"이번에 해주신 피드백들을 보고서, view와 model 둘을 분리하는 것에는 callback으로 호출할 함수의 네이밍에도 신경을 써야하는 것도 포함되어있다고 이해했는데, 제가 잘 이해한 것인지 한번 더 확인받고 싶습니다!"* — Junyoung-WON (학생 자가 이해 확인 의문)
+
+## 얻은 교훈
+
+1. **`콜백 명명 = Model-View 의존성 시그널`** — *`print*`, `show*` = View 동사 / `alert*`, `return*`, `get*` = 일반 동사*. **MCP 룰 후보 `callback-naming-view-coupling`**. PR #82·#107·#137 결.
+
+2. **`불필요한 상속 = 다형성 X 안티패턴`** — *상속받는 하위 타입들이 *각자 특수성 X* = 추상화 불필요*. **MCP 룰 후보 `unnecessary-abstraction-without-polymorphism`**. PR #145·#76·#39·#31·#77·#100 의 *pattern-applied-without-need* 결.
+
+3. **`displayName → display() extension function`** — *enum 영역 누수 → extension function 분리*. PR #137·#77·#23·#26·#16·#9·#11·#13·#82·#22·#86·#100 결.
+
+4. **`deepCopy → setResultTo → plus operator → data class 제거`** 4 단계 명명 진화 — *학생 자가 *명명 정확성 + Kotlin 어휘 활용 + 불필요 객체 제거* 3 단계 학습*. PR #39·#46·#100 결.
+
+5. **`util 패키지 자가 정의`** — *전역 사용 + 비즈니스 로직 의존 X + 문자열/랜덤/날짜*. **MCP 룰 후보 `util-package-definition`**. PR #13·#11·#16 결.
+
+6. **`value class 활용 기준 자가 학습`** — *원시값 포장 + 메모리/성능 이점*. PR #77 결.
+
+7. **`Hand 일급컬렉션 + state 분리`** — *단일 책임*. PR #99·#82·#107 결.
+
+8. **`Participant.check` 명명 = 부수 효과 명시 필요** — *check = 확인만 / checkAndUpdate = 확인 + 변경*. PR #76·#99·#9·#39 결.
+
+9. **`State 스스로 다음 상태 결정`** — *다형성 디스패치*. PR #98·#39·#43·#152·#93·#136·#90·#66 결.
+
+10. **`구체적 대상 명시 명명`** — *동사만 X + 구체적 대상*. PR #11·#66·#99·#9·#39 결.
+
+11. **`수업 + reviewer 피드백 + 자가 학습 통합`** — *학생이 *수업에서 배운 내용 + reviewer 피드백 + 자가 학습* 통합 명시*. **MCP 룰 후보 `multi-source-learning-integration`**. PR #145·#107·#46·#91·#82·#100 결.
+
+12. **`외부 자료 조사 + 자가 정의` (util 패키지)** — *학생측 외부 자료 조사 모범*. PR #91·#77·#22 결.