[Spring] 의존성 주입(Dependency Injection)이란? (개념/ 예제/ 총 정리)

서론

---

이번글에서는 스프링을 이용한 의존성 주입에 대해서 알아보려한다. 

의존성 주입(DI)은 크게 4가지 방법이 있다.

 

1. 생성자 주입

2. 수정자 주입(setter 주입)

3. 필드 주입

4. 일반 메서드 주입

 

위와 같이 4가지 방법이 있는데, 네가지 중 어떤 방식이 효율적이고 실제 실무에서 어떻게 쓰이는지 간략히 정리해보려한다.

 

---

 

 

의존성 주입(Dependency Injection)이란?

---

Sprng Framework의 3가지 핵심 프로그래밍 중 하나인 의존성 주입(DI)는 외부에서 두 객체 간의 관계를 결정해주는 디자인 패턴으로 

 

인터페이스를 사이에 둬서 클래스 레벨에서는 의존관계가 고정되지 않도록 하고 런타임 시에 관게를 동적으로 주입하여 유연성을 확보하고 결합도를 낮출 수 있게 해준다.

 

여기서 말하는 의존성은 하나의 객체가 다른 객체를 사용할 때 의존할 때를 말한다.

 

스프링 서적하면 가장 먼저 떠오르는 토비의 스프링에서는 다음과 같이 말한다.

A가 B를 의존한다"는 어떤 의미일까?

"의존 대상 B가 변하면 그것이 A에 영향을 미친다."

즉, B의 기능이 추가 또는 변겨되거나 형식이 바뀌게 되면 그 영향이 A에 미치게 되는 것을 말한다.

 

이제 첫 서론에서 말했던 의존관계 주입(의존성 주입)이 어떤 방식들이 있는지 알아보자.

 

---

 

생성자 주입 (추천)

---

이름 그대로 생성자를 통해서 의존 관계를 주입받는 형식을 말한다.

 

특징

1. 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.

2. 불변, 필수 의존관계에 사용한다.

 

 

예제 소스

@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개만 있다면 @Autowired를 생략할 수 있다.

 

 

@Autowired 생략

@Component
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;
    
 	}
}

 

---

 

수정자 주입(setter 주입)

---

setter라 불리는 필드의 값을 변경하는 프로퍼티(수정자 메서드)를 이용하여 의존관계를 주입하는 방법을 말한다.

 

특징

1. 선택, 변경 가능성이 있는 의존관계에 사용한다.

2. 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다.

 

 

예제 소스

@Component
public class OrderServiceImpl implements OrderService {
	private MemberRepository memberRepository;
	private DiscountPolicy discountPolicy;
    
 @Autowired
 public void setMemberRepository(MemberRepository memberRepository) {
 	this.memberRepository = memberRepository;
 }
 
 @Autowired
 public void setDiscountPolicy(DiscountPolicy discountPolicy) {
	 this.discountPolicy = discountPolicy;
 }
}

 

[참고]

1. @Autowired의 기본 동작은 주입할 대상이 없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false)로 설정하면 된다.

 

---

 

필드 주입

---

이름 그대로 필드에 바로 주입하는 방법을 말한다.

 

특징

1. 코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트하기 힘들다는 치명적인 단점이 있다.

2. DI 프레임워크가 없으면 아무것도 할 수 없다.

3. 사용을 지양하자.

 

그럼 언제사용?

 > 애플리케이션 실제코드와 관계 없는 테스트 코드를 작성할 때 사용한다.

 > 스프링 설정을 목적으로 하는 @Configuration같은 곳에서 특별한 용도로 사용한다.

 

 

예제 소스

@Component
public class OrderServiceImpl implements OrderService {

 @Autowired
 private MemberRepository memberRepository;
 
 @Autowired
 private DiscountPolicy discountPolicy;
 
}

 

[참고]

1. 순수한 자바 코드에는 당연히 @Autowired가 동작하지 않는다. @SpringBootTest처럼 스프링 컨테이너를 테스트에 통합한 경우에만 가능하다.

 

2. 아래의 코드와 같이 @Bean에서 파라미터에 의존관게는 자동 주입된다. 수동 등록시 자동 등록된 빈의 의존관계가 필요할 때 문제를 해결할 수 있다.

 

@Bean
OrderService orderService(MemberRepository memberRepoisitory, DiscountPolicy 
discountPolicy) {
 new OrderServiceImpl(memberRepository, discountPolicy)
}

 

---

 

일반 메서드 주입

---

이것도 다른것들고 마찬가지로 이름 그대로 일반 메서드를 통해 주입 받는 것을 말한다.

 

특징

1. 한번에 여러 필드를 주입 받을 수 있다.

2. 일반적으로 잘 사용하지 않는다.

 

 

예제 소스

@Component
public class OrderServiceImpl implements OrderService {

 private MemberRepository memberRepository;
 private DiscountPolicy discountPolicy;
 
@Autowired
public void init(MemberRepository memberRepository, DiscountPolicy 
discountPolicy) {
	this.memberRepository = memberRepository;
	this.discountPolicy = discountPolicy;
 }
}

 

[참고]

1. 의존 관계 자동 주입을 하기위해선 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다. 스프링 빈이 아닌 클래스에서 @Autowired 코드를 적용하여도 아무 기능도 동작하지 않는다.

 

---

 

그래서 무엇을 선택하는게 좋나?

---

답부터 말하자면 생성자 주입이다.

 

과거에는 수정자 주입과 필드 주입을 많이 사용했다고 한다. 그러나 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다. 그 이유는 다음과 같다.

 

이유1  -  불변

• 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변해야 한다.)
• 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 한다.
• 누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다.
• 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다

 

 

이유2  -  final

생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다.

 

그래서 생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에서 막아준다. (컴파일 시점에서 막아주는 것이 가장 좋은 오류라 볼 수있다)

 

 

예제 소스

@Component
public class OrderServiceImpl implements OrderService {

 private final MemberRepository memberRepository;
 private final DiscountPolicy discountPolicy;
 
@Autowired
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy 
discountPolicy) {
	this.memberRepository = memberRepository;
 }
 
 //...
 
}

위와 같이 설정하였을 경우 DiscountPolicy의 값이 비어있기때문에 빌드 전부터 다음과 같은 컴파일 에러를 발생시킨다.

 

[Error]
java: variable discountPolicy might not have been initialized

 

[참고]

수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출되므로 필드에 final 키워드를 사용할 수 없다. 오직 생성자 주입 방식만 final 키워드를 사용할 수 있다. 이는 큰 장점이다.

 

---

 

 

총 정리

---

• 생성자 주입 방식을 선택하는 이유는 여러가지가 있지만, 프레임워크에 의존하지 않고 순수한 자바 언어의 특징을 살리는 방법이기도 하다.
• 기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 된다. 생성자 주입과 수정자 주입을 동시에 사용할 수 있다.
• 항상 생성자 주입을 선택하라!! 그리고 가끔 옵션이 필요하면 수정자 옵션을 선택하면 된다. 필드 주입은 최대한 자제하자