객체 지향 설계 연습하기 - 블랙잭 (8)
들어가며
- 업무에 Java를 사용하고 있지만, 깊은 이해도가 부족하다는걸 절감.
- 단순 객체 생성 및 비즈니스 로직 구현에만 매달리고 있음. 회의감이 듦.
- 신규 개발 뿐만 아니라 유지 보수 및 리팩토링시 객체 지향의 묘미를 살려보고자 함
- 객체 지향적 시야와 사고는 연습뿐이라는 것을 여러 커뮤니티에서 수집
- 객체 지향 설계 연습을 통해 객체 지향적 시야와 이해력을 높이고지 함
UML 4번째 버전입니다.
- 허허 UML 기호 정리 후 제가 그린 UML이 완벽하게 잘못되 있다는걸 늦게 깨닳았습니다.
Denomination, Suit의 Card 클래스와 관계
카드는 모양과 끗수를 반드시 가지고 있어야 합니다. 두 개는 카드에 필수적인 존재입니다. 의미적으로 보면 세개의 관계가 Composition 강집합 관계인것 처럼 보입니다. 다만 enum과 class의 관계에에서 특정 enum의 레퍼런스를 유지하는 관계는 dependency로 표현한다는 stackoverflow의 의견이 있어 조금 헷갈리지만, dependency로 표현 했습니다.
Card와 Deck의 관계
Deck은 카드의 52장 모음 입니다. 덱의 존재 가치는 카드 52장의 합으로 의미가 부여되고, Deck 내부 생성자에서 Card를 new 키워드로 52장을 생성하기 때문에 Life Cycle 또한 같다고 보여져 Composition 관계로 설정했습니다.
Deck과 Dealer의 관계
Deck은 딜러의 존재 가치입니다. 딜러가 카드를 나눠주기 위해 카드 52장을 가지고 있고, 해당 카드 모음을 Deck이라고 지칭하며, 한 게임에서 한개의 덱은 딜러만 들고 있을수 있습니다. Dealer의 생성자에서 Deck을 new 키워드로 생성함으로 Composition 관계로 설정 했습니다.
Hand
이부분에서 상당히 헤맸고, 아직도 헤매고 있습니다. Hand는 각 유저가 들고 있는 카드로 표현되는 추상적인 개념인데, Hand는 Card의 모음으로 유지 됩니다. 다만, Card 자체의 레퍼런스는 Hand에서 유지되는게 아닌 Deck에서 유지되는데, Hand는 Deck의 존재를 모르므로, Card와 라이프 사이클이 같지 않은 aggregation 관계로 설정 했습니다.
User, Rule
User 또한 추상적인 개념으로 생각했습니다. 비슷한 개념으로 Human, 오스트랄로피테쿠스(?) 처럼 사람의 특성 시대적 표현 또는 인간 이라는 인류 전체적 단어로 설정된것 처럼, User 또한 게임이라는 틀안에서 모든 사람을 지칭하는 단어로 생각했고, 추상 클래스로 잡았습니다. 또, User는 게임 내에서 Hand를 가지고 있어, 상속받아 사용했으며 Rule이라는 규칙에 얽메이므로 Interface를 구현했습니다.
Dealer, Player
딜러와 플레이어는 의외로 간단했습니다. 딜러와 플레이어는 기본적으로 룰을 적용받고, Hand를 가지고 있지만 유일한 차이점은 딜러는 Deck을 가지고 있다. 입니다.
Source Code는 바뀐게 없습니다.
gist:ppzxc/5362c6a83e87ade07cc19cc8070b7127
끝으로
UML 기호 정리를 통해 UML 표현법과 각 의미에 대해 배웠으며, 해당 개념을 적용했습니다. 아직도 헷갈리는 부분과 저 스스로 납득이 되지 않는 부분이 여러모로 많습니다. 더욱더 치열하게 분석을 진행해 보겠습니다. 다음편은 드디어 블랙잭 게임을 구현해 볼수 있길 고대하겠습니다.