🌈 [Section2] 18. DI (Dependency Injection) 1

📕 오늘 배운 내용!

• 스프링 컨테이너 (Spring Container)
• 빈 (Bean)
• 빈 스코프 (Bean Scope)
• 싱글톤

---

✏️ DI (Dependency Injection)

( 이 전 게시물에서 정리한 것과 같이)

• 객체 교체의 경우 수정이 불편하기 때문에, 생성자를 통한 의존성 주입으로 객체가 생성되는 순간 의존관계를 설정하는 것

• 다른 방식으로도 의존성 주입이 가능하지만, 생성자를 통하는 것이 일반적이고 이렇게 하면, 실제로 스프링에서 의존성 주입을 도와주게 됨
  ( 스프링에서 공식적으로 추천하는 방법 )

( 아래는 공식 문서에 생성자 기반 및 setter 기반 DI를 함께 사용할 수 있지만, 스프링에서는 생성자 주입을 추천한다는 내용이 포함 ⬇️ )
[참고] https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-constructor-injection

✔️ DI 예시

➜ 워드로 따로 작성해놓은 파일 보거 참고하기 !

---

✏️ 스프링 컨테이너 (Spring Container)

(IoC 컨테이너 / DI 컨테이너 라고도 요즘 꽤 말함 )

• 스프링 프레임워크의 핵심 컴포넌트
  ( 스프링이 이 스프링 컨테이너를 통해 객체들을 관리함 )

  ✔️ 컴포넌트 (component)
  여러 개의 프로그램 함수들을 모아 하나의 특정한 기능을 수행할 수 있도록 구성한 작은 기능적 단위

• 개발자가 정의한 애플리케이션 내부의 빈(Bean)(객체)들의 생명주기 관리하고, 개발자가 필요로할 때 제공 ( IoC/DI 원리가 적용 )

  Ex. Bean 생명주기 관리 ➜ Bean 생성, 인스턴스화, 구성, 관리, 제거 등
  (생성부터 소멸까지)

• 이 자체도 인터페이스고, 이것의 하위 인터페이스를 또 사용
  ( 눈에 보이지는 않지만 모두 추상화 되어 있음 )
  

• 객체 생성 후, 의존성 주입을 통해 빈(객체)들을 연결
  ➜ 개발자가 모듈 간의 의존/결합으로 인해 발생하는 문제 신경 안써도 됨
  ➜ 메서드가 언제/어디서 호출되어야 하는지, 메서드를 호출하기 위해 필요한 매개 변수를 준비해서 전달하지 않아도 됨

  ✔️ 모듈 (module)
  관련된 데이터와 함수를 하나로 묶은 단위
  ➜ 보통 하나의 소스 파일에 모든 함수 작성하지 않고, 기능별로 따로 모듈 구성함, 그리고 이 모듈들을 합쳐 하나의 파일을 작성하는 방식으로 프로그램 만듦

• 이를 통해, 원하는 만큼 많은 객체 가질 수 있고, 인터페이스에만 의존하도록 설계할 수 있음

• XML, 애너테이션 기반의 자바 설정 클래스로 만들 수 있음
  ( But, 전에는 개발자가 xml을 통해 모두 설정해줬지만, 복잡한 부분들을 Spring Boot가 해주어 요즘 XML은 거의 사용 X)

❗ 💬 정리하자면, 개발자가 작성한 코드가 컨테이너를 사용하는 순간, 개발자의 손을 떠나 컨테이너의 독립적인 영역에 종속되어, 그 후엔 컨테이너 맘대로 관리하게 되는 것 !!

✔ 사용 이유

( IoC/DI 사용 이유와 같음 )

• 객체 간의 의존성을 낮춰 객체지향 프로그래밍의 핵심 중 하나인 낮은 결합도와 높은 캡슐화를 실현하기 위해

✔ 종류

1. BeanFactory

• 스프링 컨테이너의 최상위 인터페이스

• 빈을 관리하는 역할
  Ex. 빈 등록, 생성, 조회, 돌려주기, 검색 등

• getBean() 메소드를 통해 빈을 인스턴스화할 수 있음
  ( 처음 getBean() 메소드가 호출된 시점에서야 해당 빈이 생성됨 )

• @Bean이 붙은 메서드의 이름을 스프링 빈의 이름으로 사용하여 빈을 등록

2. ApplicationContext

• BeanFactory의 기능을 상속받은 인터페이스
  ( 인터페이스라함은, 여러 구현체를 사용할 수 있다는 의미 ! )
  

