[우테코 5기] 블랙잭 구현 미션 회고

지토랑 진행한 세 번째 페어 프로그래밍이다. 사실 끝난 지 한참 됐지만... 뒤늦게 회고를 작성해보고자 한다.
블랙잭부터 미션의 난이도가 확실히 까다로워졌다는 생각이 들었다... ㅎㅎ 그래도 배운 게 많아서 좋다.

 

✔️ 작성한 코드

GitHub - Cl8D/java-blackjack: 블랙잭 미션 저장소

 

✔️ 1차 PR

[1단계 - 블랙잭 게임 실행] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #452 · woowacourse/java-b

 

✔️ 2차 PR

[2단계 - 블랙잭(베팅)] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #538 · woowacourse/java-blackja

 

✔️ 기능 요구사항

블랙잭 게임을 변형한 프로그램을 구현한다. 블랙잭 게임은 딜러와 플레이어 중 카드의 합이 21 또는 21에 가장 가까운 숫자를 가지는 쪽이 이기는 게임이다. 플레이어는 게임을 시작할 때 배팅 금액을 정해야 한다.
 
- 카드의 숫자 계산은 카드 숫자를 기본으로 하며, 예외로 Ace는 1 또는 11로 계산할 수 있으며, King, Queen, Jack은 각각 10으로 계산한다.
- 게임을 시작하면 플레이어는 두 장의 카드를 지급 받으며, 두 장의 카드 숫자를 합쳐 21을 초과하지 않으면서 21에 가깝게 만들면 이긴다. 21을 넘지 않을 경우 원한다면 얼마든지 카드를 계속 뽑을 수 있다. 단, 카드를 추가로 뽑아 21을 초과할 경우 배팅 금액을 모두 잃게 된다.
- 처음 두 장의 카드 합이 21일 경우 블랙잭이 되면 베팅 금액의 1.5 배를 딜러에게 받는다. 딜러와 플레이어가 모두 동시에 블랙잭인 경우 플레이어는 베팅한 금액을 돌려받는다.
- 딜러는 처음에 받은 2장의 합계가 16이하이면 반드시 1장의 카드를 추가로 받아야 하고, 17점 이상이면 추가로 받을 수 없다. 딜러가 21을 초과하면 그 시점까지 남아 있던 플레이어들은 가지고 있는 패에 상관 없이 승리해 베팅 금액을 받는다.
 

---

마찬가지로 PR 내용 중에서 인상 깊었던 것들에 대해서 적어보고자 한다 🫠
 

💬 stream을 사용하기 vs for문으로 분리하기

당시에 모던 자바 스터디에서 꽤나 감명을 받았던 나는, 블랙잭에서 사용하는 카드 객체를 생성하기 위해 flatMap을 사용했었다.

private static List<Card> makeCards(final List<CardPattern> cardPatterns, final List<CardNumber> cardNumbers) {
        return cardPatterns.stream()
        .flatMap(pattern -> cardNumbers.stream()
        .map(number -> Card.create(pattern, number)))
        .collect(Collectors.toList());
}

코드를 작성한 이후에는 꽤나 깔끔한 코드라고 생각했었지만, 리뷰어님은 오히려 이것보다 for문을 활용하는 게 가독성 측면에서 더 좋을 것 같다는 리뷰를 주셨다.
 
그래서 2중 for문을 사용한 방법 2가지를 고려해보았다.

private static List<Card> makeCards(final List<CardPattern> cardPatterns, final List<CardNumber> cardNumbers) {
    List<Card> cards = new ArrayList<>();
    for (CardPattern cardPattern : cardPatterns) {
        makeCard(cardNumbers, cards, cardPattern);
    }
    return cards;
}

private static void makeCard(final List<CardNumber> cardNumbers, final List<Card> cards, final CardPattern cardPattern) {
    for (CardNumber cardNumber : cardNumbers) {
        cards.add(Card.create(cardPattern, cardNumber));
    }
}

메서드 분리를 진행하다 보니 (depth 제한) 불필요하게 필드로 넘겨주는 값이 많아진다는 생각이 들었다.
다만 이전보다 카드 패턴별로 - 카드 숫자별로 조합하여 카드를 생성한다는 것은 잘 보이는 것 같기는 하다 🤔
그래서, 위의 방법에서 필드를 줄이기 위해 다음과 같은 코드를 고려해보았다.

