4 - Singleton Pattern

💡 Singleton Pattern 이란?

 

• 기업용 온라인 서비스 기술을 지원하기 위해 탄생
• 객체 인스턴스를 1개만 사용하고 공유하도록 하는 디자인 패턴
• private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용 못하게 막아야함
• 아래 사진은 웹 어플리케이션 특성상 여러 요청이 올때의 DI 컨테이너 동작을 사진으로 표현한 것
  저 그림의 문제점은 동일한 요청이 들어오면 객체를 계속 생성하기 때문에 리소스 문제 등,
  다양한 방면에서 비효율적이다

 

 

Singleton 적용이 안된 순수 DI 컨테이너를 이용한 테스트

• 아래 사진에 나온것처럼 AppConfig 에게 MemberService를 2번 요청한 결과의 주소값이
  서로 다른것을 확인 가능하다
• 이렇게 객체가 계속 생성되면 메모리에 모든 객체가 다 남기때문에 리소스가 불필요하게 많이 낭비됨
• 적은양의 객체는 Garbege Collector에서 문제없이 처리하지만 객체가 몇만개씩 생성/소멸을 하면 메모리 낭비가 심하다

 

Singleton 적용 : 해당 객체를 1개만 생성하고 공유하기

테스트를 위한 SingletonService 클래스 생성

테스트 실행 시 같은 인스턴스를 참조함

 

💡 설정구성 정보(AppConfig) 등 전부 다 싱글톤 적용을 해야 할까?

스프링 컨테이너가 객체를 기본적으로 Singleton으로 만들어서 관리하기 때문에 그럴 필요가 없음

 

Singleton의 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 테스트가 어렵다.
• 의존관계상 클라이언트가 구현체에 의존 -> DIP,OCP 위반할 가능성이 높음.
• 내부 속성을 변경하거나 초기화가 어렵다.
• private 생성자로 하위 클래스 생성이 어려움
• 유연성 down (Dependency Injection)
• 안티패턴 이라고도 불림