싱글톤 패턴에 대해 일정 정도 간단하게 정리해서 적어보려고 한다.
1. 기본 정의
2. 코드 예시
3. 장단점
1. 기본 정의
* 게임/메모리 상 단 하나만 존재하고 언제 어디든 접근 가능한 오브젝트 만들 때 사용하는 패턴.
* 예시 : 게임 매니저, 오디어 매니저..etc
2. 기본 구조
++ Lazy Initialization(지연 초기화) 방식을 추가해 싱글톤을 필요할 때만 생성하는 방식으로 작성했다.
public class AudioManager : MonoBehaviour
{
//정적으로 선언해서 어디든 접근 가능.
private static AudioManager _instance;
//인스턴스가 필요할 때만 생성.
public static AudioManager Instance
{
get
{
if(_instance == null)
{
_instance = new GameObject("AudioManager").AddComponent<AudioManager>();
}
return _instance;
}
}
//씬이 전환되더라도 삭제 방지 및 중복 생성 방지
private void Awake()
{
if(_instance == null)
{
_instance = this;
DontDestroyOnLoad(gameObject);
}
else if(_instance != this)
{
Destroy(gameObject);
}
}
}
3. 장점
* 접근성 용이
= 어디서든 AudioManager.Instance로 싱글톤 인스턴스로 접근 가능.
* 객체의 일관성 유지
= 객체가 한 번만 생성되고 전역적으로 공유되므로 일관성 유지 가능.
* 리소스 관리 쉬움
= 씬 간 데이터나 리소스 쉽게 공유 가능.
4. 단점
* 어려운 테스트
= 객체 간 의존성이 강해져 유닛 테스트나 모킹이 어려워진다.
* 파괴된 인스턴스 참조할 경우 관리 필요
= 인스턴스가 유니티 엔진의 라이프사이클을 따라가기 때문에 특정 조건에서 인스턴스가 파괴되었을 때 이를 참조하려 하면 null reference error이 발생할 수 있다.
* 메모리 누수 관리 필요
= 싱글톤 인스턴스가 파괴되지 않아서 리소스를 과도하게 점유하거나 해제되지 않는 메모리 문제가 발생할 수 있다.
= 필요하지 않은 경우에 리소스를 해제해야 한다.
* 의존성 주입 필요
= 프로젝트가 커질 수록 글로벌 상태 관리가 복잡해진다.
유니티에서 매니저를 생성할 때 보통 싱글톤을 많이 썼는데, 여러 종류의 매니저가 많아질 경우 원하는 때 원하는 매니저를 생성하고, 해당 경우가 아니면 파괴하는 방법만 생각을 했었다. 싱글톤을 많이 사용해서 글로벌한 접근으로는 편하지만, 싱글톤을 사용하지 않고 구현하는 매니저에 대해서도 생각해보면 좋을 것 같다.