private static List<Card> makeCards(final List<CardPattern> cardPatterns, final List<CardNumber> cardNumbers) {
    List<Card> cards = new ArrayList<>();
    for (CardPattern cardPattern : cardPatterns) {
        List<Card> cardsByPattern = makeCard(cardNumbers, cardPattern);
        cards.addAll(cardsByPattern);
    }
    return cards;
}

private static List<Card> makeCard(final List<CardNumber> cardNumbers, final CardPattern cardPattern) {
    List<Card> cardsByPattern = new ArrayList<>();
    for (CardNumber cardNumber : cardNumbers) {
        cardsByPattern.add(Card.create(cardPattern, cardNumber));
    }
    return cardsByPattern;
}

이전 방법보다는 이게 더 나은 것 같다. makeCard이기 때문에 반환형이 List<Card>인 게 더 명확하기도 하고...
 
다만, 나는 고민까지만 하고 실제로 코드를 변경하지는 않았다.
stream은 성능 측면에서 고려해야 하는 사항은 맞지만, 현재는 Pattern과 Number의 개수가 변하지 않을 도메인이기도 하고, 
오히려 stream을 사용했을 때 불필요한 메서드 분리 없이 Card.create(pattern, number);를 통해 카드를 생성하는 조건이 더 잘 보인다고 판단되었기 때문이다. 이거는 개인의 성향 차이이기 때문에 아마 코드 스타일에 따라 다르지 않을까 싶다!
이번 미션에서 한 번쯤 고민해본 부분이라 블로그 글로 작성한다 :D
 

---

💬 초기화와 선언이 분리되면? (do-while)

지금까지 진행했던 우테코 미션에서 공통적인 부분이 있는데, 바로 사용자한테 입력을 받는다는 것이다.
사용자에게 처음 한 번은 무조건 입력받고, 그뒤로 입력받았을 때 수행하는 것에 따라서 실행이 종료되거나, 계속되거나 하는 경우가 많았다.
나는 이런 요구사항을 보자마자 do-while문이 떠올랐기 때문에, 이번 미션에서도 다음과 같이 작성하였다.

DrawCardCommand drawCardCommand;
do {
    drawCardCommand = getDrawCardCommand(player);
    checkDraw(gameManager, playerIndex, drawCardCommand);
    outputView.printPlayerCard(player.getName(), player.getCard());
} while (canDrawCard(player, drawCardCommand));

하지만, 리뷰어님은 다음과 같은 피드백을 주셨다.

초기화와 선언이 따로 떨어져있는 방식은 좋지않습니다-!
어떻게 생각하시나요-?!

사실 지금까지 do-while을 사용하면서 이런 생각을 한 번도 해본 적이 없었어서 놀랐다.
그래서 다음과 같이 생각을 정리했다.
 
1. 선언부 이전에 어떠한 로직이 들어온다면, NPE가 발생할 수 있다.
2. 그렇기 때문에 비즈니스 로직에 항상 null 체크를 진행하는 부분이 필요해진다.
3. 가독성 측면에서도 좋지 않다. 변수의 추적이 어려워질 수 있다.
 
생각해보면 NPE라는 건 피해야 하는 주적 중 하나이다. NPE가 발생할 수 있는 코드를 작성했다니... 🥲
지금은 혼자 작성한 코드지만, 현업에서 복잡한 레거시 코드를 작성하다 보면 분명 이러한 코드는 버그를 야기할 수 있을 것 같다는 생각이 들었다. 그래서 리팩터링에서는 재귀를 활용하도록 코드를 변경하였다.

private void handleDrawCard(final GameManager gameManager,
                            final Participant player) {
    DrawCardCommand drawCardCommand = getDrawCardCommand(player);
    checkDraw(gameManager, player, drawCardCommand);
    outputView.printParticipantCard(player.getName(), player.getCard());
    if (cannotDrawCard(player, drawCardCommand)) {
        return;
    }
    handleDrawCard(gameManager, player);
}

if문의 조건도 반전을 시켰다. (!을 통해 부정형 조건을 주지 않고, 부정형에 대한 조건을 담은 메서드로 분리)
이렇게 만드니까 카드를 더 이상 draw 하지 않을 때 해당 메서드를 빠져나갈 수 있다는 조건이 명확해져서 더 보기 좋은 것 같다.
 

