싱글톤 패턴의 구현방법과 한계 + 싱글톤 레지스트리?

싱글톤 패턴의 구현방법과 한계

간략한 정의 : 오브젝트를 하나만 존재하도록 강제하고 이를 애플리케이션의 여러 곳에서 공유 사용하도록 하는 패턴.

-> 패턴 종류 살펴보기 

 

싱글톤 패턴의 구현방법과 함꼐 안티패턴이라고 불리는 이유(한계점)입니다. 

 

구현방법 

1. 클래스 밖에서는 오브젝트를 생성하지 못하도록 생성자를 private으로 만든다.

 

2. 생성된 싱글톤 오브젝트를 저장할 수 있는 자신과 같은 타입의 static 필드를 정의한다.

 

3. static 팩토리 메소드인 getInstance()를 만들고 이 메소드가 최초로 호출되는 시점에서 한번만 오브젝트가 만들어지게 한다.

   생성된 오브젝트는 static 필드에 저장된다. 또는 static 필드의 초기값으로 오브젝트를 미리 만들어 둘수도 있다. 

 

4. 한 번 오브젝트가(싱글톤) 만들어지고 난 후에는 getInstance() 메소드를 통해 이미 만들어져 static 필드에 저장해 둔 오브젝트를

    넘겨준다. 이를 애플리케이션에서 공유 사용.

 

 

한계점

1. private 생성자를 가지고 있기 때문에 상속할 수 없다. 

   private 생성자 -> 오직 싱글톤 클래스 자신만이 자기 오브젝트를 만들도록 제한하는 것

   문제는 private 생성자를 가진 클래스는 다른 생성자가 없다면 객체지향의 장점인 상속과 다형성 사용이 불가능하다는 점이다. 

 

2. 싱글톤은 테스트하기가 힘들다.

  만들어지는 방식이 제한적이기 떄문에 테스트에서 사용될 때  Mock 오브젝트 등으로 대체하기가 힘들다.

  즉 테스트가 어렵거나 불가능하다. 

 

3. 서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.

  서버에서 클래스 로더를 어떻게 구성하고 있느냐에 따라서, 혹은 여러 개의 JVM에 분산돼서 설치가 되는 경우에

  싱글톤 클래스임에도 불구하고 하나 이상의 오브젝트가 만들어질 수 있다. 

 

4. 싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못하다. 

    아무 객체나 자유롭게 접근하고 수정하고 공유할 수 있는 전역 상태를 갖는 것은 객체지향 프로그래밍에서는

    권장되지 않는 프로그래밍 모델이다. 대신 static 필드와 메소드로만 구성된 클래스를 사용하는 것을 권장.

 

5. 코드가 지저분해 진다. 는 제 생각

 

 

 

 

 

---

뜬금포 

싱글톤 레지스트리란 ? 

사실 이 글은 스프링의 애플리케이션 컨텍스트의 싱글톤 레지스트리를 공부하다가 싱글톤 패턴과 헷갈리지 않기 위해 공부하다 정리하는 글입니다. 따라서 여기에 싱글톤 레지스트리도 슬쩍 정리해봅니다. 

 

싱글톤 레지스트리(Singleton registry)

스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다. 

하지만 자바의 기본적인 싱글톤 패턴의 구현방식은 여러 단점을 가지고 있기 때문에 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공하는데 이를 싱글톤 레지스트리라고 한다. 

 

스프링의 애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이다. 

 

장점

1. static 메소드와 private 생성자를 사용하지 않은 평범한 클래스를 싱글톤으로 활용하게 해준다. 

   따라서 싱글톤 방식으로 사용될 애플리케이션 클래스라도 public 생성자를 가질 수 있다. 

 

2. 테스트 환경에서 자유롭게 오브젝트를 만들 수 있다. 

 

3. 싱글톤 패턴과 달리 객체지향적인 설계 방식과 싱글톤 패턴을 제외한 디자인 패턴등을 적용하는데 아무런 제약이 없다.