블랙잭 미션 회고

블랙잭 미션에서 어려웠던 부분을 대표적으로 몇 가지 추려보자면 Ace 카드의 구현, 입력과 객체간의 관계, 객체의 역할 분리이다.

- 입력까지 객체의 역할인가?

이번 미션에서 가장 많은 고민을 한건 입력과 객체간의 관계에서 어디까지를 객체의 역할로 보느냐이다. 블랙잭 미션은 플레이어에게 계속해서 카드를 받을건지 물어보고, 카드를 받는다고 결정하면 해당 카드를 주고, 점수가 Bust 되는지를 확인하고, 그렇지 않으면 플레이어가 가진 카드들을 출력하면서 다시 카드를 받을건지 물어보는 로직이 반복된다.

이런 흐름을 좀 생각해보면 계속해서 플레이어의 점수를 확인하여 Bust 여부를 검사하고, 카드를 받을건지 물어보고, 답변 여부에 따라 Yes면 카드를 주고, No면 반복문을 빠져나온다. 즉, 플레이어의 입력 여부에 따라 카드를 더 주고 받는 로직이 반복되는 것! 추가로 출력까지 한다.

그래서 Input과 객체의 로직, Output의 분리가 상당히 어려웠다.

for (Player player : players.getPlayers()) {  
    while (!player.isFinished()) {  
        if (!InputView.readDrawOneMore(player.getNickname())) {  
            player.stand();  
            break;  
        }        
        player.hit(deck.draw());  
        OutputView.printPlayerCards(player);  
    }
}

최종적으로 나는 이런 방식으로 해결했지만, 함수형 인터페이스로 해결하는 방안도 있었다.

public class BlackjackGame {

	...

	public void playerTurn() {
		players.processAllPlayerTurn(
			InputView::readDrawOneMore,
			OutputView::printPlayerCards
		);

		...
	}

	...
}

public class Players {

	...

	public void processAllPlayerTurn(
		Deck deck,
		Function<String, boolean> readDrawOneMore,
		Consumer<Player> printPlayerCards
	) {
		for (Player player : players) {
			player.processTurn(deck, readDrawOneMore, printPlayerCards);
		}
	}
}

public class Player {

	public void processTurn(
		Deck deck,
		Function<String, boolean> readDrawOneMore,
		Consumer<Player> printPlayerCards
	) {
		while (!isFinished()) {
			if (!readDrawOneMore(nickname)) {  
				stand();
				break;
			}        
			hit(deck.draw());  
			printPlayerCards(player); 
		}
	}
}

해당 방식은 흐름을 제어하는 코드가 깔끔해져 보기 좋아진다는 것이고, 플레이어가 본인에게 묻고 카드를 추가하는 것이 플레이어 자체의 책임으로 정해진다는 장점이 있다. 다만 내 생각에 이 방식의 가장 큰 단점은 함수형 인터페이스를 사용했다는 점이다. 호출 시점과 사용 시점의 차이는 메서드의 파라미터로 넣어주어 문제되지 않는다해도 어떤 함수든 형식만 맞으면 들어갈 수 있다는 것이 제일 큰 단점같다.

예시로 `readDrawOneMore`이라고는 하지만, 파라미터 이름을 잘못 이해해서 한 장 더 받을 것인지가 아니라 받았는지에 대해 물어보는 형식의 메서드를 보냈다면.. y, n의 의미가 정반대가 되어 결과가 달라진다.

그래서 나는 이런 방식을 사용하진 않았고, 외부에서 처리하도록 해서 흐름을 좀 더 쉽게 파악할 수 있게 했다.

함수형 인터페이스 사용

장점
- 객체에 본인의 책임을 모두 넘겨 응집도가 높아짐
- 객체에 메시지를 보내도록 만들 수 있음

단점
- 함수를 파라미터로 전달하는 행위의 위험성
- 책임의 소재가 불분명해지고 가독성이 떨어질 수 있음

---

- 상태 패턴은 만능이 아니다.

이번에 블랙잭 피드백으로 상태 객체를 정의하고 사용하는 방법을 제안했다. 블랙잭 게임에서의 현재 상태를 객체로 관리한다는 생각은 못해봤기도 하고 신기한 방법이라 생각해서 곧장 내 미션에 적용했었다.

근데 왜 사용해야 할지 고민하지 않고 도입했기 때문일까. 상태를 객체로 만들긴 했으나 어디까지 책임을 가져야하고 어떻게 현재 코드에서 더 개선시킬 수 있는지 벽이 생긴 것처럼 막혀버렸었다. 그래서 상태 객체가 블랙잭에서 가져야할 책임을 좀 고민해봤고 나름의 결론을 내렸다.

 

상태 객체는 플레이어 본인이 본인의 행동을 결정하기 위해 사용하는 객체이지 외부와 소통을 위한 객체는 아니다.

해당 결론이 나온 이유는 외부에서 게임의 승패를 계산하는데, 이런 상태 객체를 이용하려고 하니 오히려 복잡해지고 어려웠다. 그래서 결국 상태가 무엇인지 판단하는 isBust, isBlackjack 같은 메서드를 선언할 수 밖에 없었는데 저렇게 결론을 내리고 나니 오히려 적당히 역할을 나눈 것 같아서 좋았다.

---

- Ace 카드 계산

Ace 카드는 블랙잭에서 특별하다. 1 또는 11의 값을 가질 수 있고, 이 값은 최종 점수에 따라 결정되어야 한다. 즉, 21이 넘지 않은 선에서 가장 21과 가까운 수로 만드는 카드가 되어야 한다.

이처럼 점수를 결정하는 것이 블랙잭 게임 룰에 의한 책임일까, Ace 카드 자체의 책임일까? 두 가지 모두 장단점이 있다.

1. 블랙잭 게임 룰의 책임
Ace 카드가 특별하지만, 이는 블랙잭 게임에서만 유효하다는 생각으로 결정되는 책임이다. 이러면 Ace 카드가 있을 경우에 점수에 대한 계산을 플레이어의 패 `hands`, `Cards`, `Player`와 같은 객체가 담당하게 된다.

장점으로는 보통 사람들이 블랙잭 게임을 생각할 때 자신의 패 혹은 자신이 계산한다고 생각하니 생각의 흐름을 쫓아가기 쉬워진다.

2. Ace 카드 자체의 책임
Ace 카드가 직접 본인의 점수를 통해 점수 계산을 해주는 것이다. 객체의 역할을 끝까지 혹은 극단적으로 나눈다면 나올 수 있는 좋은 설계이다. 다만, 블랙잭에서만 Ace 카드 1, 11 두 점수를 의미를 가지기 때문에 굳이 나눌 필요가 있나? 하는 생각도 있다. 오히려 클래스가 나눠지면서 점점 복잡해질 수 있기 때문이다.