싱글톤

요청을 할 때 마다 객체를 새로 생성하는 것은 낭비이다. -> 싱글톤 등장

 

싱글톤의 문제 

- 구현 코드가 길다.

- 테스트 하기 어렵다.

- DIP, OCP 원칙 위반 가능성이 높다.

- 유연성이 떨어지고 자식 클래스를 만들기 어렵다.

 

 

-> 스프링 컨테이너 등장! ( @Bean ) 

 

싱글톤 방식의 주의점

- 무상태로 설계 해야 한다. 

- 특정 클라이언트에 의존적인 필드가 있으면 안된다.

- 가급적 읽기만 가능해야 한다.

- 필드 대신 공유되지 않는 것들을 사용해야 한다. 

 

싱글톤이 보장 되는 이유

 

- @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고,

   스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.

 

# @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.