---

💬 Enum에 대한 캐싱 진행하기

public final class Card {
    private static final int CARD_SIZE = 52;
    private static final Map<String, Card> CACHE = new ConcurrentHashMap<>(CARD_SIZE);

    private final CardPattern pattern;
    private final CardNumber number;

    private Card(final CardPattern pattern, final CardNumber number) {
        this.pattern = pattern;
        this.number = number;
    }

    public static Card create(final CardPattern pattern, final CardNumber number) {
        return CACHE.computeIfAbsent(toKey(pattern, number), mapping -> new Card(pattern, number));
    }

    private static String toKey(final CardPattern pattern, final CardNumber number) {
        return pattern.name() + number.name();
    }
}

페어였던 지토가 알려주었던 방법이다. 카드는 한 번 생성되면 계속해서 재사용되기 때문에 캐싱을 해두는 것이었다.
key 값으로 패턴과 번호에 대한 name 값을 사용하고, map의 computeIfAbsent를 활용하여 캐싱을 하는 방법이 인상 깊었다 👍

public enum PatternMessage {
    HEART(CardPattern.HEART, "하트"),
    DIAMOND(CardPattern.DIAMOND, "다이아몬드"),
    CLOVER(CardPattern.CLOVER, "클로버"),
    SPADE(CardPattern.SPADE, "스페이드");

    private static final Map<CardPattern, String> CACHE = Stream.of(PatternMessage.values())
            .collect(Collectors.toUnmodifiableMap(patternMessage -> patternMessage.pattern,
    patternMessage -> patternMessage.message));

    private final CardPattern pattern;
    private final String message;

    PatternMessage(final CardPattern pattern, final String message) {
        this.pattern = pattern;
        this.message = message;
    }

    public static String findMessage(CardPattern pattern) {
        return CACHE.get(pattern);
    }
}

또한, 뷰에 출력될 메시지를 관리할 때도 다음과 같이 캐싱을 진행하였다.
 

---

💬 BiConsumer 활용하기

이것도 모던 자바의 영향을 정말 많이 받고 작성한 코드이다. 
베팅에 대한 책임을 분리하기 위해, 다음과 같은 별도의 BettingManager라는 객체를 생성하였다.

public enum BettingManager {
    FIRST_TURN_DEALER_WIN(BettingManager::distributeDealerFirstTurnWin),
    FIRST_TURN_PLAYER_WIN(BettingManager::distributePlayerFirstTurnWin),
    IS_DEALER_WIN(BettingManager::distributeDealerWin),
    IS_PLAYER_WIN(BettingManager::distributePlayerWin);

    private final BiConsumer<Dealer, Player> referee;

    BettingManager(final BiConsumer<Dealer, Player> referee) {
        this.referee = referee;
    }

    private static void distributeDealerFirstTurnWin(final Dealer dealer, final Player player) {
        if (dealer.isBlackJack() && !player.isBlackJack()) {
            dealer.earnMoney(ParticipantMoney.create(player.getMoney()));
            player.loseMoney();
        }
    }

    private static void distributePlayerFirstTurnWin(final Dealer dealer, final Player player) {
        if (!dealer.isBlackJack() && player.isBlackJack()) {
            player.earnBonusMoney();
            dealer.loseMoney(ParticipantMoney.create(player.getMoney()));
        }
    }

    private static void distributeDealerWin(final Dealer dealer, final Player player) {
        if (dealer.isBlackJack()
                || dealer.isBust() && player.isBust()
                || !dealer.isBust() && dealer.calculateScore() > player.calculateScore()) {
            dealer.earnMoney(ParticipantMoney.create(player.getMoney()));
            player.loseMoney();
        }
    }

    private static void distributePlayerWin(final Dealer dealer, final Player player) {
        if (player.isBlackJack()
                || dealer.calculateScore() < player.calculateScore()) {
            player.earnMoney();
            dealer.loseMoney(ParticipantMoney.create(player.getMoney()));
        }
    }

    public BiConsumer<Dealer, Player> getReferee() {
        return referee;
    }
}

