IoC, DI는 무엇이고 어떠한 장점이 있을까?

IoC(Inversion of Control; 제어의 역전)

좋은 객체지향 설계를 위한 방법 중 하나로 프로그램의 제어 흐름을 개발자가 아닌 프레임워크나 컨테이너가 관리하는 것을 의미한다.

개발자가 프로그램의 흐름을 직접 관리하는 것이 아니라 외부 소스(프레임워크나 컨테이너)로부터 제어 흐름을 받는 방식으로 작동하며 대표적으로 스프링(Spring), Nest.js, Django 등과 같은 프레임워크가 있다.

 

 

프레임워크와 라이브러리의 차이를 설명할 때 핵심적인 내용이 바로 IoC이다

 

 

라이브러리는 개발자가 직접  원하는 시점에 해당 기술을 호출하여 사용하기 때문에 개발자가 제어권을 가지고 애플리케이션을 개발한다

하지만 프레임워크는 개발자가 프레임워크라는 구조 안에서 요구하는 대로 프로그램을 구성하기 때문에 제어 흐름의 주체가 개발자가 아닌 프레임워크로 역전된다.

 

 

좋은 객체 지향의 설계 원칙(SOLID)에서 역할과 구현을 분리하기 위해 지켜야할 매우 중요한 요소인 OCP(개방 폐쇄 원칙)과 DIP(의존관계 역전 원칙)이 있는데, 이를 지키기 위한 핵심적인 개념이 IoC이다

---

DI(Dependency Injection; 의존성 주입)

DI는 IoC를 구현하는 방법 중 하나로 객체가 자신의 의존성을 직접 생성하지 않고 외부에서 주입받는 방식을 의미한다

이러한 방식을 통해서 객체간의 결합도를 낮추고 코드의 유연성과 테스트 용이성을 높일 수 있어 유지보수성도 높여준다

 

 

코드에 작성된 정적인 의존관계가 아니라 애플리케이션 실행 시점에 실제 생성된 객체(인스턴스)의 의존관계에서 연결되는 것을 말하는데, 객체 인스턴스를 생성하고 그 참조값을 전달해서 연결한다

DI를 사용하면 클라이언트 코드를 변경하지 않고 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있기 때문에 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다

 

 

정적인 코드에 의존관계가 나타나있는 예시이다

public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository = new MemoryMemberRepository();
//      private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
        private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
        // ... 이하동일

}

 

 

아무리 다형성을 활용해도 구현체를 바꾸게 되면 비즈니스 로직을 관리하는 클라이언트 코드의 수정은 불가피하다.

 

아래의 코드처럼 역할과 구현을 분리하여 애플리케이션 전체를 설정하고 구성하는 클래스인 AppConfig를 생성하여 여기에서 객체를 생성하여 참조를 통해 연결하는 역할을 맡긴다

// 애플리케이션 전체를 설정하고 구성하는 클래스를 생성
public class AppConfig {

    // 생성자 주입 메서드
    public MemberService memberService() {
    	// 생성한 객체의 참조를 생성자를 통해 연결
        return new MemberServiceImpl(new MemoryMemberRepository());
    }
    public OrderService orderService() {
        return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
    }
}

 

 

이렇게 되면 클라이언트 코드에서는 구현체를 직접 구현하지 않고 인터페이스만 의존하게 되어 DIP 원칙이 지켜지게 된다

즉, 클라이언트 클래스는 의존관계에 대한 고민은 외부에 맡기고 실행(역할)에만 집중하게 되어 역할과 구현이 분리하는 설계가 된다

public class OrderServiceImpl implements OrderService {

private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

 

이렇게 AppConfig를 사용해서 직접 객체를 생성하고 생성자를 통해 의존관계를 주입하는 것을 스프링 프레임워크를 사용하면 매우 편리하게 역할과 구현을 분리할 수 있게 된다

---

스프링이 제공하는 DI 컨테이너

스프링이 제공하는 DI 컨테이너는 최상위 인터페이스에 BeanFactory가 있고 이를 상속받은 ApplicationContext가 있는데 애플리케이션을 개발할 때는 Bean을 관리하고 조회하는 등의 부가기능이 필요한 ApplicationContext를 사용하여 이를 구현하는 AnnotationConfigApplicationContext, GenericXmlApplicationContext 등이 존재한다

 

 

@Configuration이 붙은 클래스를 설정(구성) 정보로 사용하고 @Bean이 붙은 메서드를 호두 호출해서 반환된 객체를 스프링 컨테이너에 등록하여 관리한다.

 

스프링 컨테이너에 등록된 객체를 스프링 빈이라하며 @Bean이 붙은 메서드의 이름을 스프링 빈의 이름으로 사용한다

 

 

스프링 기반으로 변경한 AppConfig 클래스의 예시

@Configuration
public class AppConfig {

