재사용 방식 선택 기준

관계별 설계 선택

블루프린트 재사용 구조를 고를 때는 코드 양보다 변경 방향을 먼저 본다. is-a 관계면 상속, can-do 능력이면 인터페이스, has-a 기능 조각이면 Actor Component가 보통 더 자연스럽다.

01

관계 문장 쓰기

A는 B다, A는 할 수 있다, A는 기능을 가진다 중 어느 말이 자연스러운지 본다.

문장이 어색하면 구조도 오래 못 간다
02

변경 방향 확인

부모 변경이 모든 자식에 퍼져도 좋은지, 기능별로 붙였다 떼야 하는지 판단한다.

상속은 전파가 빠르지만 되돌리기 어렵다
03

호출자 관점

호출자가 구체 타입을 알아야 하는지, 인터페이스 메시지만 보내면 되는지 나눈다.

인터페이스는 약속이고 구현 저장소가 아니다
04

상태 소유

기능이 자체 상태와 Tick, 이벤트 바인딩을 가지면 컴포넌트 후보로 본다.

복수 actor에 붙일 수 있으면 has-a에 가깝다
05

테스트 비용 비교

새 타입 추가, 기능 제거, 부모 수정 때 깨지는 범위를 비교한다.

결정표는 미래 변경 비용을 보는 도구다
상속
공통 정체성 모든 자식이 같은 기본 상태와 수명 주기를 공유할 때 적합하다.
깊어질수록 override 추적이 어렵다
인터페이스
가능한 행동 서로 다른 클래스에 같은 호출 약속을 붙일 때 쓴다.
공통 변수 저장에는 맞지 않는다
컴포넌트
붙이는 기능 체력, 상호작용, 감지처럼 actor에 조립되는 상태 있는 기능에 좋다.
소유 actor와 초기화 순서를 확인한다
조합
혼합 구조 상위 타입은 얇게 두고 실제 기능은 컴포넌트와 인터페이스로 나눌 수 있다.
거대한 부모 클래스를 피한다

관계별 설계 선택

새 타입 추가 새 캐릭터나 오브젝트를 추가할 때 어느 파일을 고쳐야 하는지 적어본다.
기능 제거 특정 자식에서만 기능을 빼야 할 때 상속이 방해되는지 본다.
호출 분리 호출자가 구체 클래스를 캐스팅하지 않고도 필요한 메시지를 보낼 수 있는지 확인한다.