AppConfig, IoC, DI

위와 같은 의존관계가 있을때 DiscountPolicy 인터페이스에 대한 구현체로 FixDiscountPolicy를 사용하다가 RateDiscountPolicy로 변경하려고 한다. 이때 아래의 코드와 같이 구현을 했다고 가정한다.

public class OrderServiceImpl implements OrderService {
  //    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
      private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
  }

역할과 구현을 나누어서 다형성도 활용하였다. 그러나 OCP, DIP 같은 객체지향 설계 원칙은 지켜지지 못했다.

 

OrderServiceImpl는 DiscountPolicy 인터페이스를 의존함과 동시에 FixDiscountPolicy 구현 클래스 또한 의존하고 있었고 이것은 DIP 위반, Fix -> Rate로 코드를 변경하는 순간 OrderServiceImpl의 소스코드 또한 함께 변경이 되어야하기 때문에 OCP 위반도 하게된다.

실제로 설계되어 있었던 상태(DIP, OCP 위반)

이것을 해결하기 위해선 인터페이스에만 의존하도록 설계를 변경해주어야 한다.

 

public class OrderServiceImpl implements OrderService {
      private DiscountPolicy discountPolicy;
}

인터페이스에만 의존하도록 설계를 변경했다. 그렇지만 구현체가 없기때문에 코드가 실행되지 않는다. 이 문제를 해결하기 위해선 무언가가 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하여 주입해주어야 한다.

 

여기서 Appconfig가 등장한다.

 

애플리케이션의 전체 동작방식을 구성하고, 구현할 객체를 생성, 연결하는 별도의 설정클래스(AppConfig)를 만든다.

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

public class OrderServiceImpl implements OrderService {
      private final DiscountPolicy discountPolicy;
      public OrderServiceImpl(DiscountPolicy discountPolicy) {
          this.discountPolicy = discountPolicy;
      }
}

AppConfig는 생성한 객체 인스턴스의 참조를 생성자를 통해서 주입(연결)시켜준다. 이렇게 되면 OrderServiceImpl는 DiscountPolicy 인터페이스만 의존하게되고, 생성자를 통해 어떤 구현 객체가 주입(연결)되는지 알 수 없다. (예시에서는 FixDiscountPolicy() 주입) 어떤 구현 객체가 주입할지는 오직 외부(AppConfig)에서 결정할 수 있게되고, 역할과 구현 클래스가 한눈에 들어온다. OrderServiceImpl는 실행에만 집중하면 된다. 이렇게하여 DIP 원칙을 위반하지 않으면서 역할과 구현을 명확하게 분리하였고, 이 과정을 스프링에서 가장 중요한 개념 중 하나인 DI(Dependency Injection) 의존관계 주입 또는 의존성 주입이라 한다.

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다.

 

AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다. 심지어 OrderServiceImpl 도 AppConfig가 생성한다. 그리고 AppConfig는 OrderServiceImpl이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수 도 있다. OrderServiceImpl은 자신의 로직을 실행할 뿐이다. 이렇게 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC, Inversion of control)이라 한다.

 

 

※ 스프링 핵심 원리 - 기본편(김영한)을 수강하고 정리한 글입니다. inf.run/2oxX

스프링 핵심 원리 - 기본편 - 인프런