[Ch 13] 중요한 것은 클라이언트의 관점

[ljhee92]

💡 이슈

• 이번 장에서는 지속적으로 중요한 것이 클라이언트의 관점이라고 이야기합니다.
• 레벨 1 블랙잭 미션에서 저는 Participant를 부모 타입으로, Dealer와 Player를 자식 타입으로 사용했습니다. 클라이언트의 관점에서 이 상속은 서브클래싱일까요 서브타이핑일까요?

❓ 이유

• Dealer와 Player를 호출하고 사용하고 있는 클라이언트의 관점에서 draw라는 메서드를 실행했을 때, 클라이언트는 딜러와 플레이어 모두 동일하게 한 장의 카드를 뽑는 것을 기대할 것이라고 생각합니다. 또, isBust 혹은 isBlackjack과 같은 메서드를 실행했을 때에도 클라이언트는 Dealer와 Player 모두에게 동일한 기대를 한다고 생각합니다. 이런 관점에서는 이 상속이 서브타이핑에 해당한다고 볼 수 있습니다.
• 그렇지만 클라이언트에서 Participant가 아니라 Dealer와 Player를 구분하여 사용하고 있었기 때문에 대체 가능성이 깨졌다고 볼 수 있고, 이 상속은 단순히 중복 코드를 없애기 위한 서브클래싱이었다고 생각이 듭니다.
• 그래서 지금 다시 블랙잭 미션을 구현하게 된다면 상속을 사용하지 않을 것이라고 결론을 내렸습니다.
• 다른 분들은 블랙잭에서 상속을 사용하셨는지 사용하지 않으셨는지, 사용하지 않으셨다면 어떻게 구현하셨는지 궁금합니다.
  또 13장을 읽은 후인 지금, 다시 블랙잭 게임을 구현하게 된다면 상속을 사용하실 것인지에 대한 의견도 같이 나눠보면 좋겠습니다~!

📖 관련 페이지

• Ch 13 전체

[taek2222]

토론하면서 더 얘기를 해보겠지만, 저도 블랙잭 미션을 복습하면서 Dealer 에는 BetAmount 필드가 필요 없었고, Player만 존재했습니다.

이 경우 부모는 BetAmount 금액이 얼마인지 알아야 하는 행동을 정의해야 하는데, 이 기능이 필요 없는 Dealer 입장을 보면 상속 관계가 옳지 않다고 생각했습니다.

[kjyyjk]

저는 미션에서 상속과 합성 두 가지 모두 사용해 보았습니다.

만약 다시 미션을 진행한다면 합성을 사용할 것 같아요.
그 이유는 다음과 같습니다.

상속을 사용한다면 게임 진행을 위해 instanceof나 딜러라는 이름으로 딜러와 플레이어를 구분해야 할 것 같아요.

여기서 우리가 상속을 사용하는 이유는 무엇일까라고 추상적으로 생각해보았는데요.
아마 중복 코드 제거와 함께 서브 타이핑, 런타임 시점에 구체 클래스 변경 등의 얘기를 할 것 같아요.

근데 이미 위에서 언급한 것처럼 클라이언트가 딜러와 플레이어를 구분해야하는 상황이라면,
상속을 사용하는 것이 과연 적절한 선택일까 생각드네요!

하지만 듀이가 말한 것처럼 클라이언트의 관점에서 여러 구체 클래스를 하나의 타입으로 바라볼 수 있는 상황이라면
그에 대한 설계 방식으로 상속을 고려해볼 수 있을 것 같아요.

간단한 예를 들자면 플레이어(초보 플레이어/중수 플레이어/고수 플레이어)와 같은 경우가 있겠네요!