private static 메서드를 활용하여 외부에서 잘못 활용되는 것을 막을 수 있으며, 딜러와 플레이어의 승패 판단에 대한 복잡한 로직을 메서드별로 분리할 수 있어 가독성 측면에서도 마음에 드는 코드이다 🫠 
(사실 처음 2개 조건 - 첫 턴에 딜러와 플레이어의 승패를 판단하는 로직은 설계를 변경하면 아마 없애도 되는 부분이었을 테지만... ㅎ 나는 처음에 카드 2장을 분배했을 때 딜러가 애초부터 블랙잭이거나 플레이어가 블랙잭이면 게임을 바로 종료하기 위해서 이런 메서드를 두었다.)
 
아무튼, 외부에서는 다음과 같이 접근하여 승패를 판단 및 돈을 분배해주면 된다.

public void judgeFirstBettingResult() {
    final Dealer dealer = participants.getDealer();
    participants.getPlayers()
            .forEach(player -> {
                FIRST_TURN_DEALER_WIN.getReferee().accept(dealer, player);
                FIRST_TURN_PLAYER_WIN.getReferee().accept(dealer, player);
            });
}

 

---

💬 명시적 형변환 없애기

💡 기존 설계

사실 이번 미션에서 가장 애를 먹었던 부분 중에 하나이다.
나는 이번 미션을 구현하면서 딜러와 플레이어를 나눠서, 하나의 참가자로 관리하였다. (딜러와 플레이어는 Participant를 상속받음)
참가자 리스트에 딜러를 가장 처음에 넣어주었기 때문에, 가장 첫 번째 인덱스에 존재하는 참가자는 딜러라는 의미로 사용하였다.

// Participants.java
public class Participants {
    private static final int DEALER_ORDER = 0;
    private static final int PARTICIPANT_START_ORDER = 1;

    public Participant getDealer() {
        return participants.get(DEALER_ORDER);
    }

    public List<Participant> getPlayer() {
        return participants.subList(PARTICIPANT_START_ORDER, participants.size());
    }
}

이렇게 하면 컨트롤러에서는 'Participant'라는 정보만 가지고 실제로 필요할 때 딜러를 꺼내서 사용할 수 있었지만,
꺼내서 사용하는 부분에서 (Dealer)를 통해 명시적으로 형변환을 하는 부분이 들어가야 한다는 단점이 존재했다.
 
또한, 인덱스로 관리한다는 것은 개발자가 참가자들에 대한 객체를 접근할 때 순서에 대한 이해를 가지고 있어야 하기 때문에 잘못 사용될 위험도 높았다. (당시에 인덱스로 관리하던 이유는, 참가자들에 대한 카드 정보를 반환할 때 요구사항에서 딜러 - 플레이어 순으로 출력되었기 때문에 이러한 순서를 맞추기 위함이었다.)

private void printDealerCard(final Participants participants) {
	final Dealer dealer = (Dealer) participants.getDealer();
}

대략 위와 같은 코드였다. 내부적으로 반환을 Participant 타입으로 하기 때문에, 자식 타입인 Dealer로 캐스팅을 했어야 하는 것이다. (혹은 필요하다면 Player로 캐스팅)
 
 

💡 instanceof 도입 

처음에 리뷰어님이 명시적 형변환을 사용하지 않는 구조로 변경해달라고 말씀해 주셔서, 형변환을 사용하게 되면 잘못된 타입 캐스팅이 일어날 수 있을 것 같아서 하지 말라는 의미로 받아들였다. 그래서, 타입 체크를 하고 캐스팅을 하면 안전하지 않을까? 라는 생각으로 다음과 같이 instanceof를 사용하는 코드로 변경하였다 🥲 (생각해보면 바보 같은... 방법이다)

if (participant instanceof Dealer) {
    return (Dealer) participant;
}

하지만, instanceof는 여러 방면으로 SOLID를 무시하는 코드이다.
 

1. 캡슐화가 깨진다.

: 클라이언트가 Participant의 구체 타입인 Dealer에 대해서도 알게 된다. 
 

2. OCP 위반

: 캡슐화가 깨지면 OCP도 자연스럽게 위반하게 된다. 만약 요구사항이 변화하여 Dealer 자체가 필요없어진다면, 클라이언트 코드에서 선언되었던 Dealer에 대한 코드도 모두 제거해야 한다. 확장에 매우 취약해지는 구조를 가지게 되는 것이다. 확장에는 열려 있고, 변경에는 닫혀 있어야 하는 OCP를 위반하게 되는 것이다.
 