➜ But, 스프링 컨테이너 하면 주로 이 ApplicationContext를 뜻함

• BeanFactory가 제공하는 기능 외에 부가기능 제공

  ✔️ 부가기능

  • MessageSource
    ➜ 메세지 다국화를 위한 인터페이스
  • EnvironmentCapable
    ➜ 개발, 운영 등 환경변수 등으로 나눠 처리하고, 애플리케이션 구동 시 필요한 정보들을 관리하기 위한 인터페이스
  • ApplicationEventPublisher
    ➜ 이벤트 관련 기능을 제공하는 인터페이스
  • ResourceLoader
    ➜ 파일, 클래스 패스, 외부 등 리소스를 편리하게 조회

✔ 생성 과정

1. 스프링 컨테이너 생성

➜ new AnnotationConfigApplicationContext(구성정보.class)로 스프링에 있는 @Bean의 메서드 등록
(애너테이션 기반의 Java 설정 클래스로 Spring을 만드는 것 )

➜ 생성할 때 어떤 구성정보를 쓸 것인지 지정하는데, 위의 예시에서는 AppConfig.class를 구성정보로 지정함
( AppConfig.class에 있는 구성 정보를 통해서 스프링 컨테이너가 필요한 객체들을 생성 )

➜ 애플리케이션 클래스는 구성 메타데이터와 결합되어 ApplicationContext가 생성/초기화된 후, 완전히 구성되고 실행 가능한 시스템/애플리케이션을 갖게 됨

XML 기반으로 만드는 ClassPathXmlApplicationContext도 있음

✔️ AnnotationConfigApplicationContext
➜ ApplicatonContext 인터페이스의 구현체 )

➜ 스프링 컨테이너가 Configuration Metadata 사용

✔️ Configuration Metadata
Spring 컨테이너가 객체를 어떻게 생성할 것인지 표현하기 위한 메타데이터

• XML-based metadata - 외부 XML 파일로 표현
  ➜ 클래스에서 프레임워크에 대한 의존성을 줄일 수 있음
• Java-based metadata - 애너테이션 등의 자바 코드로 표현
  ➜ XML 방식에 비해 관리가 쉬움

2. 스프링 빈 등록

➜ 스프링 컨테이너 생성 시 파라미터로 넘어온 설정 클래스 정보를 사용하여 등록

➜ 빈 이름은 기본적으로 메서드 이름 사용하고 항상 다르게 !
( @Bean(name="지정할 이름")으로 직접 부여도 가능 )
( 같은 이름 부여할 경우 기존 빈을 덮어버릴 수 있기 때문 )

3. 스프링 빈 의존 관계 설정 - 준비

➜ 빈 생성 후, 의존 관계 설정을 위해 준비

4. 스프링 빈 의존 관계 설정 - 완료

➜ 생성된 빈들로 설정 정보를 참고하여 각 객체간에 의존 관계를 주입
( 이렇게 Java 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리됨 )

5. 생성한 빈 조회
➜ 등록된 빈들을 모두 조회하고 싶을 경우, findAllBean() 메소드 사용하여 출력 가능

findAllBean()
컨테이너에서 모든 빈의 이름을 가져와서 출력하는 메서드
( 이 경우 스프링이 자체적으로 등록한 빈도 모두 출력됨 )

➜ 직접 등록한 빈들만 조회하고 싶을 경우, findApplicationBean() 메소드 사용하여 출력 가능

➜ 상속관계가 있을 시 부모타입으로 조회하면 자식 타입도 함께 조회됨
( object 타입으로 조회하면 모든 스프링 빈 조회 가능 )

✔️ ApplicationContext 인터페이스 구현체 확인법
Windows의 경우
➜ Ctrn + N ➜ 클래스에서 ApplicationContext로 검색
⠀
➜ 화면에서 가장 첫번째 파일인 ApplicationContext 인터페이스를 구현한 하위 클래스들이 나오는 걸 확인할 수 있음

✔ 컨테이너 인스턴스화

➜ ApplicationContext 생성자에 제공된 외부 리소스들로부터 구성 메타데이터를 로드할 수 있도록 하는 리소스 문자열

Ex. 여기서 외부 리소스 ➜ 위치 경로, 로컬 파일 시스템, Java CLASSPATH 등

---

✏️ 스프링 빈(Bean)

• 스프링 컨테이너에 의해 관리되는 재사용 소프트웨어 컴포넌트
  ( 스프링 컨테이너에 의해 관리되는 인스턴스화된 객체 )
  ( 설정 정보(BeanDefinition)와 함께 스프링 컨테이너에 등록된 객체 )

