인프런 김영한 강사님의 강의를 듣고 정리한 내용입니다.
기존의 프로그램에서는 일반적인 객체가 제어 흐름을 조종하게 된다. 제어 흐름은 생성, 연결, 실행, 소멸을 의미한다. 제어 권한이 개발자에게 있다.
IoC는 Inversion of Control의 준말로, 제어의 역전을 의미한다.
IoC는 제어 권한이 개발자에게 쥐어지지 않는다.(즉, 일반적인 객체가 제어 흐름을 조종할 수 없게 된다.)
모든 제어 권한을 IoC 컨테이너가 쥐게 된다. 일반적인 객체들은 제어에 관여하지 않고 로직만을 수행하게 된다.
스프링을 사용하는 경우에는, 제어의 권한이 스프링 프레임워크에게 쥐어지고 IoC 컨테이너가 모든 제어를 관리하게 된다.
Dependency Injection의 준말로, 의존 관계 주입을 의미한다.
IoC 컨테이너는 의존 관계의 주입을 담당하기도 하므로 DI 컨테이너라고도 한다.
실행 전에 코드만 보고 알 수 있는 클래스 간의 의존 관계를 말한다.
어떤 클래스 내부에서 다른 클래스(혹은 인터페이스)의 객체를 사용하게 된다면(의존한다면), 이를 의존관계라고 부른다.
만약 인터페이스를 사용한다면 실행 전까지는 어떤 구현체가 객체로 주입될 지 알 수 없다.
어플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성하고, 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것을 의존관계 주입이라고 한다.
의존 관계 주입을 사용한다면 클라이언트 코드를 변경하지 않고 의존관계를 변경할 수 있다. (클라이언트 코드 내부에 특정한 구현체를 적지 않아도 됨.) 설정 파일 내부에서 구현체에 대한 부분을 변경해주기만 하면 의존관계를 쉽게 변경할 수 있다. 의존 관계의 주입에 관한 부분은 모두 컨테이너가 관리한다.
스프링의 IoC/DI 컨테이너이다. 일반적으로 Application Context를 의미한다. 스프링 컨테이너의 최상위 인터페이스인 Bean Factory의 모든 권한을 상속받아서 빈을 관리하게 된다. 또한 편리한 부가 기능들을 상속받아 제공한다.
스프링 부트 사용 시 애플리케이션 클래스 상단에 @SpringbootApplication을 붙여서 스프링 컨테이너를 직접 띄우지 않고도 자동으로 스프링 컨테이너를 띄워줄 수 있다.
ㅋㄲㅈㅁ의 그 콩이 아니다.
스프링 컨테이너에 등록되는 모든 객체를 일컫는다.
스프링 빈(Bean)은 싱글톤(Singleton) 패턴으로 생성된다.
싱글톤 패턴은 프로그램에서 특정 클래스의 객체를 하나만 생성하여 사용하는 패턴을 말한다. 초기 생성자 호출 시 하나의 객체만을 생성하고, 이후에 생성자가 호출되더라도 더 이상 객체를 생성하지 않고 이미 생성된 빈을 반환한다. 그리고 프로그램 종료 시 컨테이너의 모든 빈들은 컨테이너에 의해 자동으로 소멸된다.
스프링에서는 대부분의 빈을 싱글톤 패턴으로 생성하고 스프링 컨테이너에 등록시킨다. 필요에 의해 싱글톤이 아니게 설정할 수 있지만 그런 경우는 극히 드물다.
싱글톤 패턴의 장단점에 관한 내용은 다음 블로그를 참조함.
https://tecoble.techcourse.co.kr/post/2020-11-07-singleton/
빈을 사용하는 이유는 결국 싱글톤 패턴으로 객체를 관리하고자 함이다.
그래서 싱글톤 패턴의 장점이 곧 빈의 사용 이유가 된다.
자원적 이점 (공간, 시간)
객체가 여러 번 생성되는 것을 막고, 이미 생성된 객체가 있다면 그것을 반환한다. 그래서 메모리 공간이 낭비되는 것을 막을 수 있다.
또한 이미 생성된 객체에 대해서 접근하기 때문에 생성 시간이 낭비되지 않아 속도 상의 이점도 있다.
데이터 공유
클래스 간의 데이터 공유 이점이 있다. 싱글톤 객체는 전역으로 관리되기 때문에 객체 간의 데이터 공유가 쉽다. 하지만 이는 곧 동시성 문제를 야기할 수 있기 때문에 잘 설계하여 사용해야 한다.
긴 구현 코드
정적 팩토리 메서드에서 객체 생성을 확인하고 생성자를 호출하는 경우에 멀티스레딩 환경에서 발생할 수 있는 동시성 문제 해결을 위해 synchronized 키워드를 사용해야 한다.(synchronized는 threadlocal과 달리 쓰레드 별로 분리되지 않은 자원에 대해 lock을 걸어서 동시성 문제를 해결 방법이다.)
테스트 상의 어려움
싱글톤 인스턴스는 자원을 공유하고 있기 때문에 테스트가 결정적으로 격리된 환경에서 수행되려면 매번 인스턴스의 상태를 초기화시켜주어야 한다. 그렇지 않으면 어플리케이션 전역에서 상태를 공유하기 때문에 테스트가 온전하게 수행되지 못한다.
클라이언트가 구체 클래스에 의존
new 키워드를 직접 사용하여 클래스 안에서 객체를 생성하고 있으므로, 이는 SOLID 원칙 중 DIP를 위반하게 되고 OCP 원칙 또한 위반할 가능성이 높다.
이외에도 자식클래스를 만들수 없다는 점과, 내부 상태를 변경하기 어렵다는 점 등 여러가지 문제들이 존재한다. 결과적으로 이러한 문제들을 안고있는 싱글톤 패턴은 유연성이 많이 떨어지는 패턴이라고 할 수 있다.