[Design Pattern] 싱글턴 패턴(Single Pattern)에 대해 알아보자

Definition

싱글턴 패턴(Singleton Pattern)은 클래스 인스턴스를 하나만 만들고, 그 인스턴스로의 전역 접근을 제공한다.

 

Situation

- 단일 객체에 대한 제어된 액세스가 필요할 때

- 프로그램의 클래스에서 모든 클라이언트가 사용할 수 있는 단일 인스턴스만 있어야 하는 경우. 예를 들어, 프로그램의 다른 부분에서 공유하는 단일 데이터베이스 객체
- 전역 변수를 더 엄격하게 제어해야 하는 경우

Structure

- Singleton 클래스는 자체 클래스의 동일한 인스턴스를 반환하는 정적 메서드 getInstance를 선언한다.

- Singleton의 생성자는 클라이언트 코드에서로부터 숨겨져야 한다. getInstance 메서드를 호출하는 것이 Singleton 객체를 가져오는 유일한 방법이어야 한다.

- Java나 C++에서 Singleton 생성자를 private로 선언하면 외부에서 호출이 불가능하다.

 

Pros

- 클래스에 단일 인스턴스만 있음을 확인할 수 있다.

- 해당 인스턴스에 대한 전역 액세스 포인트를 얻는다.

- 싱글톤 객체는 처음 요청될 때만 초기화된다.

 

Cons

- 단일 책임 원칙을 위반한다. Singleton은 본질적으로 최소한 두 가지 책임이 있다. 자신의 생성 및 수명 주기를 제어하기 때문이다.

- Singleton 패턴은 예를 들어 프로그램의 구성 요소가 서로에 대해 너무 많이 알고 있는 경우 잘못된 디자인을 가릴 수 있다.

- Singleton 패턴은 다중 스레드 환경에서 특별한 처리를 하여 다중 스레드가 Singleton 객체를 여러 번 생성하지 않도록 한다.

- 많은 테스트 프레임워크가 mock 객체를 생성할 때 상속에 의존하기 때문에 Singleton의 클라이언트 코드를 단위 테스트하기 어려울 수 있다. 싱글톤 클래스의 생성자는 private이고 대부분의 언어에서 정적 메서드를 재정의 하는 것이 불가능하기 때문에 Singleton을 mock 하는 창의적인 방법을 생각해야 한다. 아니면 그냥 테스트를 작성하지 말거나 Singleton 패턴을 사용하지 마라.

 

비슷한 패턴

- State 객체는 종종 Singleton이다. 

- Facade 클래스는 대부분의 경우 단일 Facade 객체로 충분하기 때문에 종종 Singleton으로 변환될 수 있다.

- Flyweight는 객체들의 모든 공유 상태를 단 하나의 Flyweight 객체로 어떻게든 줄일 수 있다면 Singleton과 비슷하다. 그러나 이러한 패턴 사이에는 두 가지 근본적인 차이점이 있다.

• 단 하나의 Singleton 인스턴스만 있어야 하는 반면, Flyweight 클래스는 고유 상태가 다른 여러 인스턴스를 가질 수 있다. 
• Singleton 객체는 변경할 수 있다. Flyweight 객체는 변경할 수 없다.

- Abstract Factory, Builder 그리고 Prototype은 모두 Singleton으로 구현될 수 있다.

 

기타

Synchronize the getInstance() method (Option 1):

- 작동이 보장되는 간단한 기술이다. 잦은 잠금으로 인해 런타임 성능에 약간의 영향을 미친다.

Use eager instantiation (Option 2):

- 항상 클래스를 인스턴스화하려는 경우 인스턴스를 정적으로 초기화해도 문제가 되지 않는다.

Double checked locking (Option 3):

- 완벽한 솔루션 w.r.t 성능. 그러나 성능 문제가 없는 경우 이중 확인 잠금이 과도할 수 있다. 또한 최소한 Java 5 이상인지 확인해야 한다.