오늘은 SOLID원칙과 이를 활용한 FSM기법에 대해 정리해 보겠습니다.
1) SOLID
SOLID는 좋은 소프트웨어 설계를 위해 지켜야 할 객체 지향 설계의 5가지 원칙을 의미하며 다음과 같습니다.
-
단일 책임 원칙 (SRP)
하나의 클래스는 단 하나의 책임(기능)만 가져야 합니다.
예를 들어 플레이어 컨트롤러가 이동 로직과 사운드 재생, UI 업데이트를 모두 담당한다면 사운드와 UI는 별도의 클래스로 분리해야 합니다. -
개방 폐쇄 원칙 (OCP)
확장에는 열려 있고 수정에는 닫혀 있어야 합니다.
새로운 기능을 추가할 때 기존의 코드를 수정하지 않고 인터페이스 등을 통해 확장할 수 있도록 설계해야 합니다. -
리스코프 치환 원칙 (LSP)
자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 합니다.
부모 타입의 변수에 어떤 자식 객체를 넣어도 프로그램의 논리적 흐름이 깨지지 않아야 함을 의미합니다. -
인터페이스 분리 원칙 (ISP)
자신이 사용하지 않는 기능이 포함된 거대한 인터페이스를 구현하지 않도록 해야 합니다.
필요한 기능별로 인터페이스를 작게 쪼개어, 필요한 것만 골라 구현할 수 있게 만들어야 합니다. -
의존성 역전 원칙 (DIP)
구체적인 클래스가 아니라 추상화된 인터페이스나 추상 클래스에 의존해야 합니다.
이를 통해 객체 간의 결합도를 낮추고 유연한 구조를 만들 수 있습니다.
2) FSM
FSM(Finite State Machine)은 객체가 가질 수 있는 상태를 유한하게 정의하고, 한 번에 하나의 상태에만 머물게 하는 설계 방식입니다.
예시로 플레이어 캐릭터의 상태를 Idle, Move, Attack, Die 등으로 나누고 각 상태에서 일어날 로직을 분리하여 관리합니다.
FSM에서 가장 중요한 것은 상태 전이(Transition)의 통제입니다.
특정 조건(Trigger)이 충족되었을 때만 다음 상태로 넘어가도록 전이 규칙을 엄격하게 관리해야 버그를 줄일 수 있습니다.
<style>
public enum State { Idle, Move, Attack }
public class PlayerFSM : MonoBehaviour
{
private State currentState = State.Idle;
public void ChangeState(State newState)
{
// 상태 전이를 통제하는 핵심 함수
if (currentState == State.Attack) return; // 공격 중에는 상태 변경 불가 예시
currentState = newState;
}
void Update()
{
switch (currentState)
{
case State.Idle: /* 대기 로직 */ break;
case State.Move: /* 이동 로직 */ break;
}
}
}
</style>3) Tag
Tag는 유니티에서 특정 게임 오브젝트를 식별하기 위해 사용하는 문자열 값입니다.
Tag는 주로 '이 물체가 무엇인가'라는 식별(Identification)을 위해 사용합니다.
Layer와 비슷해보이지만 Layer는 물리 엔진의 충돌 체크나 카메라의 렌더링 범위를 제한하는 필터링 용도로 사용한다는 점에서 다릅니다.
이 Tag를 로직에서 잘못 사용하거나 남발할 경우 성능에 악영햘을 줄 수 있습니다.
기본적으로 문자열 비교연산이 숫자 연산보다 무거우며, 수천 개의 오브젝트를 태그로 찾으려하면 CPU 연산 부담이 커지기 때문에 자주 참조하는 객체는 태그 검색보다는 싱글톤이나 직접 참조 방식을 고려하는것이 좋습니다.
