[1단계 - 블랙잭 게임 실행] 재즈(함석명) 미션 제출합니다.

[seokmyungham]

현구막 안녕하세요~ 이번 블랙잭 게임 리뷰를 부탁드리게 된 재즈라고 합니다😊
세 번째 미션이라 이젠 조금 익숙해지려 하다가도, 사다리 미션보다 난이도가 확 올라간 느낌이라서 또 새롭네요 ㅎㅎ
객체의 역할이 다양해지니까 점점 더 재미있어지는 것 같아요 🔥

게임 로직을 구현하는 방법이 정말 다양할 것 같아서
리뷰 하시는데 코드 인지적 비용을 덜어드리고자.. 게임 흐름 명세와 함께 궁금한 부분들 질문드립니다!

블랙잭 게임 흐름

• Dealer와 Player는 공통적으로 추상 클래스 BlackjackGamer를 상속 받습니다.
• Dealer, Player 서로 카드를 받는 조건이 다르므로 각각 추상 메서드를 오버라이드합니다.
• "카드 패"를 의미하는 Hand 객체에서 자신의 카드 점수를 계산하고, 딜러의 점수를 플레이어에게 넘겨주어 플레이어는 자신의 승, 패 여부를 결정합니다.
• 플레이어에 따른 승, 패 여부를 출력해야 하므로, Players에서 이름과 게임 결과를 매핑하여 Dto로 반환합니다.
• 플레이어들의 게임 결과를 Dealer 로 넘겨주어, 딜러의 게임 결과를 집계하고 Dto로 반환하도록 하였습니다.

미션을 진행하면서 궁금했던 점

출력 형식에 의존하는 Enum CardNumber CardShape?

이번 미션에서 카드 번호와 카드 문양을 상수로 활용하고자 Enum 클래스로 만들게 되었어요.
현재 두 Enum 모두 문자열 name을 필드로 가지고 있는데요, 페어와 저 모두 문자열 name은 지금 출력에 의존 하고 있는게 아닐까? 라는 생각을 가지고 있습니다.
출력 요구사항이 "J하트" 에서 "JACK하트"로 변경되면 도메인(Enum)을 수정해야 하기도 하고, 도메인을 지키지 못하고 있다는 느낌이 큰 것 같아요..

페어와 의견을 나눠보면서 현재 Enum에서 문자열 필드를 제거하고, view 패키지에 Enum을 출력 형식으로 변환해줄 수 있는 Enum CardShapeToSymbol같은 중간 다리를 하나 추가하는 방법을 제가 제안해봤는데 아직 서로 확신이 없는 것 같습니다.

현재 CardNumber와 CardShape가 출력 형식에 의존하고 있는 것 같은지,
제가 위에 작성한 방법에 대해 어떻게 생각하시는지 현구막의 의견을 듣고 싶어요!!

Dto를 사용하는 것을 어떻게 생각하시는지, 사용한다면 Dto 생성 로직의 위치

저번 사다리 미션에서 Dto를 사용하면서 조금 번거롭기도 했고 코드를 가볍게 가져가고 싶어
"다음 미션에는 Dto를 사용하지 말아야지!!" 라고 다짐했는데 이번에도 Dto를 사용하게 되었어요.

도메인 전체 구조를 뷰에 노출시키지 않고 싶으면 컨트롤러에서 도메인의 필드 원시값을 꺼내서 넘겨도 되지만,
Dto 사용 시 내가 원하는 값들만 모아서 전달할 수 있다는 장점과
Map<String, boolean> 처럼 게임 결과를 넘기게 되었을 때 이 코드를 처음 보는 개발자가 저 안의 엔트리 값이 뭘 의미하는지 해석하는 인지적 비용을 줄일 수 있고
Dto에 이름을 붙일 수 있다는 점이 매력적으로 다가왔던 것 같아요.
그리고 Dto 생성 로직이 도메인 내부에 존재하면서 getter도 거의 사용하지 않아 getter 오용의 위험성을 어느정도 방지한 것도 긍정적인 부분이었던 것 같습니다.

그런데 현재 Dto 생성 로직이 도메인 내에 존재하는데,
Dto개수가 늘어남에 따라 중요하지 않은 Dto 생성 로직이 불필요하게 많아지는 것 같다고 느껴요.

