싱글턴은 전역적으로 생성되어서 어디서든 접근이 가능하도록 설계된 디자인 패턴이다.
다른 스크립트에서 객체를 참조하는 것이 편리하다.
Unity에서는 다른 스크립트 내부에서 GetComponent<T>()를 사용하여 다른 스크립트를 참조하는 경우가 다분하다. 하지만 이는 프로젝트의 규모가 커질수록 어렵다.
씬 이동 시에 데이터가 파괴되지 않는다.
Unity는 기본적으로 씬 이동 시에 현재 씬에 있던 모든 오브젝트들이 파괴된다. 오브젝트들이 파괴되면서 오브젝트에 붙어있던 컴포넌트 또한 파괴되고, 컴포넌트에 저장된 데이터들도 파괴된다.
단 하나의 객체 생성을 보장한다.
게임 데이터를 불러오는 DataManager가 있다고 가정해보자. 그리고 DataManager 객체가 2개 생성되어 있고, 각각의 데이터 경로가 다르다고 한다면 이는 문제의 여지가 다분하다.
싱글턴 객체가 전역 상태를 유지하기 때문에 발생하는 문제들이 존재한다.
클래스 간의 의존성이 높아진다.
싱글턴으로 구현한 객체에 다른 클래스들이 언제든지 접근이 가능하기 때문에 의존성이 높아진다.
이는 SOLID 원칙 중 DIP에 위배된다.
테스트가 매우 어렵다.
객체의 값을 변경하게 되는 경우에는 그 값이 유지되어 다음 테스트 케이스에 영향을 미칠 수 있다.
유지보수가 매우 어렵다.
다수의 클래스가 하나의 싱글톤 객체에 접근하게 된다면 어느 시점에서 문제가 발생하는지 디버깅이 어렵다. 호출 중인 함수들을 전부 찾아서 문제를 해결해야 한다.