스프링 기본 - 섹션5. 싱글톤 컨테이너

일단 싱글톤은 다음과 같이 앱 전체에서 인스턴스 한번만 만들어두고 해당 객체를 불러올 때마다 미리 만들어둔 인스턴스를 가지고 오는 방식이다. 요청할 때마다 함수 실행하려도 새로 만들면서 사용하면 클라이언트가 매번 요청할 때마다 만들어야 하니 너무 비효율적이기 때문.

 

하지만 싱글톤의 문제점은

- 구현 코드가 너무 많이 들어간다.

저거 하나만 해도 생성자 막고, 불러오면 다시 같은거 반환해주고 하는 코드 일일히 만들어야 함

- 의존관계상 클라이언트가 구체 클래스에 의조한다 -> DIP 위반.

인터페이스에 의존해야 하는데 함수 실행을 위해 인스턴스를 만들고 그걸 의존해야 함

- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.

- 테스트하기 어렵다.

- 내부 속성을 변경하거나 초기화하기 어렵다

스프링 실행하자 마자 바로 만들어지기 때문에 뭘 해볼 수가 없다.

- private 생성자로 자식 클래스를 만들기 어렵다.

- 결론적으로 유연성이 떨어진다.

- 안티패턴으로 불리기도 한다.

 

 

근데 이걸 스프링으로 하면 이 싱글톤의 모든 단점을 상쇠하면서 장점만 가져올 수 있다. ac.getBean()해서 가져올 때마다 미리 만들어진 걸 반환함.

 

다만 조심할 건 싱글톤을 사용할 경우, 하나의 인스턴스만 공유하기 때문에 그 인스턴스에 맴버변수 같은거 정의해서 막 변경할 경우, 진짜 다른 클라이언트에서 요청해서 수시로 바뀔 수 있다. 그냥 함수 실행 용도로만 만들어서 쓰라고(읽기로만).

이걸 고급스럽게 얘기하면 stateful하게 쓰지 말고 stateless하게만 쓰라는 것.

 

그럼 스프링 보기 전에 AppConfig로 정의한 내용을 보자.

 

위에서 처음 한번만 만들고 다음엔 불러오게 할려고 생성자는 private로 막고 막 했는데 스프링의 @Configure로 정의한 AppConfig를 보면 분명 해당 함수를 호출할 때 마다 new로 생성할라고 되어 있다.

그런데 분명 저 함수를 여러번 실행해도 왜 하나의 인스턴스만 만들어지는 것인가?

 

그건 사실 저 클래스를 그대로 만드는 것이 아니라 @Configuration을 했다면 그 클래스를 모방하는 다른 클래스가 만들어지기 때문.

 

근데 난 분명 클래스로 불러올 때 내 AppConfig.class로 내가 만든 클래스가 왜 잘 불러와지나?

그건 전 시간에 했던, 부모 클래스로 부르면 자식들까지 다 오도록 만들어진 것 때문임.