Inversion of Control 은 객체 혹은 프로그램의 일부에 대한 제어권을 컨테이너, 혹은 프레임워크에게 주는 소프트웨어 공학의 원칙입니다. 전통적인 프로그래밍에서 개발자는 라이브러리를 통해 라이브러리의 코드를 직접 호출하였습니다. 즉 개발자가 프로그램 실행 흐름의 제어권을 가지고 있었습니다. 프레임워크를 활용한 현대적인 프로그래밍에서는 프레임워크가 프로그램의 전체 실행 흐름을 제어하며 개발자는 프레임워크를 위한 커스텀 코드를 작성합니다. 이는 프레임워크의 클래스를 상속하거나 우리의 커스텀 클래스를 프레임워크에 꼽아넣는 방식으로 이루어집니다.이러한 구조의 이점은 다음과 같습니다
- 작업의 실행과 구현의 결합 제거 (decoupling)
- 구현간 변경의 용이성 (ocp)
- increase modularity → follows increase testability
IOC 를 달성하기 위한 다양한 메커니즘이 있습니다.
- 전략 패턴, 서비스 로케이터 패턴, 팩토리 패턴 그리고 의존성 주입(DI)
이번 정리에서는 가장 흔히 IOC의 개념으로서 이해되고 Spring 이 IOC를 위해 사용중인 메커니즘인 DI에 대해서 정리해 보겠습니다. DI외의 IOC 메커니즘은 아래 페이지를 참고해주세요.
- See Also)
DI - Dependency Injection, 의존관계 주입
Dependency Injection 이전에
Dependency. 즉, 의존관계란 무엇인지 먼저 알아봅시다.클래스 의존성의 종류
- 연관관계 Association
- A 에서 B로 이동할 수 있다.
- A 에서 B로 이동할 수 있는 영구적인 경로가 존재한다.
의존관계 Dependency- A의 메서드 파라미터에 B가 등장을 하거나
- A의 메서드의 리턴 타입으로 B가 등장을 하거나
- A내부에서 B를 생성하는 경우
- A가 B와 협력을 맺는 일시적인 시점에 B로 이동할 수 있는 경로가 존재한다.
조영호님 과 토비님은 Dependency Injection에
의존관계 주입 이라는 용어를 사용하는 것을 추천합니다. 일반적으로 일컬어지는 의존성(클래스 의존성, 패키지 의존성)의 개념과 클래스 의존성의 한 종류인 의존관계를 구분하자는 의미입니다. 하지만 통상적으로 의존성이라는 용어가 널리 활용되고 있기는 합니다. 의존성, 의존관계란 변경에 의한 영향의 전파 가능성을 암시합니다.
MemberService 는 MemberRepo 에 의존한다. ==
MemberRepo 의 변경은 MemberService에 영향을 줄 수 있다.Object 8장 의존성 관리하기 01 - 의존성
- 유연하고 재사용 가능한 코드를 설계하기 위해서는 두 종류의 의존성을 서로 다르게 만들어야 한다.
- 런타임에는 컴파일 되지 않은 클래스 (채택되지 못한 interface/추상 class의 구현) 및 interface자체와 어떠한 의존성도 가지지 않는다.
- 반면 코드 작성시점에는 interface/추상 class 및 하부 모든 구현의 의존성을 고려하여야한다.
- 클래스 사이에 의존성을 두지 않고 interface/추상 class를 통하여 구체적인 class단위의 협력 단위는 런타임에 결정되도록 설계하라.
- 컨텍스트 독립성을 고려하라. 자신이 다른 객체에 보낼 메세지가 구체적으로 어느 클래스에 전송될지 고려하면 안됨.
의존성 해결의 세가지 방식
- 객체를 생성하는 시점에 생성자를 통해 의존성 해결
Movie avatar = new Movie("아바타", new AmountDiscountPolicy(...));- 객체 생성 후 setter 메서드를 통해 의존성 해결
avatar.setDiscountPolicy(new AmountDiscountPolicy(...);- 메서드 실행 시 인자를 이용해 의존성 해결( ~ strategy pattern)