Singleton Container

✅ Web Application & Singleton

스프링없는 순수한 DI 컨테이너 - AppConfig

• 요청을 할 때 마다 객체를 새로 생성한다 ➡️ 메모리 낭비가 심함
• 해결방안: 객체가 1개만 생성, 공유하도록 설계 ➡️ 싱글톤 패턴(Singleton Pattern)

Singleton Pattern

• 디자인 패턴
• Class 의 instance가 딱 1개만 생성되도록 보장
• 외부에서 임의로 new 생성 막기

public class SingletonTest {
	//1. static 영역에 객체를 딱 1개만 생성해둔다.
	private static final SingletonTest instance = new SingletonTest();
    
    //2. public 으로 열어서 개체 인스턴스가 필요하면 이 static 메서드를 통해서만 접근하도록 허용
    public static SingletonTest getInstance() {
    	return instance;
    }
    //3. 생성자를 private로 선언해서 외부에서 new를 사용한 객체 생성을 못하게 막는다.
    private Singletontest() {
    }
    
    public void login() {
		//로직 호출    
    }
}

Singleton Pattern 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많음
• 클라이언트가 구체 클래스에 의존
  • DIP 위반 (DIP: Dependency Inversion Principle - 의존 역전 원칙)
  • OCP 위반 가능성 ⬆️ (OCP: Open-Closed Principle - 개방 폐쇄 원칙)
• 테스트 어려움
• 내부 속성 변경, 초기화 어려움
• 자식클래스 만들기 어려움(private Constructor)
  ➡️ 유연성이 떨어짐, 안티 패턴으로 불리기도 함

✅ Singleton Container

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다.

Singleton Container

• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리
• 스프링 컨테이너는 싱글톤 컨테이너의 역할을 함 --싱글톤 객체를 생성, 관리하는 기능 --> 싱글톤 레지스트리
• 싱글톤 패턴의 단점 해결하면서 객체를 싱글톤으로 유지
  

Singleton 방식의 문제점

• 하나의 같은 객체를 공유하기 떄문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안됨
• 무상태 (stateless)로 설계
• 클라이언트는 가급적 읽기만 가능

✅ @Configuration & Singleton

=> 스프링 설정 정보는 항상 @Configuraion 사용하자