객체 지향 설계 연습하기 - 블랙잭 (13)

github source code

들어가며

업무에 Java를 사용하고 있지만, 깊은 이해도가 부족하다는걸 절감.
단순 객체 생성 및 비즈니스 로직 구현에만 매달리고 있음. 회의감이 듦.
신규 개발 뿐만 아니라 유지 보수 및 리팩토링시 객체 지향의 묘미를 살려보고자 함
객체 지향적 시야와 사고는 연습뿐이라는 것을 여러 커뮤니티에서 수집
객체 지향 설계 연습을 통해 객체 지향적 시야와 이해력을 높이고지 함

TDD

어느 정도 TDD의 순간이 보이고, 책과 각종 유튜브 강의로 눈에 익자 TDD를 시도하며 코드 작성을 시도했습니다.
완벽한 설계는 없다는 원칙을 고수하고 이전에 남아 있던, UML을 바탕으로 큰 그림을 먼저 그리려 했습니다.

인수 테스트와 유닛 테스트의 조합으로 회귀 테스트를 더 강력하게

초기 테스트를 작성하다 보면, 아주 많은 작업이 필요한 경우가 있다.
보통은 getting Stuck 이라고 하는 잘못된 케이스 일 수도 있지만, 테스트 작성을 위한 더 세부적인 내용을 작성해야 할 수 있다.
책에서는 인수 테스트를 전체 시스템이 동작하는가?라고 정의하고 있다.

실패하는 인수 테스트를 작성한다.
테스트를 작성한다.
해당 테스트가 동작하게 만들 코드를 작성한다.
코드를 가급적 테스트한 기능의 단순 구현으로 리팩토링 한다.
반복한다.
인수 테스트를 반복한다.

인수 테스트를 이곳에 적용 했습니다.

순환 고리 형태로, 게임을 만들고, 카드 게임의 제일 기본 원칙인 초기화 세팅 테스트 함수
딜러가 카드를 나눠 줘야 하는데, 카드 게임의 기반이 없으므로, canInitialize() 메소드를 인수테스트로 작성.
그 후 canInitialize() 함수가 동작하기 위한 기반인 Card 클래스를 작성함

gist:ppzxc/01b37237cffb30d389a4276ee714cc1b#BlackJackTest.java

카드 클래스의 테스트 코드

기본적인 카드 클래스가 가져야할 속성과 모양이 정상적으로 세팅 되는지 부터 검사
이부분에서 처음에는 지저분하고 가독성이 낮은 코드가 작성되었음.
리팩토링하며, 테스트 코드 뿐만 아니라, 실 메소드 사용에서도 사용될 isEqual() 메소드를 작성하고, 테스트 코드 또한 한눈에 잘 보이게끔 지속적으로 리팩토링함

gist:ppzxc/01b37237cffb30d389a4276ee714cc1b#CardUnitTest.java

Card와 모양, 끗수

모양과 끗수 클래스는 큰 차이점 없습니다.
Card 클래스에는 속성을 하나의 변수로 유지하려 Pair로 변경했습니다. 카드는 한쌍이 있어야 하나의 카드이니까요.
카드 비교가 마땅치 않아, isEqual 메소드를 생성했습니다.
여기서도 라인수 및 가독성을 위해 리팩토링을 많이 진행했지만, 아직 지저분해 보입니다.

gist:ppzxc/01b37237cffb30d389a4276ee714cc1b#Card.java gist:ppzxc/01b37237cffb30d389a4276ee714cc1b#Suit.java gist:ppzxc/01b37237cffb30d389a4276ee714cc1b#Denomination.java

V3 시작의 첫날

TDD를 제대로 준수하며, 작성하고 리팩토링하면서, 제 눈으로 코드가 깔끔해지고 뒤가 든든해지는 코딩 방법을 체득하고 있다고 느꼈습니다.
테스트는 제 코드에 신뢰성을 더해줄 것이며, 리팩토링은 저 포함 유지 보수 인력이 파악하기 편한 코드가 될것이라고 직접 느낀것 같습니다.

철저히 TDD 원칙을 준수 했습니다.

테스트 코드 없이는 기능 코드를 작성하지 않는다.
쉬운 것 부터 작성한다.
리팩토링시 가독성에 주안점을 둔다.

소트웍스 엔솔로지 원칙을 준수하려 노력했습니다.

규칙 1 메소드당 들여쓰기 한 번
규칙 2 else 예약어 금지
규칙 3 원시값과 문자열의 포장
규칙 4 한 줄에 한 점만 사용
규칙 5 축약 금지
규칙 6 모든 엔티티를 작게 유지
규칙 7 2개 이상의 인스턴스 변수를 가진 클래스 사용 금지
규칙 8 일급 콜렉션 사용
규칙 9 게터/세터/속성 사용 금지

객체지향설계 블랙잭(13)