[TIL #20] 의존관계 주입 DI 와 제어의 역전 IoC

// 주문 비즈니스 로직
public class OrderServiceImpl implements OrderService {

// 할인 정책 객체 생성
private final DiscountPolicy discountPolicy = new RateDiscountPolicy();

}

기존 코드는 다음과 같이 서비스 클래스에서 직접적으로 할인 정책에 대한 구현 클래스는 직접적으로 객체를 생성해서 넣어주고 있다.

이것은 직전에 공부했던 `DIP`(추상화에 의존하며 구체화에 의존하면 안된다)와 만약 할인 정책이 변경된다고 하면 새로운 구현 클래스를 만들어 해당 코드를 변경해야 하는데 이것은 `OCP`(확장에는 열려있지만 변경에는 닫혀있어야한다)를 위반하는 것이다.

 

그렇다면 `DIP`와 `OCP`를 모두 만족시키려면 어떻게 해야할까?

 

public class AppConfig {
	public OrderService orderService() {
		return new OrderServiceImpl(new FixDiscountPolicy());
	}
}

 

다음과 같이 새로운 `Config` 클래스를 생성해서 여기서 `orderService`로 구현 클래스를 주입해준다. `Config` 는 앱 내에서 설정과 같은 기능을 담당한다. 이러면 `DIP`는 자연스럽게 만족이 되며, 만약 할인 정책이 변경된다고 해도 service 클래스는 자체는 건드릴 게 아예 없고 `Config` 에서 변경해주면 되기 때문에 `OCP` 또한 만족하게 된다.

위와 같이 실행 시점에 외부에서 실제 구현 클래스를 생성하고 서비스에 전달해서 실제 의존관계가 연결 되는 것을 의존관계 주입 DI(Dependency Injection)이라고 한다.

 

여기서 원래는 구현 클래스가 직접적으로 필요한 구현 클래스를 생성하고 실행하는 흐름이였는데 AppConfig가 프로그램 제어에 대한 권한을 가져가면서 구현 클래스는 본인의 로직만 실행하는 것으로 바뀌었다.

 

이렇게 프로그램 제어의 흐름을 구현 객체에서 직접 하는 것이 아니라 외부에서 관리하는 것을 제어의 역전 IoC(Inversion of Control)이라고 한다. 요즘 가정에서 IoT(Internet of Things) 시스템을 적용하면서 불을 끄고 키고, 커튼을 열고 닫고, 전자기기를 끄고 키는 등 사물을 제어하는 것을 직접적으로 하는 게 아니라 모두 인터넷으로 연결해서 하나의 컨트롤러 안에 제어를 하는 데 뭔가 비슷한 개념처럼 보인다. (단어는 다르지만 IoC IoT 스펠링도 비슷하고...)