📋 DI(Dependency Injection)란?

의존성 주입(DI)란 무엇을 뜻 하는가?
의존성 주입은 스프링 프레임워크의 핵심 기술 중 하나로써, 객체 간에 의존성(객체 간의 연결관계)을 객체 내부에서 직접 호출하는 대신, 외부(스프링 IoC 컨테이너를 이용함)에서 객체를 생성해서 넣어주는 방식 쉽게 말하자면 용도에 맞게 필요한 객체를 그냥 가져다 사용하는 것이다. 이 객체들이 어떻게 만들어졌는지는 알 필요가 없는 것이다. 예를 들어 장난감의 배터리를 바꾸는 것과 같이 필요할 때 가져다가 사용하는 것이다. 이로 인해 코드가 간결해지면서 객체간의 결합도를 낮춰주며 동시에 확장성을 증가 시켜준다.
그럼 이때 드는 의문점은 스프링에서는 모든 객체를 주입할 수 있는것인지, 언제 객체를 생성하는지, 그리고 어디에 생성된 객체들이 존재하는 것이다. 그리고 어떻게 이 생성된 객체들이 주입이 되는 것이다.

🤔의문점 1 : 스프링에서는 모든 객체를 주입할 수 있다??

: 일단 결론은 아니다. 스프링에서는 bean 으로 등록된 객체이거나 스프링이 스캔한 객체들만 의존성 주입이 가능 하다는 것이다. 여기서 bean 은 스프링이 관리하는 객체이다.
bean으로 등록되지 않은 객체는

public class Car1 {
    private BatteryA batteryA = new BatteryA(100, "Energizer"); 
}

이렇게 뒤에 "new ~~" 를 작성해서 클래스 내부에서 직접 생성하여 관리를 하였지만,
반면에, bean으로 등록되거나 스프링이 스캔한 객체는

public class Car1 {
    private BatteryA batteryA;
}

내부에서 생성될 필요없이 간단하게 주입해서 사용이 가능하다는 것이다!
그럼 언제 스프링은 객체들을 생성하는 것일까?

🤔의문점 2 : 언제 bean 객체들이 생성이 되지?

: 간단하게는 스프링 프로젝트가 시작될 때, 스프링이 bean 객체나 어노테이션이 붙은 객체들을 스캔하여서 생성한다. 조금 더 깊게 파고 들면 Bean Application Context가 시작 될때 이다. Application Context관련해서는 나중에 조금 더 깊게 파보자. 일단은 스프링 프로젝트가 시작될 때 생성되는 것이라고 알고 있으면 되겠다.
그럼 어떻게 스프링은 bean 객체들을 주입해줄까?

🤔의문점 3 : 어디에 생성된 객체들이 존재하는 것이지?

: 스프링에는 bean 객체들이 담겨져 있는 IoC(Inversion of Control) 컨테이너라는 것이 있다. 생성된 bean 객체들을 스프링 IoC 컨테이너 담겨져 있는 것이다. 그 후, 여기에 있는 bean 객체들을 필요한 객체들에 주입을 해주는 것이다.
그럼 여기서 마지막 의문점은 어떻게 bean 객체들을 주입을 해주는 것이다.

🤔의문점 4 : 어떻게 bean 객체들을 주입을 해주지?

: 이제 여기서 위에서 언급한 DI 라는 개념이 나온다.
스프링에서 DI를 하는 방법은 총 3가지가 있다. 생성자 주입, setter/수정자 주입, 그리고 필드 주입이 있다.

📍3가지 DI 방법

1. 생성자 주입 (Constructor Injection)
   = 해당 객체에 주입되어야 하는 객체를 해당 객체 생성자 파라미터로 정해둔다. 그러면 해당 객체가 생성될 때, 스프링이 해당 객체 생성자의 파라미터를 확인해서 스프링 IoC 컨테이너에 bean 객체를 확인하고 주입해준다. 이 방법은 가장 많이 쓰이는 방법으로써 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우에 사용할 수 있다. 또한 Spring 프레임워크에서는 생성자 주입을 적극 지원하고 있기 때문에, 생성자가 1개만 있을 경우에 @Autowired를 생략해도 주입이 가능하도록 편의성을 제공하고 있다. 그리고 스프링 공식문서는 생성자 주입 사용을 권장한다.

public class Car1 {
    private BatteryA batteryA;
    @Autowired  //생성자가 하나 일때는 생략 가능
    public Car1(BatteryA batteryA) {
        this.batteryA = batteryA;
    }
}

2. 수정자 주입(Setter 주입, Setter Injection)
   = 해당 객체에 선택적으로 주입되는 객체를 setter 메서드의 파라미터로 정해둔다. 그 후, 상황에 맞게 setter 메서드를 호출하면 스프링이 파라미터를 확인해서 스프링 IoC 컨테이너에 bean 객체를 확인하고 주입해준다. Setter 주입은 생성자 주입과 다르게 주입받는 객체가 변경될 가능성이 있는 경우에 사용한다.

