[우아한 테크코스 5기] 블랙잭 1단계 학습 로그

---

들어가며

GitHub 저장소

구현 기능들

궁금한 것

코드 리뷰 

후기

---

📆 기간 : 2023.02.28~ 2023.03.02

23.01 라스베가스에서 블랙잭을 하다

---

들어가며

이번 블랙잭 미션은 페어 루쿠와 함께 진행하게 되었다. 초반에는 잘 진행하였으나 중후반 들어서 서로 의견이 대립되는 경우가 많아졌고 나와 페어는 미션기능 구현을 빠르게 마쳐야 된다는 생각에 제대로 요구사항을 만족시키지 못했던 것 같다.

Shuffle, 상속, 도메인 등등.. 에서 대립이 되었지만 조급해지다 보니 지금은 넘어가고 나중 리팩토링 때 하자 라는 말로 계속 뒤로 미뤘던 것 같다. TDD로 잘 작성하였으나 구조 설계에서 문제가 있었던 것 같다.

---

GitHub 저장소

블랙잭 1단계 PR 깃허브 주소

---

구현 기능 목록

Card

카드 Number와 카드 Pattern을 가지고 있는 카드 객체이다. 52장의 Card를 만든다는 생각으로 구현하였다.

카드는 Ace계산을 위해 Ace를 판별하며, 카드 값과 이름을 반환 해주는 메서드를 가지고 있다.

CardPattern

enum 타입으로 SPADE,DIAMOND,HEART,CLOVER 값을 가지고 있다.

CardNumber

enum 타입으로 Ace~10,J,Q,K 값을 가지고 있다.

CardGenerator

카드 패턴과 카드 넘버로 부터 카드 덱을 생성한다. 이 과정에서 shuffle과정이 있었는데 나는 전략패턴으로 빼자 라는 의견이었고 페어는 안에서 사용하자 라는 의견이었다. 이 과정이 대립되었고 리팩토링 과정에서 전략패턴으로 분리하였다.

CardDeck

카드 덱은 Queue에 카드를 가지고 poll 하는 방식으로 구현하였다. 이는 실제 카드덱이라고 생각하여 진행하였다.

 

Dealer

dealer는 Player를 상속하게 하였다. 나는 Player의 자식을 딜러라고 생각해도 될 것 같아서 이렇게 구현하였다. 하지만 주변 크루들은 참여자들을 두고 참여자들을 따로 dealer와 player가 상속받도록 진행한 것 같다.

Name

참여자의 이름 원시값을 포장한 객체이다.

Player

게임에 참여하는 Player들이다. dealer의 조상으로 카드를 추가하고, blackjack초과 여부, card,name getter 메서드를 가지고 있다.

Players

Player리스트를 가지고 있는 일급 컬렉션이다.

BlackJackGame

게임을 관리할 수 있는 game 도메인이다. 내가 생각했던 Game은 카드분배 메세지를 전달하고 결과를 총괄하는 역할이었다. 인스턴스 변수의 개수 제한으로 어떻게 설계해야 할지 막막했던 부분인 것 같다.

Result

enum 타입으로 승,무,패를 가지고 있었고 player의 승무패를 토대로 Reverse 하는 방식으로 dealer의 승무패를 계산할 수 있도록 하였다.

---

궁금한 것

인스턴스 변수의 제한 목적

인스턴스 변수가 많다는 것은 객체의 역할 분리가 잘 되어있지 않다는 것이다. 인스턴스 변수를 줄임으로써 객체의 역할을 분리할 수 있다고 본다. 하지만 아직 잘 모르겠다.. 개인적으로 게임 도메인은 카드, 카드덱, 결과를 가지고 있어야 할 것 같았는데 나는 카드, 카드덱으로만 구성하였다. 이렇게 구성하는 것이 옳을지 고민이다.

Controller가 어디까지 해야하는가

컨트롤러는 model과 view를 연결하는 것이다.  View의 입력을 도메인에 전달할 뿐 상태를 변화시키면 안 된다. 완태의 의견은 ex) 하나의 game도메인을 통해서 메시지를 전달한다.인데 그러면 game 도메인의 역할이 너무 많아지는 것은 아닌가 고민이 된다.

Domain에서 getter 사용 시 원시값 풀어서 반환과 객체로 반환 무엇이 좋을까

 원시값 포장을 하는 것은 원시값이 아닌 의미 있는 객체로 포장을 했기 때문에 원시값을 풀지 않고 반환하는 것이 옳다고 생각했다. 하지만 그렇게 진행하다 보면 View가 도메인에 의존적이게 될 수밖에 없다고 생각한다. 이 경우 Dto를 쓰는 게 옳을까?

View에서는 도메인을 어느 정도 알고 몰라야 하는가?

View가 도메인을 알 경우 도메인의 비즈니스 기능이 노출된다고 생각한다. 그리고 의존성이 생긴다고 보는데, 중간 객체를 둔다면 도메인이 캡슐화되어 기능을 숨길 수 있다는 장점이 있고 의존성이 떨어질 수 있다고 본다. 그래서 중간객체를 쓰나 보다..

---

코드 리뷰

커밋 단위를 테스트와 기능을 같이 함으로써 모든 테스트가 통과하도록 하면 좋을 것 같다.

Domain의 로직이 Controller에서 많이 실행되는 것 같다.

View와 도메인의 검증 역할은 다르다.

결과 검증 로직 분리

Command enum타입으로 관리하면 좋을 것 같다.

도메인에서 View에 의존적이지 않은 코드를 작성할 것

---

나가며

이번 블랙잭 미션은 TDD를 잘 지켜서 구성한 것 같아서 나름? 만족스럽다. 하지만 코드의 구조, 설계, 구현 모든 게 맘에 들지 않았다. 또한 페어 프로그래밍도 너무 어려웠다.

다음 미션에서는 정적 팩토리 메서드와, 엔티티와 값객체 (헷갈려서..) 분리를 통해 잘 작성해보고 싶다.

모든 것이 맘에 들지 않는 블랙잭 미션이다. 내 실력이 문제인 것 같기도 하고..

다른 크루들은 엄청 잘하는 것 같아서 더 열심히 해야겠다는 생각뿐이다.