Singleton Pattern

싱글톤 패턴은 개발을 조금이라도 접해봤다라면 한번쯤은 들어봤을 것이다.

 

싱글톤 패턴은 단 하나의 유일한 객체를 만들기 위한 코드 패턴이다. 쉽게 말하자면 메모리 절약을 위해, 인스턴스가 필요할 때 똑같은 인스턴스를 새로 만들지 않고 기존의 인스턴스를 가져와 활용하는 기법을 말한다.

 

개발을 할 때 전역변수를 선언하여 사용하는 이유는 똑같은 데이터를 메서드마다 지역 변수로 선언해서 사용하면 무의미하기도하고 낭비이기 때문에, 전역에서 한번만 데이터를 선언하고 가져와 사용하면 효율적이기 때문이다.

 

이러한 개념을 그대로 클래스에 대입한 것이 싱글톤 패턴이라고 생각하면 된다.

 

따라서 보통 싱글톤 패턴이 적용된 객체가 필요한 경우 해당 객체가 리소스를 많이 차지하는 역할을 하는 무거운 클래스일때 적합하다. 예를 들어 매니저 클래스를 싱글톤 패턴을 사용한다.

 

하지만 싱글톤 패턴이 사용하기도 쉽고 모든 클래스에 접근하여 이걸 사용하면 개발이 편하지 않나?라고 생각하면 반은 맞고 반은 틀리다라고 할 수 있을 것이다. 

 

싱글톤의 문제점

1. 모듈간 의존성이 높아진다.

대부분의 싱글톤을 이용하는 경우 인터페이스가 아닌 클래스의 객체를 미리 생성하고 정적 메서드를 통해 사용하기 때문에 클래스 사이에 강한 의존성과 높은 결합이 생기게 된다. 즉 하나의 싱글톤 클래스에 여러 모듈을 공유하니까 싱글톤 인스턴스가 변경되면 이를 참조하는 모듈들도 수정이 필요하게 된다라는 뜻이다.

 

2. SOLID 원칙에 위배되는 경우가 많다.

싱글톤 인스턴스 자체가 하나만 생성하기 때문에 여러가지 책임을 지니게 되는 경우가 많다. 그러면 단일책임원칙을 위배하기도하고, 싱글톤 인스턴스가 혼자 너무 많은 일을 하거나 , 많은 데이터를 공유 시키면 다른 클래스들 간의 결합도도 높아지게 되어 개방-패쇄 원칙도 위배된다. 또한 클라이언트가 인터페이스와 같은 추상화가 아닌 구체 클래스에 의존하게 되어 의존 역전 원칙도 위배이 된다. 

 

3. 모듈을 단위 테스트하기 어렵다.

단위 테스트를 할 때, 테스트가 서로 독립적이어야 테스트를 어떤 순서로든 실행 할 수 있어야 하는데, 싱글톤 인스턴스는 자원을 공유하고 있기 때문에 테스트에 온전하게 수행되지 못할 수 있다.

 

그래서 적절하게 사용하는 것이 좋다!!!

 

그렇다면 이제 실제 어떻게 쓰이는지 예제를 만들어 보겠다.

 

Singleton.class

 

조금 설명을 하자면

싱글톤 클래스를 제네릭으로 만들어주고 MonoBehaviour를 상속받고 조건을 T는 MonoBehaviour를 상속받은 클래스여야 한다는 조건을 달아준다. 그리고 get으로 해당 인스턴스가 null이면 게임오브젝트에 해당오브젝트를 넣어준다. 오브젝트가 null일 경우는 새로운 게임오브젝트를 만들어준다. awake에는 당연히 씬을 이동해도 파괴되지 않게 DontDestroyOnLoad로 선언해준다.

 

이제 씬을 이동해도 데이터들을 유지시켜야하는 것들을 담아주는 DontDestroyObject 클래스를 만들어서 싱글톤을 상속받고, SetSingleTon 함수를 실행시켜 InitManager에 데이터유지가 필요한 매니저들을 담아주면 된다. 그럼 이제 해당 매니저들을 접근하면서 사용할 수 있게 된다.

 

여기까지 싱글톤 패턴에 대해서 알아보겠다. 

마지막으로 여러 블로그들을 살펴보면서 많은 싱글톤 구현방법을 봤지만 각자 다르게 구현하지만 제네릭으로 만들어주는 형태는 사용해야 편할 것이다!!!