📌 1. 의존성 주입(Dependency Injection, DI)의 개념

---

📎 의존성 주입이란?

Spring 프레임워크는 3가지 핵심 프로그래밍 모델을 지원하고 있는데, 그 중 하나가 의존성 주입(Dependency Injection, DI)이다.

DI란, 외부에서 두 객체 간의 관계를 결정해주는 디자인 패턴으로, 객체를 직접 생성하는 것이 아니라 외부에서 생성한 후 주입 시켜주는 방식이다.

위사진에서 보는 것 처럼 첫번째 방법은 A객체가 B와 C객체를 New 생성자를 통해서 직접 생성하는 방법이고,

두번째 방법은 외부에서 생성된 객체를 setter()를 통해 사용하는 방법이다.

두번째 방식이 의존성 주입의 예시인데, A객체에서 B,C객체를 사용(의존)할때 A객체에서 직접 생성 하는 것이 아니라 외부(IOC컨테이너)에서 생성된 B, C객체를 조립(주입)시켜 setter 혹은 생성자를 통해 사용하는 방식이다.

스프링에서는 객체를 Bean이라고 부르며, 프로젝트가 실행될때 사용자가 Bean으로 관리하는 객체들의 생성과 소멸에 관련된 작업을 자동적으로 수행해주는데 객체가 생성되는 곳을 스프링에서는 Bean 컨테이너라고 부른다.

📎 의존성 주입 장점 9가지

1. 재사용성을 높여준다.
2. 테스트에 용이하다.
3. 코드를 단순화 시켜준다.
4. 종속적이던 코드의 수도 줄여준다.
5. 왜 사용하는 지 파악하기가 수월하다. 코드를 읽기 쉬워지는 점이 있다.
6. 종속성이 감소한다. 구성 요소의 종속성이 감소하면, 변경에 민감하지 않다.
7. 결합도(coupling)는 낮추면서 유연성과 확장성은 향상시킬 수 있다.
8. 객체간의 의존관계를 설정할 수 있다.
9. 객체간의 의존관계를 없애거나 줄일 수 있다.
   
   
   

📌 2. 의존성 주입 구체적 예시

---

📎 의존성주입의 예시

예를 들어 다음과 같이 Store 객체가 Pencil 객체를 사용하고 있는 경우에 우리는 Store객체가 Pencil 객체에 의존성이 있다고 표현한다.

public class Pencil {

}

public class Store{

    private Pencil pencil;

    public Store() {
      this.pencil = new Pencil();
    }

}

📎 의존성주입이 필요한 이유

하지만 위와 같은 예시 클래스는 크게 2가지 문제점을 가지고 있다.

👉 두 클래스가 강하게 결합되어 있다.

Store 클래스는 현재 Pencil 클래스와 강하게 결합되어 있는 문제점을 가지고 있다. 두 클래스가 강하게 결합되어 있어서 만약 Store에서 Pencil이 아닌 Food와 같은 다른 상품을 판매하고자 한다면 Store 클래스의 생성자에 변경이 필요하다. 즉, 유연성이 떨어진다. 각각의 다른 상품들을 판매하기 위해 생성자만 다르고 나머지는 중복되는 Store 클래스들이 파생되는 것은 좋지 못하다. 이에 대한 해결책으로 상속을 떠올릴 수 있지만, 상속은 제약이 많고 확성이 떨어지므로 피하는 것이 좋다.

👉 객체들 간의 관계가 아니라 클래스 간의 관계가 맺어지고 있다.

또한 위의 Store와 Pencil는 객체들 간의 관계가 아니라 클래스들 간의 관계가 맺어져 있다는 문제가 있다. 올바른 객체지향적 설계라면 객체들 간에 관계가 맺어져야 하지만 현재는 Store 클래스와 Pencil 클래스가 관계를 맺고 있다. 객체들 간에 관계가 맺어졌다면 다른 객체의 구체 클래스(Pencil인지 Food인지 등)를 전혀 알지 못하더라도, 인터페이스의 타입(Product)으로 사용할 수 있다.

📎 의존성주입을 통한 문제 해결

👉 위와 같은 문제를 해결하기 위해서는 우선 다형성이 필요하다. Pencil, Food 등 여러 가지 제품을 하나로 표현하기 위해서는 Product라는 Interface가 필요하다. 그리고 Pencil에서 Product 인터페이스를 우선 구현해야한다.

public interface Product{

}

public class Pencil implements Product{

}

👉 다음은 Store와 Pencil이 강하게 결합되어 있는 부분을 제거해주어야 한다. 이를 제거하기 위해서는 다음과 같이 외부에서 상품을 주입(Injection)받아야 한다.

public class Store{

   private Product product;

