객체 지향 설계 연습하기 - 블랙잭 (10)
들어가며
- 업무에 Java를 사용하고 있지만, 깊은 이해도가 부족하다는걸 절감.
- 단순 객체 생성 및 비즈니스 로직 구현에만 매달리고 있음. 회의감이 듦.
- 신규 개발 뿐만 아니라 유지 보수 및 리팩토링시 객체 지향의 묘미를 살려보고자 함
- 객체 지향적 시야와 사고는 연습뿐이라는 것을 여러 커뮤니티에서 수집
- 객체 지향 설계 연습을 통해 객체 지향적 시야와 이해력을 높이고지 함
UML 6번째 버전입니다.
- 6번째 UML이 완성 됐습니다.
- Card는 Deck으로 합성 연관, Deck,은 Dealer까지 합성 관계로 묶여 있습니다.
- User 추상 클래스는, Hand 인터페이스를 구현합니다.
- Rule 인터페이스는 다형성을 사용하기 위해 STATEGY 패턴으로 User 추상 클래스에 변수화해서 사용합니다.
- Dealer와 Player는 User 추상 클래스를 상속하며, User로 인스턴스화 되게끔 구성해 다형성을 이용할수 있습니다.
- 따라서 모든 접근은 User 추상 클래스를 이용해 접근 되며 Board는 User와 Aggregation 관계에 있습니다. 결국 모든 유저는 main 클래스에서 생성되서 게임이 시작되니깐요.
- UML Class Diagram을 작성해본지 얼마 되지 않아 위 UML이 제가 작성한 코드와 다를 수도 있습니다.
소스코드
Suit, Denom, Card, Deck, Hand
- 큰 변화가 없는 Card 관련 클래스들 입니다.
- Hand만 Interface로 바뀌었고, 의존성 종속성이 없어졌습니다.
gist:ppzxc/9e1ea6c0a259eeb20c59d02c8b09d0b0
Rule, DealerRule, PlayerRule
- 다형성을 이용하기 위해 룰을 인터페이스화 시켜서 각각 딜러 룰과 플레이어 룰을 만들었지만, 의도치 않게 중복 코드가 발생했습니다.
- Board에서 Rule을 적용하려다 보니 불가피하게 중복 코드가 발생했는데요.
- 이
문제
는 해결을 뒤로 미뤄야 할것 같습니다…
gist:ppzxc/cf08989d7ba5bf55c700d029e24ef261
User, Dealer, Player
- 격변의 시기를 거친 유저 추상 클래스와 딜러, 플레이어 입니다.
- 유저와 딜러는 모든 메소드와 변수를
구현 (interface)
과추상 클래스 상속 (abstract)
으로 구현 됩니다. - 유일한 차이점은
딜러는 덱 (deck)을 가지고 있다.
뿐이죠.
gist:ppzxc/95eb5bd6b68112857a67669e8a19b0fd
Board, Main 클래스
- 처음 생성되어 실제 게임 로직이 구현될 Board와 Main 클래스 입니다.
- Board 클래스를 작성하면서 설계된
Class, Interface, Abstract Class
를 사용했는데요. - 역시, 부실한 설계와 잦은 변경때문에 한계점이 분명히 드러났습니다.
- 목표했던, User 추상 클래스를 통해 게임의 모든 통제권을
상속
받아 사용하려 했는데, Board 클래스에서 불가피하게 일부 구현된 기능이 몇가지 있습니다. - 다형성을 이용했던 User 변수는 딜러와 플레이어의 구분이 되질 않아 순회를 통해서 찾아야 했구요.
- 블랙잭 룰의 요구 분석 및 상세 설계가 진행 되지 않아, hit 조건과 stay 조건을 board에서 검사하는 불상사가 일어났습니다.
gist:ppzxc/5fc711e55335a855531a77249a0df189
실행
- 아직 bust시 게임 종료와 상세 규칙, 딜러 규칙, 플레이어 규칙 등 조건이 분기 되진 않았지만, 게임의 뼈대는 제대로 동작하고 있는걸 확인 할 수 있습니다.
- 모든 소스 코드는 github.com/jungha-cho/blackjack에서 확인 할 수 있습니다.
끝으로
- 한동안 BlackJack 게임은 더이상 리팩토링하지 않으려고 합니다.
- 전편에도 말씀드렸듯 분명한 요구 분석과 명세서가 작성되지 않은 상태에서 게임을 구현하다보니, 우당탕탕 수정에 수정만 거듭되고, 부랑자 같은 코드가 탄생하는걸 직접 겪으니, 한가지 책이 떠올라서 책을 읽고 제가 개발하려하는 프로그램에 방향성을 잡는법을 익히고 다시 접근해야 될 것 같습니다.
- 책은 조엘 온 소프트웨어 입니다. 회사와 팀, 개발 프로세스 등 방대한 양을 다루고 있지만, 내부에 명세서와 관련된 내용이 꽤 있었던 걸로 기억이 나서 다시 읽어보려구요.
Reference
- []