public class Car1 {
    private BatteryA batteryA;
    @Autowired //생략 가능하다. 
    public void setBatteryA(BatteryA batteryA) {
        this.batteryA = batteryA;
    }
}

3. 필드 주입(Field Injection)
   = 해당 객체에 주입되어야하는 객체를 선언 한후 @Autowired 어노테이션을 붙인다. 해당 객체가 생성될 때, 스프링이 @Autowired 어노테이션이 붙은 필드를 확인 한 후 스프링 IoC 컨테이너에 bean 객체를 확인하고 주입해준다. 이 주입은 코드가 간결해져서 과거에 상당히 많이 이용되었던 주입 방법이다. 하지만 필드 주입은 외부에서 접근이 불가능하다는 단점이 존재하는데, 테스트 코드의 중요성이 부각됨에 따라 필드의 객체를 수정할 수 없는 필드 주입은 거의 사용되지 않게 되었다. 또한 필드 주입은 반드시 DI 프레임워크가 존재해야 하므로 반드시 사용을 지양해야 한다.

public class Car1 {
    @Autowired
    private BatteryA batteryA;
}

📍생성자 주입 사용 권장 이유

위에서 언급했듯이, 스프링 공식 문서는 생성자 주입 사용을 권장한다. 공식 문서는 이렇게 작성 되어있다

"Spring 팀은 일반적으로 생성자 주입을 지지합니다. 이는 애플리케이션 구성 요소를 불변 객체로 구현하고 필요한 의존 객체가 null이 아님을 보장하기 때문입니다. 또한 생성자가 주입한 구성 요소는 항상 완전히 초기화된 상태에서 클라이언트(호출) 코드로 반환됩니다."

• 생성 될때 주입이 된다.
  해당 객체가 생성 될 때 부터 필요한 객체들이 주입된다. 이는 생성자가 필요한 모든 객체가 주입되지 않으면 해당 객체가 생성되지 않을 것이라고 100% 확신할 수 있다. 또한 필요한 모든 객체가 주입되었는지 확인하기 위한 별도의 코드를 작성할 필요가 없으므로 매우 유용하므로 코드 복잡성을 단순화한다.

public class Car1 {
    private BatteryA batteryA;
    private BatteryB batteryB;
    public Car1(BatteryA batteryA, BatteryB batteryB) {
        this.batteryA = batteryA;
        this.batteryB = batteryB;
    }
}

위의 코드에서 batteryA는 bean 객체이고 batteryB는 bean 객체가 아니다. 이때, Car1 객체를 생성하려 할때, 에러가 난다. 이는, 객체가 생성이 될때 생성자 파라미터의 객체들이 주입이 되는데 batteryB는 bean 객체가 아니기 때문에 나는 에러이다.

• 코드 냄새 식별
  주입 되어야하는 모든 객체들을 쉽게 알 수 있다. 이로 인해, 해당 객체가 많은 다른 객체들에게 의존 하는지 알 수 있다. 만약 의존 하는 객체가 많다면 해당 객체가 많은 책임감을 가지고 있는 것을 뜻하면서 이는 나쁜 코드 냄새라고 할 수 있다.

public class Car1 {
    private BatteryA batteryA;
    private BatteryB batteryB;
    private Window window;
    private Tire tire;
    private Wheel wheel;
    private Engine engine;
    public Car1(BatteryA batteryA, BatteryB batteryB, 
                Window window, Tire tire, Wheel wheel, Engine engine) {
        this.batteryA = batteryA;
        this.batteryB = batteryB;
        this.window = window;
        this.tire = tire;
        this.wheel = wheel;
        this.engine = engine;
    }
}

위의 코드 처럼 생성자에서 얼마나 많은 객체들이 주입이 되어져야하는지 알 수 있다.

• 테스트 코드 작성 용이
  생성자 주입은 필요한 객체들을 생성자에 명시하여서 해당 객체를 테스트할 때 필요한 의존 객체들을 Mockito를 사용해 쉽게 모의 구현 할 수 있다. 또한, 이는 단위 테스트의 제어 및 격리를 개선해준다.

public class Car1 {
    private BatteryA batteryA;
    public Car1(BatteryA batteryA) {
        this.batteryA = batteryA;
    }
    public String CarHasBattery(){
        return "BROOM BROOM";
    }
}

예를 들어 위가 Car1에 대한 코드이면,

class Car1Test {
    @Mock
    BatteryA batteryA;
    @Test
    void CarTest(){
        Car1 car1 = new Car1(batteryA);
        assertEquals("BROOM BROOM", car1.CarHasBattery()); //Success
    }
}

위에 처럼 테스트 코드를 주입되어야하는 객체를 Mock으로 쉽게 생성 후 작성 할 수 있다.

• 불변성
  생성자 주입으로 주입받은 객체가 불변하다는 장점을 가지고 있다. 이는, NullPointerException을 방지 할 수 있다. 또한, 내부 상태 변화로 인한 버그에 덜 취약하다는 것이다.