Spring DI

 

✅  DI 필요성

 

우선 "의존성(Dependency)"의 의미에 대해 간단히 정리해보자면,

 

클래스 간 의존성이 있다

 = 한 클래스가 다른 클래스의 기능을 사용한다

 = 한 클래스가 바뀌면 다른 클래스도 영향을 받는다

 = 한 클래스는 다른 클래스의 변경으로부터 자유롭지 않다

 

정도로 정리할 수 있겠다.

 

---

 

좋은 객체지향 설계 원칙(SOLID) 중

DIP(Dependency Inversion Principle, 의존성 역전 원칙)는 바로 이 의존성에 대해 이야기한다.

 

 - 구체에 의존한 경우: 추상 인터페이스에 변경이 생기면, 이것을 구체화한 구현체들도 수정해야 한다.

 - 추상에 의존한 경우: 그러나 구현체에 변경이 생기더라도, 인터페이스는 변경될 필요가 없다.

 

따라서 구체가 아닌 추상에 의존해야, 유연하고 확장성이 좋은 시스템을 설계할 수 있다.

 

즉 DIP를 따르려면 구체적 요소에 대한 의존은 피하고, 추상화(인터페이스)에 의존해야 한다.

 

 

의존관계 역전을 구현하는 방법 중 하나로 의존성 주입(DI, Dependency Injectcion)가 있다.

 

---

 

의존성 주입(DI, Dependency Injection)이란,

이러한 의존성을 "외부"에서 주입시켜 주는 것을 말한다.

 

의존성을 외부에서 주입시켜주면,

각 클래스는 자신의 기능만을 실행하고, 자신과 다른 클래스와의 의존성에 대해서는 더이상 신경 쓰지 않게 된다.

다시 말해, 의존성이 있는 클래스끼리는 서로의 변경으로부터 자유로워지게 된다.

 

 

✅ Spring DI

 

0️⃣ DI 없이 구현한 코드

@Controller
public class ProductController {

    ProductService productService = new ProductService();
    
}

 

 - ProductController가 ProductService를 직접 생성하고, 의존성도 직접 주입한다.

 - 만약 ProductService에 변경이 생기면, ProductController의 코드까지 변경해주어야 한다.

 - 두 클래스 간의 결합도가 높아서, 확장성과 유연성은 떨어지게 된다.

 

---

 

우리는 클래스 간 결합도가 낮고, 확장성과 유연성이 높은 코드를 작성해야 한다.

 

그러기 위해서 클래스 간 의존도를 외부에서 주입해주도록, DI를 구현해야 한다.

 

우리는 @Autowired 라는 어노테이션을 사용하여, 스프링 프레임워크에게 의존성을 주입해달라고 요청할 수 있다.

 

 - 이때 의존성을 주입받는 객체는 스프링 빈으로 등록되어 있어야 한다.

 

Spring DI 구현 방법에는 크게 필드 주입, Setter 주입, 생성자 주입 이 있다.

 

---

 

1️⃣ 필드 주입 (Field Injection)

 

@Controller
public class ProductController {

    @Autowired
    private ProductService productService;

}

 - 간단하게 주입받고자 하는 필드 선언부에 @Autowired 어노테이션만 붙여주면 된다.

 

 - 의존성이 외부에서 어떻게 주입되는지 명확히 드러나지 않는다는 단점이 있다.

    위 코드만 보고는 ProductService가 어떻게 생성되고, 주입되는지 알 수 없다.

    이로 인해 코드의 확장이나 테스트, 유지보수의 어려움이 생길 수 있다.

   

---

 

2️⃣ Setter 주입 (Setter Injection)

 

@Controller
public class ProductController {

    private ProductService productService;
    @Autowired
    public void setProductService(ProductService productService){
        this.productService = productService;
    }

}

 - Setter를 정의하고, 그 위에 @Autowired 어노테이션을 붙여준다.

 

 - Runtime에 의존성을 선택해야 하는 경우, Runtime에 의존성을 변경해야 하는 경우 유용하다.

 

 - 의존성을 주입할 필드는 final로 선언할 수 없어서, 객체의 불변을 보장할 수 없다.

 

 - Setter를 통해 의존관계 주입을 하지 않아도 객체 생성은 가능하다는 단점이 있다.

    만약 객체 생성만 해두고 그 구현체를 Setter를 통해 주입해주지 않는다면 NullPointerException이 발생할 수 있다.

 

---

 

3️⃣ 생성자 주입 (Constructor-based DI)

 

@Controller
public class ProductController {

    private final ProductService productService;
    @Autowired
    public ProductController(ProductService productService){
        this.productService = productService;
    }

}

 - constructor를 정의하고, 그 위에 @Autowired 어노테이션을 붙여준다.

 

 - 객체 생성 시점에 스프링이 의존성을 주입해준다.

 

 - 객체 의존성 주입이 필수인 경우에만 객체를 생성할 수 있으므로, NullPointerException을 방지할 수 있다.

 

 - 객체를 final로 선언하여 객체가 최초 주입된 이후 변하지 않도록 할 수 있다. (의존관계 불변성 O)

 

---

 

#️⃣ 셋 중 어떤 주입을 사용하는 것이 좋을까?

 

 - 결론부터 말하면 생성자 주입을 사용하는 것이 가장 권장되는 사항이다.

 

 - 생성자 주입만이 객체의 불변성을 보장할 수 있다.

 

 - 생성자 주입만이 NullPointerException을 방지할 수 있다.

 

 - 생성자 주입을 사용하면, 생성자 매개변수를 통해 어떠한 의존성이 필요한지 명확히 드러난다.

 

 

 - (참고) 생성자 주입만의 장점이었던 것: 순환 참조 방지

 

         이전까지는 생성자 주입만이 순환 참조를 방지할 수 있다는 것이 생성자 주입만의 큰 장점이었다.

         필드 주입과 setter 주입과는 달리, 생성자 주입을 사용하면 컴파일러가 순환 참조 발생시 에러를 띄워주었기 때문이다.

         그러나 스프링부트2.6 부터는 이 부분이 패치되어, 3가지 방식 모두 순환 참조 발생 방지가 된다고 한다.

 

순환 참조란 , 두 클래스가 서로를 참조하는 상황을 말한다.

 

예를 들면 클래스 A는 클래스 B를 참조하고, 클래스 B는 클래스 A를 참조하는 경우를 생각해보자.

클래스 A의 인스턴스를 생성하려면 클래스 B의 인스턴스가 필요하고, 클래스 B의 인스턴스를 생성하려면 클래스 A의 인스턴스가 필요한 경우이다.

 

 

---

 

✅  Reference

 

 

• 클린 아키텍처 (2019, Rober C. Martin)

 

• https://velog.io/@gillog/Spring-DIDependency-Injection-%EC%84%B8-%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95
• https://www.youtube.com/watch?v=8lp_nHicYd