+ 이외에도 SRP 위반, 성능 문제 등 다양한 문제들을 야기한다... 🫠...
 
 

💡 Participant에서 각 타입 반환하기

그래서, 아예 Participant 자체에서 Dealer를 명시적으로 반환하도록 만들었다. 사실 이렇게 되면, 애초에 클라이언트 코드에서 Participant만 바라보도록 하려고 했었던 설계가 깨진다. (하지만... 당시에는 명시적 형변환을 없애려는 노력을 더 진행했다 ㅠ)

// Participant.java
public static Dealer createDealer() {
    return Dealer.create();
}

우선, 인덱스로 관리하던 것 자체를 제거하고 Dealer는 Participant를 상속받기 때문에 부모 클래스인 Participant에서 자식 클래스인 Dealer를 명시적으로 반환하도록 만들었다. 다만, 작성하고 나서도 이런 코드가 맞을까...? 라는 생각이 들었다.

Participant와 Dealer 사이의 결합도가 증가하게 되며, 둘이 상호 참조를 하기 때문에 위험도가 높다는 것이었다.
스프링만 생각해봐도 의존 관계의 양방향성이 정말 위험한데, 이를 고려하지 않은 나쁜 코드였다...🥲
 
 

💡 Stream 활용하기

그래서, 또 다시 고민을 시작했다... 이걸 어떻게 해결해야 할까?
이쯤에 1단계가 merge가 되고, 2단계 미션이 시작했기 때문에 새로운 요구사항이 추가되었었다.
바로, 참가별 베팅 금액을 관리했어야 하는 것이다. 그래서 나는 ParticipantInfo라는 새로운 객체를 생성하여 관리하고자 했다.
(참가자가 Money 정보를 가지고 있는 게 가장 깔끔하겠지만, 인스턴스 필드 변수가 3개 이상이 되지 않도록 하기 위해 이렇게 분리하였다...)

public class ParticipantInfo {
    private final Map<Participant, ParticipantMoney> participantInfo;

    private ParticipantInfo(final Map<Participant, ParticipantMoney> participantInfo) {
        this.participantInfo = participantInfo;
    }

    public static ParticipantInfo create(final Map<Participant, ParticipantMoney> participantAsset) {
        return new ParticipantInfo(participantAsset);
    }

    public Participant findDealerInfo() {
        return participantInfo.keySet()
                .stream()
                .filter(participant -> DEALER_NAME.isSame(participant.getName()))
                .findFirst()
                .orElseThrow(() -> {
            throw new IllegalStateException("딜러 정보가 존재하지 않습니다.");
        });
    }

    public List<Participant> findPlayerInfo() {
        return participantInfo.keySet()
                .stream()
                .filter(Predicate.not(participant -> DEALER_NAME.isSame(participant.getName())))
                .collect(Collectors.toUnmodifiableList());
    }
}

당시 작성하던 코드다. 물론 이것도 좋은 코드는 아니다... ㅎ
참가자의 정보를 관리한다는 의미로 ParticipantInfo라는 네이밍을 사용하였고, 각 정보에서 참가자와 딜러에 대한 정보를 가져온다는 의미로 위와 같은 메서드를 생성하였다. 또한, 인덱스로 관리하지 않고 딜러의 고유 이름을 통해 참여자의 정보를 찾도록 만들었다. (물론, 플레이어의 이름에는 '딜러'가 들어오지 못하도록 하였다!)
 
그래서 컨트롤러에서는 Dealer, Player에 대한 정보를 알 필요 없이 Participant를 통해 접근할 수 있게 되었다.

// GameController.java
private Map<Participant, ParticipantMoney> getParticipantInfo() {
    final Map<Participant, ParticipantMoney> participantInfo = new LinkedHashMap<>();
    participantInfo.put(Participant.createDealer(), ParticipantMoney.zero());
    for (Participant player : makePlayers()) {
        participantInfo.put(player, getPlayerBettingMoneys(player));
    }
    return participantInfo;
}

그리고 딜러에 대한 정보가 필요할 때면 다음과 같이 찾아와서 사용하였다.

public void calculateProfit(final Map<Participant, ParticipantMoney> initMoneyInfo) {
    final Participant dealer = participantInfo.findDealerInfo();
    if (dealer.isBust()) {
        resetPlayerBettingMoney(dealer, initMoneyInfo);
        return;
    }
    calculatePlayerMoney(dealer, initMoneyInfo);
}