   public Store(Product product) {
      this.product = product;
   }

}

👉 여기서 Spring이 DI 컨테이너를 필요로 하는 이유를 알 수 있는데, 우선 Store에서 Product 객체를 주입하기 위해서는 애플리케이션 실행 시점에 필요한 객체(빈)를 생성해야하며, 의존성이 있는 두 객체를 연결하기 위해 한 객체를 다른 객체로 주입시켜야 하기 때문이다. 예를 들어 다음과 같이 Pencil이라는 객체를 만들고, 그 객체를 Store로 주입시켜주는 역할을 위해 DI 컨테이너가 필요하게 된 것이다.

public class BeanFactory{

    public void store() {
      
      //Bean의 생성
      Product pencil = new Pencil();    
      
      //의존성 주입
      Store store = new Store(pencil);      

    }
}

👉 그리고 이러한 개념은 제어의 역전(Inversion of Control, IoC)라고 불리기도 한다. 어떠한 객체를 사용할지에 대한 책임이 BeanFactory와 같은 클래스에게 넘어갔고, 자신은 수동적으로 주입받는 객체를 사용하기 때문이다. (실제 Spring에서는 BeanFactory를 확장한 Application Context를 사용한다.)

📌 3. 다양한 의존성 주입 방법

---

📎 @Autowired란?

@Autowired는 의존성 주입을 할 때 사용하는 Annotation으로 생성자나 세터 등을 사용하여 의존성 주입을 하려고 할 때, 해당 빈을 찾아서 주입해준다. 또한, 의존 객체(Bean)가 2개 이상이면 오류를 발생시킨다. @Autowired를 통해 의존성 주입을 구현할 수 있는데, 4가지 방법으로 구현할 수 있다.

📎 의존성 주입 방법 (1): 생성자 주입(Constructor Injection)

👉 생성자 주입은 생성자를 통해 의존 관계를 주입하는 방법이다.

@Service
public class UserServiceImpl implements UserService{

   private UserRepository userRepository;
   private MemberService memberService;

   @Autowired
   public UserServiceImpl(UserRepository userRepository, MemberService memberService) {
     this.userRepository = userRepository;
     this.memberService = memberService;
   }

}

👉 생성자 주입은 생성자의 호출 시점에 1회 호출되는 것이 보장된다. 그렇기 때문에 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우에 강제하기 위해 사용할 수 있다. 또한 Spring 프레임워크에서는 생성자 주입을 적극 지원하고 있기 때문에, 생성자가 1개만 있을 경우에 @Autowired를 생략해도 주입이 가능하도록 편의성을 제공하고 있다. 그렇기 때문에 위의 코드는 아래와 동일한 코드가 된다.

@Service
public class UserServiceImpl implements UserService{

   private UserRepository userRepository;
   private MemberService memberService;

   public UserServiceImpl(UserRepository userRepository, MemberService memberService) {
     this.userRepository = userRepository;
     this.memberService = memberService;
   }

}

📎 의존성 주입 방법 (2): 수정자 주입(Setter 주입, Setter Injection)

👉 수정자주입은 필드 값을 변경하는 Setter를 통해서 의존 관계를 주입하는 방법이다. Setter 주입은 생성자 주입과 다르게 주입받는 객체가 변경될 가능성이 있는 경우에 사용한다. (실제로 변경이 필요한 경우는 극히 드물다.) @Autowired로 주입할 대상이 없는 경우에는 오류가 발생한다. 아래 예제에서는 XXX 빈이 존재하지 않는 경우에 오류가 발생하는 것이다. 주입할 대상이 없어도 동작하도록 하려면 @Autowired(required = false)를 통해 설정할 수 있다.

@Service
public class UserServiceImpl implements UserService{

   private UserRepository userRepository;
   private MemberService memberService;
   
   @Autowired
   public void setUserRepository(UserRepository userRepository) {
     this.userRepository = userRepository;
   }

   @Autowired
   public void setMemberService(MemberService memberSerive) {
      this.memberService = memberService;
   }

}

📎 의존성 주입 방법 (3): 필드 주입(Field Injection)

👉 필드주입은 필드에 바로 의존 관계를 주입하는 방법이다. IntelliJ에서 필드 인젝션을 사용하면 Field Injection is not recommended이라는 경고 문구가 발생한다.

@Service
public class UserServiceImpl implements UserService{

   @Autowired
   private UserRepository userRepository;
   @Autowired
   private MemberService memberService;

}

