스프링 IoC
IoC(Inversion of Control) 의 약자로 제어의 역전이라는 의미를 가진다. 이는 어플리케이션 안에서 객체가 생성/해제 및 참조하는 작업을 전적으로 프레임워크가 관리하는 형태를 말한다.
스프링 프레임워크에서는 객체의 생명주기 및 타 객체와의 의존관계 설정을 객체 자신이 아닌 어플리케이션 컨텍스트(혹은 IoC 컨테이너, 빈 팩토리 등으로 표현)가 해주기 때문에 IoC 프레임워크라고 할 수 있다.
IoC 의 개념은 꼭 스프링 프레임워크 뿐만 아니라 타 프레임워크 및 디자인 패턴과 같이 범용적인 곳에서 사용되는데, 어떤 객체의 사용 여부가 타 객체에 의해 수동적으로 결정되어 사용되는 방식도 IoC 의 개념이 적용된 거라고 볼 수 있다.
스프링 DI
스프링 DI(Dependency Inversion) 는 의존 관계 주입이라는 의미로 스프링이 다른 IoC 프레임워크와는 다른 차별화된 특징 중 하나라고 볼 수 있다. 이에 대해 좀 더 상세한 예를 살펴보자.
의존 관계
의존 관계라는건 A 가 B 타입 클래스 내에 메서드를 사용하는 경우 클래스 간의 의존관계가 있다 라고 표현합니다. 이는 결국 B 클래스 내부의 기능이 추가/수정되는 경우 A 타입 객체에게도 영향이 가는 것을 의미한다.
이때 A 클래스와 B 클래스 간의 의존관계를 느슨하게 할 수 있는 방법이 A 클래스가 B 클래스를 직접 참조하는 것이 아닌 C 인터페이스를 참조하도록 하고, B 클래스는 C 인터페이스를 구현하도록 하는 것이다.
이렇게 인터페이스를 통해 구현 클래스간의 직접적인 의존 관계를 없애주게 되면 B 클래스 내부 변경에 대한 영향을 덜 받게 된다.
인터페이스를 통한 느슨한 의존 관계에서는 클래스 다이어그램 만으로는 실제 A 클래스가 런타입 시점에 C 인터페이스를 구현한 어떤 구현 클래스를 사용할지 알 수 없다. 사전에 설정을 통해 어떤 클래스의 객체를 쓸지 정해둘 수는 있으나 그 내용이 설계나 코드 상에는 나타나지 않는다. 결국 컨테이너 설정에 따라 구체적인 사용 클래스를 지정해주고, 런타임 시점에 객체간의 의존 관계를 연결해주는 작업이 바로 의존관계 주입 이다.
설계 시점에서 알 수 없는 런타임 시점에 객체간의 의존관계를 제3자(스프링 컨테이너)가 결정하고, 컨테이너가 객체 레퍼런스를 제공해주는 것! 그것이 의존관계 주입의 핵심!
스프링 DL
의존관계 검색(Dependency Lookup)은 의존관계가 있는 객체를 외부에서 주입 받는 것이 아닌, 의존관계가 필요한 객체에서 직접 검색하는 방식을 말합니다. 헷갈릴 수 있는 부분이 클라이언트 객체(의존관계가 필요한 객체)에서는 의존하고자 하는 인터페이스 타입만 지정해서 검색할 뿐 해당 인터페이스를 구현한 구체적인 클래스 객체에 대한 결정과 해당 객체에 대한 생명 주기는 IoC 컨테이너에서 책임집니다.
참조
문헌
Dependency Inversion이 아니라 Injection입니다