추가로, Participant에 대해서 관리하고 있기 때문에 딜러만 사용할 수 있는 메서드를 Player가 사용할 수도 있다.
이에 대해 방지하기 위해서 다음과 같이 Player에는 Exception을 터트리도록 하였다.

// Dealer.java
public final class Dealer extends Participant {
    ...

    @Override
    public Card getFirstCard() {
        return hand.getFirstCard();
    }

    @Override
    public boolean canGiveCard() {
        return STANDARD_GIVEN_SCORE.isGreaterThanAndEqual(hand.calculateScore());
    }
}

// Player.java
public final class Player extends Participant {
    ...

    @Override
    public Card getFirstCard() {
        throw new UnsupportedOperationException("딜러만 카드 한 장을 보여줄 수 있습니다.");
    }

    @Override
    public boolean canGiveCard() {
        throw new UnsupportedOperationException("딜러만 16점 이하일 때 카드를 추가로 받을 수 있습니다.");
    }
}

다만, 이런 식으로 Exception을 터트리는 건 상당히 찝찝하다. 당시에는 이런 생각을 가지고 작성하였다.

하지만, 리뷰어님은 다음과 같은 피드백을 남겨주셨다.

UnsupportedOperationException 를 사용하는 상황과는 상황이 조금 다를수도 있겠다는 생각이드네요!
자바에서 제공하는 기본 API의 경우 과거 버전의 호환성이 최우선으로 판단되는 경우이고 (버전 업에 따라 이전 버전에 문제가 전혀 없어야하는 게 보장되어야함) 지금의 경우에는 학습이기도 하고 구조를 계속 변경하며 더 좋은 방법을 찾을 수도 있겠다는 생각이 들어서요-!

사실 자바 API와 비교하는 건 맞지 않은 예시이긴 했다. 내가 설계한 것은 호환성 때문에 이렇게 작성했다기보다는, 어떻게든 Participant에 Dealer를 끼워맞추기 위해서 작성한 코드와 다름없기 때문이다.
 
또한, XXXInfo라는 네이밍은 객체지향적 관점에서 생각해보았을 때 불분명한 네이밍이다.
ParticipantInfo 대신 Participant라고만 하더라도 해당 객체가 참가자에 대한 정보를 나타낸다는 것 정도는 명확하게 예상할 수 있으며, Info는 오히려 어떠한 정보가 포함되어 있는지 예상하기 어렵게 만들기 때문이다.
 
 

💡 상속 대신 조합 사용하기

결국, 최종적으로 상속 구조를 포기하는 것으로 마음을 돌렸다.
컨트롤러에서 Dealer, Player를 모르게 하는 것은 실패하였지만, 이렇게 하는 것이 그나마 깔끔한 구조라고 판단하였다.

public interface Playable {
    void addCard(final Card... cards);

    boolean canDrawCard();

    boolean isBlackJack();

    boolean isBust();

    int calculateScore();

    void resetMoney(final ParticipantMoney initMoney);
}

우선, 플레이어와 딜러가 공통적으로 할 수 있는 행위에 대해서는 인터페이스를 사용하였다.

public final class Dealer implements Playable {
    private static final ParticipantName DEALER_NAME = ParticipantName.create("딜러");

    private final Participant participant;
    private ParticipantMoney participantMoney;

    private Dealer(final Participant participant, final ParticipantMoney money) {
        this.participant = participant;
        this.participantMoney = money;
    }

    static Dealer create() {
        return new Dealer(Participant.create(DEALER_NAME.getName(), ParticipantCard.create()), ParticipantMoney.zero());
    }

    public Card getFirstCard() {
        return participant.getHand().get(FIRST_CARD_INDEX);
    }
	
    ...

    @Override
    public void addCard(final Card... cards) {
        participant.addCard(cards);
    }

   	...
}

Dealer는 Playable 인터페이스를 구현하고, 필드로 Participant를 가지고 있어서 공통적으로 할 수 있는 행위에 대해서는 Participant에게 메서드를 위임하여 수행할 수 있도록 만들었다. 또한, Map으로 참가자의 베팅 금액 정보를 관리하는 것이 아닌, 인스턴스 필드로 ParticipantMoney를 가지고 있도록 만들어서 베팅할 때마다 금액 정보가 변경되도록 만들었다.
(한 가지 아쉬운 건, Money에 대해 불변성을 지키지 못했다는 것이다 🥲 이 부분은 배팅 금액을 계산하는 로직을 뜯어 고쳐야 해결되는 부분이기 때문에 여기까지는 수정을 하지 못했다.)