👉 필드 주입을 이용하면 코드가 간결해져서 과거에 상당히 많이 이용되었던 주입 방법이다. 하지만 필드 주입은 외부에서 변경이 불가능하다는 단점이 존재하는데, 점차 테스트 코드의 중요성이 부각됨에 따라 필드의 객체를 수정할 수 없는 필드 주입은 거의 사용되지 않게 되었다. 또한 필드 주입은 반드시 DI 프레임워크가 존재해야 하므로 반드시 사용을 지양해야 한다. 그렇기에 애플이케이션의 실제 코드와 무관한 테스트 코드나 설정을 위해 불가피한 경우에만 이용하도록 해야한다.

📎 의존성 주입 방법 (4): 일반 메소드 주입(Method Injection)

👉 일반 메소드를 통해 의존 관계를 주입하는 방법이다. 한번에 여러 필드를 주입 받을 수 있지만, 거의 사용할 필요가 없는 주입 방법이다.

📌 4. 생성자 주입을 사용해야 하는 이유

---

📎 이유(1): 객체의 불변성 확보

👉 실제로 개발을 하다보면, 의존 관계 주입의 변경이 필요한 상황은 거의 없다. 하지만 수정자 주입이나 일반 메소드 주입을 이용하면 불필요하게 수정의 가능성을 열어두게 되며, 이는 OOP의 5가지 개발 원칙 중 OCP(Open-Closed Principle, 개방-폐쇄의법칙)를 위반하게 된다. 그러므로 생성자 주입을 통해 변경의 가능성을 배제하고 불변성을 보장하는 것이 좋다.

📎 이유(2): 테스트 코드의 작성

👉 실제 코드가 필드 주입으로 작성된 경우에는 순수한 자바 코드로 단위 테스트를 작성하는 것이 불가능하다. 예를 들어 아래와 같은 실제 코드가 존재한다고 하자.

@Service
public class UserServiceImpl implements UserService{

   @Autowired
   private UserRepository userRepository;
   @Autowired
   private MemberService memberService;

   @Override
   public void register(String name){
     userRepositoryadd(name);
   }

}

👉 위의 코드에 대한 순수 자바 테스트 코드를 작성하면 다음과 같이 작성할 수 있다.

public class UserServiceTest{

   @Test
   public void addTest(){
     UserService userService = new UserServiceImpl();
     userService.register("MinKyu");
   }

}

👉 위와 같이 작성한 순수 자바 테스트 코드는 Spring과 같은 DI 프레임워크 위에서 동작하지 않으므로 의존관계 주입이 되지 않을 것이고, userRepository가 null이 되어 userRepository의 add 호출 시 NullPointExeption가 발생할 것이다. 이를 해결하기 위해 Setter를 사용하면 여러 곳에서 사용가능한 싱글톤 패턴 기반의 빈이 변경될 수 있는 치명적인 단점을 갖게된다.

또한 반대로 테스트 코드에서도 @Autowired를 사용하기 위해 스프링 빈을 올리면 단위 테스트가 아니며 컴포넌트들을 등록하고 초기화하는 시간이 커져 테스트 비용이 증가하게 된다.

반면에 생성자 주입을 사용하려면 컴파일 시점에 객체를 주입받아 테스트 코드를 작성할 수 있으며, 주입하는 객체가 누락된 경우 컴파일 시점에 오류를 발견할 수 있다. 심지어 우리가 테스트를 위해 만든 Test객체를 생성자로 넣어 편리함을 얻을 수도 있다.

📎 이유(3): final 키워드 작성 및 Lombok과의 결합

👉 생성자 주입을 사용하면 필드 객체에 final 키워드를 사용할 수 있으며, 컴파일 시점에 누락된 의존성을 확인할 수 있다. 반면에 생성자 주입을 제외한 다른 주입 방법들은 객체의 생성(생성자 호출) 이후에 호출되므로 final 키워드를 사용할 수 없다.

또한, final 키워드를 붙임으로써 Lombok과 결합되어 코드를 간결하게 작성할 수 있다. Spring과 같은 DI 프레임워크는 Lombok과 환상적인 궁합을 보여주는데, 위에서 작성했던 생성자 주입 코드를 Lombok과 결합시키면 다음과 같이 간편하게 작성할 수 있다. 이러한 코드가 가능한 이유는 Spring에서는 생성자가 1개인 경우 @Autowired를 생략할 수 있도록 도와주고 있으며, 해당 생성자를 Lombok으로 구현하였기 때문이다.

@Service
@RequiredArgsConstructor
public class UserServiceImpl implements UserService{

    private final UserRepository userRepository;
    private final MemberService memberService;

    @Override
    public void register(String name){
      userRepository.add(name);
   }

}

📖 참고

• https://csy7792.tistory.com/148
• https://velog.io/@jeong-god/IoC%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
• https://velog.io/@gillog/Spring-DIDependency-Injection
• https://mangkyu.tistory.com/150
• https://mangkyu.tistory.com/125