✔️ Java Bean(Spring Bean)
➜ 단순하게 클래스 내에 Getter/Setter만 가지고 있는 클래스
( 스프링 빈은 자바 빈과 다름 )

• 스프링 컨테이너 생성 시 파라미터로 넘어온 설정 메타데이터(BeanDefinition)로 생성

• @Bean이 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록

✔ Bean 접근 방법

• ApplicationContext 사용
  ➜ bean 정의를 읽고 액세스할 수 있음

• getBean() 사용
  ➜ bean의 인스턴스를 가져올 수 있음

  But, 응용 프로그램 코드에서는 getBean() 메서드로 호출하여 사용하면 안됨
  ➜ 이 메서드를 사용할 경우 getBean(이름, 타입)으로 호출해야하는데 이름과 타입을 알아야만 호출이 가능
  But, 의존성을 주입했어도 이름과 타입을 몰라도 호출이 가능해야함!
  ( 의존성 주입이 의미가 없는 것 )

✔ BeanDefinition

( 추상화되어 있음 )

• Configuration metadata로 정의한 빈 설정 메타데이터
  ( 빈의 생성 정보, 컨테이너의 명령, 인스턴스화, 설정, 조립할 객체 정의 )

• 속성에 따라 컨테이너가 Bean을 어떻게 생성, 관리할지 결정

• @Bean or <bean> 당 각 1개씩 메타 정보가 생성

• 스프링이 설정 메타정보를 BeanDefinition이라는 인터페이스를 통해 관리하기 때문에, 스프링이 XML, Java와 같은 다양한 설정 형식을 지원할 수 있는 것

✔️ BeanDefintion 개체가 포함하고 있는 메타데이터
[참고] https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-definition

• BeanClassName
  ➜ 생성할 빈의 클래스 명 (자바 설정처럼 팩토리 역할의 빈을 사용하면 없음)
• factoryBeanName
  ➜ 팩토리 역할의 빈을 사용할 경우 이름 Ex. appConfig
• factoryMethodName
  ➜ 빈을 생성할 팩토리 메서드 지정 Ex. userService
• Scope
  ➜ 싱글톤 (기본값)
• lazyInit
  ➜ 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아니라, 실제 빈을 사용할 때까지 최대한 생성을 지연처리 하는지 여부
• InitMethodName
  ➜ 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명
• DestoryMethodName
  ➜ 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명
• Constructor arguments, Properties
  ➜ 의존관계 주입에서 사용 (자바 설정처럼 팩터리 역할의 빈을 사용하면 없음)

✔ 빈 스코프 (Bean Scope)

• 말 그대로 빈(객체)이 사용되어지는 범위

• 빈 설정 메타정보(BeanDefinition) 만들 때, 그걸로 만들 클래스의 인스턴스 만들기 위해서, 그 인스턴스(빈)가 존재할 수 있는 범위(레시피) 설정하는 것
  Ex. 앱 구동되는 동안 빈(객체)을 몇개 만들어서 쓸 건지, HTTP 요청마다 생성해서 쓸 건지 등 결정

  ✔️ 레시피
  ➜ 빈이 존재할 수 있는 범위

• 특정 Bean 정의에서 생성된 객체에 연결할 다양한 의존성, 구성 값뿐만 아니라, 특정 Bean 정의에서 생성된 개체의 범위도 제어 가능

• Spring Framework는 6개의 Scope(범위) 지원하고 이 중 하나에 배치되도록 정의할 수 있음
  ( 아래 <✔ 빈 스코프 종류>에서 설명 )

• 구성을 통해 생성하는 객체의 범위를 선택할 수 있기 때문에 강력하고 유연

• 사용자가 범위를 정의하여 생성할 수도 있음

✔ 빈 스코프 종류

• singleton (Default)
  ➜ 스프링 컨테이너의 기본값
  ➜ 각 스프링 컨테이너의 단일 객체 인스턴스에 대한 단일 BeanDefintion의 범위 지정
  ( static 인스턴스 직접 만들지 않아도 됨 )

• prototype
  ➜ 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프

• request
  ➜ 웹 요청이 들어오고 나갈 때 까지 유지되는 스코프

• session
  ➜ 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프

• application
  ➜ 웹의 서블릿 컨텍스와 같은 범위로 유지되는 스코프

