[F-Lab 모각코 챌린지 16일차] Java : 블랙잭 게임 구현

 

도메인 모델링

 

블랙잭  룰을 보며 게임을 구성하는 요소들을 추출해봤다. 

1) 블랙잭 게임에 참여하는 참가자 2) 카드, 3) 카드덱, 4) 배팅 머니  4가지 도메인을 추출했다. 

 

블랙잭 게임에 참여하는 참가자

블랙잭 게임은 딜러와 게임을 하는 게이머가 필요하다.

이 둘의 본질은 "게임에 참여"하는 주체라 생각했다.

게임 참자가들은 블랙잭 게임 참가자는 돈과 카드가 필요하다. 그리고 돈과 카드로 게임에 참여하는 행위를 한다. 

 

그래서 게이머와 딜러의 공통 속성을 User 라는 상위 도메인으로  옮겼다. 

블랙잭 참자가여도 게이머와 딜러의 롤은 또 분리되기 때문에 User 를 상속하는 Dealer와 Gamer 로 분리했다. 

 

카드

카드도 User 도메인과 마찬가지로 Card 라는 Base class 를 확장하는 AlphabetCard 와 NumberCard 두 개의 자식 클래스를 생각했다. 카드를 알파벳과 넘버로 분리한 이유는 알파벳 카드는 알파벳을 가져야하고 넘버 카드는 숫자를 가져야하니 

고유의 상태값이 다르다 생각했기 때문이다. 

 

여기서 피드백을 받은 건 카드를 영문으로 표기하던 숫자로 표기하던 표현의 방식의 차이만 있을뿐 카드의 책임이나 역할은 동일하다였다. 

클래스를 분리할 땐 명확하게 역할과 책임이 다른것을 클래스로 분리해야 된다는 피드백을 받았다. 

 

아직 추상클래스와 인터페이스 각각의 목적을 잘 이해하는데 어려움을 겪었는데 실제로 설계하고 피드백을 받으니

살짝 감이 온다. 

 

카드덱

카드덱을 모델링할때는 현실에서 카드덱 역할을 반영했다. 

카드덱의 행동은 카드를 셔플하고 분배하는게 전부라 생각했다. 

그래서 카드 리스트 객체 생성을 가드덱에서 하는게 맞을까? 하는 의문에 카드 리스트를 직접 참조하기 보다는

카드 리스트 일급 컬렉션 객체를 참조하여 이 객체에게 카드를 요청하는게 맞지 않을까 ? 싶었다. 

과도한 분리인지 의견을 구해봤는데 역할을 다르게 정의했다면 분리하면 된다고 하셨다. 

 

---

소감

오늘은 도메인 코드만 짜보고 PR 을 받아봤는데 도메인 설계는 몹시 중요한데 또 정답은 없다는거.... 그래서 어려운가보다 설계가...

 

---

레이어드 패키지는 유지보수 어렵다 ?

1. 도메인 파악이 어렵다.
   • Company 도메인을 파악하거나 수정하려면 각 레이어별 패키지를 모두 확인해야 한다.
   • 도메인이 커질수록 더 그러하다.
2. 레이어별 패키지 구조에서는 한 클래스가 모든 use case 를 커버하기 위해 거대해지는 경향이 있다.
   1. CompanyRepository 를 참조하는 클래스가 많아질수록 CompanyRepository 변경이 점점 더 어려워진다.
   2. 예를 들면 DB 계층의 CompanyRepository 에 여기 저기서 필요한 모든 쿼리 메서드가 계속해서 추가될 가능성이 높다.
3. 접근 제어자 사용에 제한이 생긴다.
   • Company 도메인과 관련된 클래스들은 서로 다른 패키지로 흩어졌기 때문에 getter, setter 나 공개 메서드가 증가한다.
   • 접근 경로가 증가하므로 사이드이펙트 발생 빈도가 증가하거나 디버깅 범위가 넓어진다.