디자인 패턴
싱글톤 패턴
역할
- 클래스가 자체의 인스턴스 하나만을 인스턴스화하도록 보장
- 해당하는 하나의 인스턴스에 대한 손쉬운 글로벌 액세스 제공
단점
- 싱글톤은 많은 종속성을 가려 훨씬 해결하기 어려운 버그를 유발
- 싱글톤은 테스트를 어렵게 만든다. 유닛 테스트는 반드시 서로 독립적으로 수행해야 하는데 싱글톤은 씬 전반에서 많은 게임 오브젝트의 상태를 변경할 수 있기 때문에 테스트에 방해가 될 수 있다.
- 싱글톤은 결합도를 높인다. 결합도가 높으면 확장성, 수정 등이 어려워지고 가독성이 떨어진다.
제너릭 싱글톤 구현
이전 블로그에서 한 번 정리했었다. https://velog.io/@asc98/20241023-TIL
주의할 점
싱글톤을 사용할 경우 라이프 사이클에 주의해야한다.(Awake, Start)
모든 싱글톤을 DontDestroyOnLoad할 필요가 없다.
DontDestroy했는데 참조하는 객체들이 null 되어있는 경우가 생기면 더 불편하다.
Singleton/ SingletonDonstDestroy로 구분하여 구현해도 좋다.
InitializationManager를 만들어 Init()으로 초기화 순서를 지정할 수 있다.
오브젝트 풀 패턴
역할
많은 수의 게임 오브젝트를 생성하고 파괴할 때 CPU의 부담을 줄이는 최적화 기법
할당/해제에 걸리는 성능 낭비와 메모리 낭비를 줄이고자 사용한다.
구현
필요할 만큼을 미리 생성해두고, 비활성해둔다.
생성 대신 비활성된 오브젝트를 찾아 활성화 한다.
미리 생성해둔 것보다 많은 양을 요구한다면 추가로 생성한다.
파괴 대신 오브젝트를 비활성화한다. (최대 수량을 넘어 추가로 생성된 오브젝트는 파괴)
전략패턴
역할
원본 클래스를 건드리지 않고 다양하게 추가되는 방식을 대응
구현
전략 패턴을 구현하기 위해서 전략 인터페이스를 정의한다.
전략 인터페이스는 세부 동작을 구현
상태 패턴
역할
여러 상태들이 있고 실행되는 로직이 달라짐을 체계적으로 관리하고 싶을 때
public interface IState
{
public void Enter()
{
// 상태에 처음 진입할 때 실행되는 코드
}
public void Update()
{
// 프레임당 로직. 새로운 상태로 전환하는 조건 포함
}
public void Exit()
{
// 상태에서 벗어날 때 실행되는 코드
}
}IState를 구현하는 각 상태에 대한 클래스를 만든다.
다른 클래스인 StateMachine은 컨트롤 플로가 상태에 진입하고 상태에서 벗어나는 방법을
관리한다.
장점
상태 패턴은 오브젝트에 대한 내부 로직을 설정할 때 SOLID 원칙을 준수하는 데 도움이 된다.
각 상태는 상대적으로 크기가 작으며 다른 상태로 전환하기 위한 조건만 추적한다.
개방-폐쇄 원칙에 따라 기존 상태에 영향을 주지 않고 상태를 더 많이 추가할 수 있다.
번거로운 switch 또는 if 문을 사용하지 않아도 된다.
단점
추적해야 하는 상태가 많지 않다면 추가 구조는 과할 수 있다. 이 패턴은 상태의 복잡도가 특정 수준까지 올라갈 것으로 예상하는 경우에만 유용하다.
FSM
Finite State Machine 유한 상태 기계
N개의 유한 상태, 현재 상태, 상태 전환
HFSM
Hierachial Finite State Machine 계층형 유한 상태 기계
큰 개념의 상태와 실제 행동을 결정하는 세부 상태를 구분하여 구현
