getBean와 일반 객체 생성 차이

getBean : 객체 반환 시 동일한 객체 반환 ( 주소가 같은 동일한 객체 )

일반 객체 생성 : 매번 새로운 객체를 반환

싱글톤 레지스트리로서의 애플리케이션 컨텍스트

싱글톤 레지스트리는 무엇인가?

• 싱글톤을 관리하는 IoC 컨테이너
• 싱글톤은 애플리케이션에서 하나만 존재하는 오브젝트이다.

스프링은 왜 싱글톤으로 빈을 만들까?

• 클라이언트 요청마다 서비스 오브젝트를 만들면, 서버 부하가 발생함.
  • 서비스 오브젝트 : 프로그램 로직 관련 오브젝트 ( 불변 )
    • 서블릿에서는 하나의 서비스 오브젝트를 여러 스레드에서 공유한다

싱글톤 구현 방법

1. 클래스 밖에서 오브젝트를 생성하지 못하도록 생성자를 private로 만든다
   • 오브젝트의 개수를 제한하는 개념이므로 생성자는 private로 해야함.
2. 생성된 싱글톤 오브젝트를 저장할 static 필드를 만든다.
   • 다른 스레드에서 공유해야 하니까 static으로 만듦
3. static 팩토리 메소드인 getInstance()를 만들고, getInstance()가 호출 되는 시점에서 한 번만 오브젝트가 만들어지도록 함.
4. getInstance()는 만들어진 싱글톤 오브젝트를 반환한다.

public class UserDao {
    private ConnectionMaker connectionMaker;
    // INSTANCE : 싱글톤 오브젝트로 UserDao 객체를 받아줌.
		private static UserDao INSTANCE;

		//생성자를 private로 만듦.
    private UserDao(ConnectionMaker connectionMaker) {
        this.connectionMaker = connectionMaker;
    }

		// getInstance()로 싱글톤 오브젝트를 반환할 수 있도록 함.
    public static synchronized UserDao getInstance(){
        if(INSTANCE==null){
            INSTANCE = new UserDao(new DConnectionMaker());
        }
        return INSTANCE;
    }
}

싱글톤 패턴의 한계

1. 생성자가 private이므로 상속을 할 수 없다.

   → 객체 지향 프로그래밍의 장점임 상속과 다형성을 적용할 수 없다.

2. 테스트하기 어렵다.

   → 동적으로 오브젝트를 주입할 수 없으니, 필요한 오브젝트를 직접 만들어야 한다.

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

   → 싱글톤 기법이 서버 환경에서 보장되지 않는다.

   → JVM에 분산되서 설치되면, 오브젝트가 여러 개 생기니 싱글톤 가치가 떨어진다.

4. 싱글톤을 사용하는 것은 전역 상태를 갖기에 바람직하지 않다.

   → 싱글톤은 static 팩토리 메소드를 통해서 자유롭게 객체에 접근할 수 있으므로 전역 상태를 갖기 쉽다.

   • 이러한 전역 상태는 객체 지향 프로그래밍에서 권장하지 않는다.