#스프링 #DI 장점

DI 사용 장점

• 객체 간 결합도를 낮춘다
• 유연한 코드 작성 가능
• 가독성 증진
• 코드 중복 방지
• 유지보수가 용이
• 기존에는 개발자가 직접 객체 생성과 소멸을 제어했는데 DI로 인해 객체 생성과 소멸 등 클래스간 의존관계를 스프링 컨테이너가 제어

• DI는 객체의 생성, 소멸, 의존 관계를 개발자가 직접 설정하는 것이 아니라 XML이나 애너테이션을 통해 스프링 프레임워크가 제어
• 기존에는 개발자가 직접 객체를 생성해줬던 반면에 스프링 프레임워크에서는 객체의 제어를 스프링이 직접 담당해주는 IoC 특징을 가진다

DI를 하는 방식

1. Field Injection(필드 주입)
2. Setter Injection(수정자 주입)
3. Constructor Injection(생성자 주입) (*추천//Spring에서도 권장하는 방식)

Field Injection(필드 주입)의 단점

• SRP(단일 책임 원칙)의 원칙을 해칠 가능성이 높아진다
  • 간단한 사용법 아래 개수 제한 없이 무한정 추가하게 되고 Class가 많은 책임을 떠안게 된다
• 의존성이 숨는다
  • 필드 주입의 경우에는 외부에서 해당 클래스가 어떤 의존성의 책임을 지고 있는지 알 수 없다.
• DI 컨테이너의 결합성과 테스트 용이성
  • DI 프레임워크의 핵심은 관리되는 Class가 DI Container에 의존성이 없어야 한다. 이는 DI Container가 필요한 의존성을 전달만 하면 그 이후엔 독립된 개체가 되어야 한다
  • 독립된 개체가 되면 Test에서도 용이
    하지만 필드 주입은 DI Container에 의존성을 가지게 된다
• 불변성을 활용할 수 없다
  • 필드 주입은 final을 선언할 수 없다

Setter Injection(생성자 주입)의 단점

• NullPointerException이 발생할 수 있다
  • 선택적 주입을 할 수 있기 때문에 클래스 인스턴스 생성 시에 의존성 주입을 해주지 않아도 생성 이러한 상황에서 사용하면 NullPointerException이 발생
• 불변성을 활용할 수 없다
  • 필드 주입은 final을 선언할 수 없다

Constructor Injection(생성자 주입)을 사용해야 하는 이유

• NullPointerException의 발생을 막는다
  • 기존 Setter Injection의 단점을 보완 생성시에 의존성 없이는 생성 불가능하기 때문에 일부러 null을 주입하지 않는 이상 발생하지 않는다
• 불변성을 활용
  • final로 선언 가능
• SRP(단일 책임 원칙)을 지킬 수 있도록 유도
  • 코드가 길어진다면 단일 책임 원칙을 다시 한번 생각하게 해 준다

(------------------------------------------------------------)

• 의존 중인 객체를 외부로부터 주입받는 방식이 DI
• DI를 통해 IoC를 이루고 이는 결합도를 줄이고 가독성을 높이고 유지 보수를 편하게 해 준다
• DI를 수행하는 것은 스프링 컨테이너(= ApplicationContext)
• Bean 객체는 스프링 컨테이너가 관리하는 객체를 의미
• 스프링 컨테이너 내부에 Bean 저장소에 Bean 객체의 정보를 저장
• Bean은 기본적으로는 싱글톤 스코프로 생성, 관리되고 프로토타입 스코프도 사용 가능
• ApplicationContext는 BeanFactory라는 최상위 인터페이스를 상속

참조: https://marrrang.tistory.com/58