설계

거의 마지막 미션 답계 설계부터 쉽지 않았다

특히 처음에 카드를 구성할 때는 Ace 때문에 여러번 설계를 부수고 만들기를 한 5번 정도 한 것 같다

• enum에 추상 메서드를 쓰는 방법, 일반 클래스를 만드는 방법, 추상 클래스를 활용하는 방법 등등

특히 enum 처럼 기본적으로 싱글톤으로 동작하는 친구의 경우 ACE 하나의 값을 변경하면 나머지 ACE의 값이 변경되는 문제도 보았다

그러나 문제를 잘~ 읽어 보니 ACE를 위해서 특별히 설계해야할 것은 보이지 않았다

[배팅금액] 조립을 하거나 Map을 쓰거나

베팅금액을 설계할 때 이 금액을 두 가지 방면으로 고민을 했었다

1. 하나는 참가자에게 귀속된 인스턴스 멤버로 두거나

2. 다른 하나는 정규화된 DB처럼 Map 자료형으로 ID, 베팅금액 처럼 두거나. (이 경우는 ID 가 별도로 존재하지 않아서 사람 이름, 베팅금액 이 될 것이다

1번의 경우 승패를 나타내는 로직이 굳이 사람에게 있을 필요 없다는 리뷰를 받아서 이 경우 또한 검토를 하지 않았다

따라서 2번의 방식을 사용했는데

이랬을 경우 프로덕션 코드는 둘 째 치고 텍스트 픽스쳐를 설계하기가 힘들다는 단점이 있었다

예를들어 1번의 경우를 사용하면

Player.builder()
    .name("User A")
    .cards(JACK, ACE)
    .bettingMoney(10_000);

등으로 위처럼 설계가 가능하기 때문이다

참고로 2번 처럼 한 경우는 아래 처럼 텍스트 픽스쳐가 안이쁘게 나온다 (…)

Player pobi = createPlayerWithDenominations("pobi", TWO, EIGHT, ACE);

List<BettingMoney> bettingMonies = new ArrayList<>();
bettingMonies.add(new BettingMoney(pobi.getName(), "10000"));

우선 참가자를 만든 후 베팅 금액에 해당하는 컬렉션을 생성하여 이름을 키값으로 하는 배팅금액을 만들어 넣어주어야 한다 ㅠㅠ

상태패턴

2단계에서 상태패턴으로 진행하는 과정이 있었으나..

상태패턴에 대해서는 딱히 적용을 하지 않았었다

아니 못했다..

이날 컨디션이 무척 안좋았었는데 (코로나)

수업을 들으면서 꼬박 졸았던 것 같았다

상태패턴의 장점

각 상태들의 어떤 상태들로 변화할 지 알기 때문에 클라이언트 코드는 상태들의 변화에 대해서 컨트롤할 필요가 없다는 것이다

• 클라이언트 입장에서 코드가 간결해짐

• 중복된 형태의 if-else 문이 없어진다

• 클래스별 SRP 원칙이 잘 지켜지고, 이에 따라 단위테스트 코드 작성도 좋아진다

상태패턴의 단점

• 코드를 파악할 때 상태들 하나 하나를 모두 열어봐야 어떤 흐름에서 상태가 변화하는지를 파악할 수 있다

• 만일 가장 최상위 추상타입(인터페이스나 추상 클래스)에서 임의의 시그니처를 추가한다면 변경 여파가 수직적으로 커진다

• 만일 구현할 필요가 없는 자식 클래스에서 시그니처를 물려받는다면 UnsuportedOperationException 예외를 발생시켜야 한다

  • 즉 어떤 상태에서는 어떤 기능을 수행할 수 없는 것 !