• websocket
  ➜ 단일 BeanDefintion 범위를 WebSocket의 라이프사이클까지 확장
  ➜ Spring ApplicationContext의 컨텍스트에서만 유효
  ⠀
  ( 이 중 4개는 ApplicationContext를 사용하는 경우에만 사용 가능 )
  [참고] https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-factory-scopes

✔ 싱글톤 스코프(Singleton Scope)

• 해당 빈의 인스턴스를 딱 1개만 생성해서 사용하는 것
  ( ➜ 객체(인스턴스)를 2개 이상 생성하지 못하도록, 코드에서 private 생성자 사용하여 외부에서 new 키워드 사용 못하게 막기 )

• 이 단일 인스턴스는 싱글톤 빈의 캐시에 저장됨

• 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때 까지 유지
  ( 스프링 컨테이너 종료시 소멸 메서드도 자동으로 실행 )

• 해당 BeanDefinition과 일치하는 ID / ID를 가진 빈에 대한 모든 요청은 스프링 컨테이너에서 그에 해당하는 특정 빈 인스턴스를 반환

• 이름이 정해진 빈에 대한 모든 요청과 참조는 캐시된 개체를 반환
  ( 싱글톤 스코프의 스프링 빈은 여러번 호출해도 모두 같은 인스턴스 참조 주소값을 가짐 )

➜ 클라이언트들이 스프링 빈을 요구할 때, 같은 참조값을 가진 빈 객체를 반환해줌

[참고] https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/beans.html#beans-factory-scopes

❗ 💬 핵심
➜ bean 하나에 하나씩 메타 정보가 생성되고, 스프링 컨테이너는 이런 메타 정보를 기반으로 스프링 빈을 생성한다 !!!!!

✔ 싱글톤 패턴(방식)의 문제점

• 싱글톤 방식을 구현하는 코드 자체가 많음

• 의존관계상 클라이언트가 구체 클래스에 의존
  ➜ DIP 위반 ( OOP의 SOLID 중 하나 )

• 지정해서 가져오기 때문에 테스트하기 어려움

• 유연성 떨어짐
  ( private 생성자를 사용해 자식 클래스 만들기가 어려기 때문 )

• 속성 공유
  ➜ 멀티 쓰레드 환경에서 동시성 문제
  ( 싱글톤 객체의 속성이 여러 쓰레드에 의해 바뀔 수 있음 )
  ➜ A 쓰레드에선 속성 값을 x로 바꾸고 출력하는 과정에서 B 쓰레드가 속성 값을 y로 바꾸면 쓰레드 A에선 예상하지 못한 값이 나올 수 있음
  ( 1개의 인스턴스에서 속성값을 공유하기 때문 )

• 싱글톤 빈이 많을 수록 구동 시간이 증가
  ( 애플리케이션 구동 시 생성되기 때문에 )

✔️ 이 문제점을 싱글톤 컨테이너가 해결해줌 !

• 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리
• 스프링 컨테이너 ➜ 싱글톤 컨테이너 역할
• 싱글톤 레지스트리 (Singleton Registry) 기능 가짐
  ⠀
  ➜ 위 기능들 덕분에, 싱글톤 방식의 문제점들을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리할 수 있음
  ( 스프링 빈이 바로 싱글톤으로 관리되는 객체인 것 )
  ⠀
  ( 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않고, DIP, OCP 위반하지 않으면서 테스트 용이해짐 )

✔️ 싱글톤 레지스트리 (Singleton Registry)
싱글톤 객체로 생성하고 관리하는 기능

✔ 싱글톤 방식의 주의점

• 하나의 인스턴스를 생성해서 공유하는 형식이므로 무상태(Stateless)로 설계해야함

  • 특정 클라이언트에 의존적이거나 값을 변경할 수 있는 필드가 있으면 안됨

  • 가급적 읽기만 가능해야 함

  • 필드 대신, 공유되지 않는 지역변수,파라미터,ThreadLocal을 쓰기
    ( 스프링 빈의 공유값을 설정하면 장애 발생 )
    Ex. 필드가 아닌 파라미터를 반환하자

---

✔️ 싱글톤 예시

➜ 워드에 작성해 놓은 것 참고하기 !!

---

🌈 느낀점

오늘 학습 설명이 좀 꼬이고 꼬인 느낌이어서 이해하기 어려웠다ㅠ
그래서 학습 시간에는 읽으면서 정리하고 있지만 도저히 이해가 안갔었는데 그래도 이후 이해하려고 말로 설명해보면서 블로그 작성하니까 많이 이해가 됐다 !