    @Bean // 메서드의 이름 = 스프링 빈의 이름
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    ...
}

 

싱글톤으로 관리되는 스프링 빈

스프링의 DI 컨테이너는 싱글톤 디자인 패턴으로 관리 되기 때문에 DI 컨테이너에 등록된 빈은 애플리케이션에서 딱 1개만 생성되어 이를 공유해서 사용하게 된다

즉, 등록된 빈을 공유해서 사용하기 때문에 스프링 빈은 무상태로 설계 되어야 사이드 이펙트를 막을 수 있다

 

 

스프링 컨테이너는 스프링 빈이 싱글톤으로 보장하기 위해 특별한 기술을 사용하는데 CGLIB라는 바이트 코드를 조작하는 라이브러리를 사용(프록시 패턴을 적용)하여 @Configuration 애노테이션이 붙은 설정 클래스의(예시: AppConfig)빈들을 싱글톤으로 보장되게 해준다

 

 

그래서 @Configuration 없이 @Bean 애노테이션만으로 빈을 등록하면 싱글톤 빈으로 등록되지만 CGLIB를 사용하지 않기 때문에 의존관계 주입을 위해 메서드를 직접 호출해야 하고, 메서드를 직접 호출하면 매번 새 객체가 생성되어 싱글톤이 깨지게 된다

그러므로 설정 정보는 항상 @Configuration을 사용해야 한다

 

자동 주입

의존관계는 스프링이 제공하는 기능을 통해 자동으로 주입하거나 직접 작성하여 수동으로 주입할 수 있는데, 같이 사용한다면 수동 으로 등록한 빈이 우선순위를 가지게 된다

또한 최근의 스프링 버전에선 자동으로 주입하는 빈의 이름이 중복되어 충돌되면 오류가 발생하도록 기본 설정되어있다(설정으로 바꿀 수 있긴하다)

 

 

스프링 빈을 자동으로 주입하기 위해서는 @Component와 @ComponentScan이라는 애노테이션을 사용할 수 있는데, 스프링 빈으로 등록할 클래스에 @Component를 추가해주면 @ComponentScan 애노테이션이 붙은 클래스의 패키지부터 하위 패키지를 모두 스캔하여 @Component가 붙은 클래스를 모두 빈으로 등록한다

 

 

그 외에도 @Controller, @Service, @Repository, @Configuration 애노테이션이 붙은 클래스도 모두 등록되는데 애노테이션 내부를 들어가보면 모두 @Componenet가 붙어있기 때문이다.

 

 

@ComponentScan은 다양한 옵션을 설정할 수 있는데, 스캔 범위 대상을 직접 지정할 수도 있고 제외할 대상을 지정하는 옵션을 지정할 수 있다.

 

 

보통은 패키지 위치를 지정하지 않고 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 방법을 사용하는데, 스프링 부트로 프로젝트를 생성하면 생성되는 Application 클래스에 @SpringBootApplication 애노테이션이 붙어있다

 

 

여기에 @ComponentScan이 붙어있어 특별한 경우가 아니면 직접 @ComponentScan을 사용할일이 없고 제외할 대상을 지정하는 옵션을 활용하여 등록되지 않아야할 부분들을 제거하면 된다

 

 

의존관계를 주입 하는 방법은 생성자 주입, 수정자 주입(setter) 필드 주입, 일반 메서드로 주입하는 방식이 있는데 기본적으로 생성자 주입을 제외하고는 대부분 사용하지 않거나 사용하지 않아야 한다

 

 

생성자 주입 예시

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired // 생략해도 의존관계가 자동으로 주입이 됨
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

 

생성자를 통해서 의존관계를 주입하는 방법으로 행성자 호출 시점에 딱 1번만 호출되는 것이 보장되어 불변, 필수 의존관계에 사용된다

생성자가 딱 1개만 있으면 @Autowired를 생략할 수 있다.

 

 

생성자 주입을 제외한 나머지 주입 방식은 모두 생성자 이후에 호출이 되기 때문에 필드에 final 키워드를 사용할 수 없는데, 생성자 주입은 주입 대상인 필드에 final 키워드를 사용할 수 있어 주입 해야 할 대상을 실수로 누락하면 컴파일 시점에서 바로 오류가 발생하기 때문에 개발 시점에 오류를 바로 잡을 수 있는 장점이 있다

 

 

롬복 라이브러리의 @RequiredArgsConstructor 애노테이션을 사용하면 final 키워드나, @NonNull 애노테이션이 붙은 필드를 모아서 생성자를 자동으로 만들어 준다

 

 

아래의 코드처럼 주입하고자 할 대상의 필드에 final 키워드를 붙여주고 컴포넌트 스캔의 대상인 클래스에 롬복이 제공하는@RequiredArgsConstructor를 사용하면 생성자 주입 전체를 모두 생략할 수 있어 이 방법이 거의 기본으로 사용된다

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

}

 

build.classes에 컴파일된 클래스를 열어보면 생성자 코드가 추가되어있는 것을 확인할 수 있다.

정리

스프링이 나오고 시간이 갈 수록 점점 자동으로 스프링 빈을 등록하는 방법을 자주 사용하며 특별한 경우에만 수동으로 빈을 등록하여 사용한다.

애플리케이션에 광범위하게 영향을 미치는 기술을 지원하는 객체는 수동으로 빈을 등록하여 설정 정보에 바로 나타나게 하는 것이 유지 보수에 좋다고 한다.

공통 관심사(AOP)를 활용하거나 다형성을 적극 활용하는 비즈니스 로직들을 예를 들 수 있는데, 자동으로하든 수동으로 하든 이런 설정 클래스들은 특정 패키지에 묶어서 설정 클래스들이 모아져있다는 것을 한눈에 보고 이해할 수 있도록 해야 파악하기도 좋고 유지보수하기에 좋다