public final class Player implements Playable {
    private final Participant participant;
    private ParticipantMoney participantMoney;

    private Player(final Participant participant) {
        this.participant = participant;
    }

    public static Player create(final String name) {
        validatePlayerName(name);
        return new Player(Participant.create(name, ParticipantCard.create()));
    }

  	 ...
    @Override
    public void addCard(final Card... cards) {
        participant.addCard(cards);
    }
}

기존에는 Player가 하면 안 되는 행위에 대해서 UnsupportedOperationException을 던졌어야 했지만, 조합을 사용하면서 굳이 해당 메서드를 생성하지 않으면 되기 때문에 (애초에 재정의할 필요가 없어짐) 코드상으로 더 깔끔해졌다는 점이다.
다만 개인적인 관점이지만, bypass하는 메서드가 많다 보니까 TDD를 진행할 때 상당히 힘들었다 😅 (지옥의 테스트...)
 
그리고, 참가자와 딜러에 대한 정보는 별도의 객체를 생성해서 받아오도록 만들었다.

public class Participants {
    private final Dealer dealer;
    private final Players players;

    private Participants(final Dealer dealer, final Players players) {
        this.dealer = dealer;
        this.players = players;
    }

    public static Participants create(final Players players) {
        return new Participants(Dealer.create(), players);
    }

    public Dealer getDealer() {
        return dealer;
    }

    public List<Player> getPlayers() {
        return players.getPlayers();
    }
}

필드로 Dealer와 Players를 가지고 있는 Participants라는 객체를 생성하여서 각 객체를 가져오도록 만들었다.
객체의 의존성은 Participants -> dealer, players이기 때문에 단방향성이고, 필드로 관리하기 때문에 불필요한 결합을 가지고 있는 것도 아니어서 설계 측면에서는 그나마 이 방향이 가장 나은 게 아니었을까 싶다.

public final class GameManager {
    private final Deck deck;
    private final Participants participants;

    private GameManager(final Deck deck, final Participants participants) {
        this.deck = deck;
        this.participants = participants;
    }
}

그래서, 게임에 대한 전반적인 관리를 진행하는 GameManager가 Deck과 참가자 전체 정보인 Participants를 가지고 있도록 만들어서 필요할 때 딜러와 플레이어를 꺼내쓸 수 있도록 만들었다.
 

private void printCardResult(final GameManager gameManager) {
    final Participants participants = gameManager.getParticipants();
    final Dealer dealer = participants.getDealer();
    outputView.printCardResult(dealer.getName(), dealer.getHand(), dealer.calculateScore());
    participants.getPlayers().forEach(player ->
    outputView.printCardResult(player.getName(), player.getHand(), player.calculateScore()));
}

다만, 컨트롤러에서는 다음과 같이 Dealer, Players에 대한 의존이 생길 수밖에 없어서 이 부분은 아쉽다 🥲
하지만 첫 코드와 비교해보았을 때 형변환도 없애고, 각 객체가 해야 할 행위에 대해 잘 정의한 것 같아서 이 구조가 그나마 가장... 낫지 않았을까 싶다. 
 
만약 지금 다시 설계를 진행한다면, 처음부터 조합을 사용하고 베팅 금액 역시 Dealer는 가지고 있지 않고 그냥 뷰에서 결과를 계산할 때 플레이어의 총 금액에서 계산하면서 만들지 않았을까... 생각이 든다. + 불변성 보장 (상태 패턴도 적용하지 않았을까?)
 

---

사실 블랙잭 미션은 여러모로 아쉬움이 많이 남았던 미션이다. 구조 변경을 계속 진행한 건 재밌었지만, 그만큼 시간이 많이 촉박하기도 했고, 체스 미션이 다가오면서 심적으로 많이 힘들었기 때문이다... ㅠ 그래도 이렇게 블로그 글로 작성하다 보니까 정말 많은 대공사가 들어갔었다는 것을 다시 한 번 되새길 수 있었다.
계속 하다 보면 나중에는 더 발전할 수 있지 않을까... 파이팅!! 💪