.png&blockId=3197e115-ee0d-4d9c-9f5d-4b57cb28634e)
핵심
1.
DI 프레임워크에 의존적이다.
2.
외부에서 접근이 불가하여, 테스트 코드 작성이 어렵다 ( 요새 같이 단위테스트의 중요성을 강조할 때,,,쯧! )
3.
순환 참조/호출이 서버 구동중에 발생하여 에러에 대비하기 어렵다.
코드가 간결하고 편리한 거 말곤,,, 장점이 없네요?
필드 주입의 문제점
프레임워크와 강한 결합이 있다.
•
@Autowired 를 이용해 의존성을 주입 하므로 스프링을 통해서만 의존성 주입이 가능
단위 테스트 코드 작성이 불편하다.
•
프레임워크와의 강한 결합 때문에, 필드 주입을 이용한 객체를 테스트 하려면 스프링 컨테이너를 띄워야 한다.
런타임 중에 순환 참조/호출이 발생 할 수 있다.
•
JVM의 클래스 로더 작동 방식
◦
컴파일 후 실행시점에 모든 클래스가 실행 (X)
◦
런타임 중 클래스가 필요하게 되는 시점에 해당 클래스 로더에게 요청하여 클래스를 생성(로드) (O)
•
객체 생성 방식
◦
필드주입
public class A {
@Autowired
private B b;
}
public class B {
@Autowired
private A a;
}
Java
복사
A 클래스가 로드 될 때, B class 타입의 레퍼런스 변수만 가지며,
클래스 A의 객체가 생성 될 때, 클래스 B의 b 객체를 생성하지 않는다.
◦
생성자 주입
public class B {
private final A a;
@Autowired
public B (A a){
this.a = a;
}
}
Java
복사
생성자는 객체가 생성될 때 실행되는 메서드 이다. 따라서
객체 B가 생성될 때 객체 A를 생성해서 담는다.
Spring Framework가 구동되면, 설정을 바탕으로 빈 객체를 생성하게 되는데•
필드 주입은
◦
참조하는 객체를 선언하지 않았으므로 순환 오류 없이 초기화 완료
◦
아무문제없이 잘 작동되다가 class B 또는 class A 객체를 로드할 시점이 될 때 순환 에러를 발생
•
생성자 주입은
◦
빈 객체 생성 시점에 순환 오류 발생
따라서, 컴파일 시점에 에러를 인지할 수 있는 생성자주입 방법에 비해 필드 주입 방법은 위험하다. (비용이 크다?)
State safe 하지 않다.
•
final로 선언 할 수 없기 때문
•
개발자가 객체를 새로 할당해서 사용해도 에러가 나지 않는다.
참고