Dto 생성 로직을 Dto 내부로 옮기고 컨트롤러에서 getter를 사용해서 생성한다면 걱정을 해결할 수 있지만 지금도 100줄이나 넘는 컨트롤러 로직이 더 복잡해질 것을 우려해서 도메인 내부에서 생성하도록 결정하게 되었습니다.

은총알은 없고 트레이드 오프를 항상 고려해야 하지만
현재 제 코드는 미숙한 부분들이 너무 많다고 느끼고
이번 미션을 진행하면서 개선해야 할 부분들에 대해 현구막께 많은 것을 배우고 싶어요!! 😀

긴 글과 코드 읽어주셔서 감사하고
리뷰 기다리고 있겠습니다!!
감사합니다 😄

[Hyeon9mak]

안녕하세요 재즈~ 블랙잭 미션을 함께할 현구막입니다. 🙇‍♂️
블랙잭 구현 잘 진행해주셨네요~ 고민이 많으셨던거 같아요~

출력 형식에 의존하는 Enum CardNumber CardShape?

앗~ 마침 관련된 코멘트를 여러번 반복해서 남겨두었어요 😄 👍
결론을 말씀드리면 domain 내부 enum 에서 출력에 의존하지 않도록 변경해주셔야합니다.
그리고 그 이유를 정확하게 알고 계신 것 같아요 💯

"J하트" 에서 "JACK하트"로 변경되면 도메인(Enum)을 수정해야 하기도 하고

이미 정확한 이유를 알고 계셨다니... 사실 반복해서 출력 의존 관련 코멘트를 남기지 않아도 되었겠다는 생각이 드네요 🤔
다음 리뷰 요청에 모두 개선해주실거라 기대합니다 👍

Dto를 사용하는 것을 어떻게 생각하시는지, 사용한다면 Dto 생성 로직의 위치

Dto 사용 시 내가 원하는 값들만 모아서 전달할 수 있다는 장점과 Map<String, boolean> 처럼 게임 결과를 넘기게 되었을 때 이 코드를 처음 보는 개발자가 저 안의 엔트리 값이 뭘 의미하는지 해석하는 인지적 비용을 줄일 수 있고 Dto에 이름을 붙일 수 있다는 점이 매력적으로 다가왔던 것 같아요.

우선 DTO 를 왜 사용하는지, 어떤게 장점인지 명확히 알고 계신 점은 콕 짚어서 박수드리고 싶어요. 👏
크루들에게 자랑하셔도 좋을거 같아요. 💯 👍

고민하신 것과 같이 DTO 생성 위치는 분명히 고민해보셔야할 것 같아요.
DTO(Data Transfer Object)는 순수하게 계층간 데이터 전달을 위해 사용되는 객체죠.
그만큼 절대로 로직을 담지 않게 간단히 만들고, 언제든지 변경되고 삭제할 수 있는 객체에요.
즉, CardDto 는 쉽게 변하는 객체입니다.

반대로 Card 는 블랙잭 게임이라는 비즈니스에 있어 핵심이 되는 객체라고 볼 수 있어요.
ACE 여부를 판별하는 로직도 갖고 있고, 오랜 세기를 거쳐 전세계인에게 공동의 상식으로 만들어진 도메인이라 잘 변화하지 않습니다.

... 여기까지 말씀드리면 이해하셨으리라 생각해요! 😄 👍

지금도 100줄이나 넘는 컨트롤러 로직이 더 복잡해질 것을 우려해서 도메인 내부에서 생성하도록 결정하게 되었습니다.

controller 가 비즈니스 로직을 품어도 되는 걸까요? controller 는 view 와 domain 의 소통을 담당해야하는데 ... 🤔
controller 도 하나의 객체와만 대화를 진행하면 domain 과 view 의 소통에만 집중할 수 있겠네요!

그 외에도 간단한 코멘트 몇 가지 남겼습니다.
궁금하신 점 추가로 코멘트 남겨주세요 🙇‍♂️

[Hyeon9mak]

안녕하세요 재즈~ 피드백 잘 반영해주셨어요.
이번 단계를 진행하시면서 생성자 개방에 대한 거부감이 줄어들고,
출력모델과 DTO, 도메인 모델 사이 의존방향에 대한 재즈만의 기준이 확립되셨길 바랍니다~

몇 가지 간단한 코멘트 남겼는데, 다음 단계를 진행하시면서 함께 고민해주세요.
다음 단계에서 만나요~