IT's 잡탕찌개 블로그

Spring ApplicationContext란 무엇인가?
Spring에서 IOC Container를 BeanFactory라고 하며 이 BeanFactory에 여러 기능이 추가된 class를 ApplicationContext라고 한다.

Bean Factory는 SpringContainer의 최상위 interface로 spring bean 을 관리 및 조회하는 역할을 한다.
BeanFactory를 기반으로 ApplicationContext에 추가된 부가기능으로는 환경변수 관련 처리, Application의 event를 발생시킬 수 있으며, 다양한 리소스를 읽는 등 여러 기능이 존재한다.

Application Context가 bean요청을 처리하는 과정
0. application context는 @configuration 이 붙은 class는 설정파일 정보로, @Bean, @Component가 붙은 method는 method 이름으로 bean 목록을 작성한다.
1. client가 특정 bean을 요청한다.
2. application context는 현재 등록된 bean 목록에서 해당 이름의 bean이 존재하는지 확인한다.
3. application context는 설정 class로부터 bean 생성 요청 및 생성된 bean객체를 반환한다.

Application Context를 사용하여 SpringFramework가  얻는 장점
. @Configure Annotation을 통해 설정과 관련된 class를 구분, 관리할 수 있다.
. 설정 class를 구분함으로써 client는 구체적인 설정 class를 알 필요가 적어진다.
. Application Context를 통해서 전반적인 IOC 서비스를 제공할 수 있다.
. Application Contextㄹ르 통해서 다양한 Bean을 검색할 수 있다.

Spring ApplicationContext에 등록된 Bean
Application Context에 등록된 Bean의 경우 기본적으로 Singleton으로 관리된다.
Spring에서 여러 Bean을 요청할 시 모든 요청에 대해 활용되는 객체는 단일 객체이며,
이로 인해 여러번 요청이 오더라도 매 요청마다 새로운 Bean 객체를 생성하지 않고 단일 객체를 활용한다.
(MultiThread에서 해당 Bean을 공유한다고 한다.)

Java를 통해 직접 Singleton객체를 만들 때 단점은 아래와 같다.
. private 생성자를 지녀 상속이 불가능하다.
. server 환경에서는 singleton이 1개만 생성됨을 완벽히 보장하지 못한다.
. static 상태를 만들 수 있기때문에 객체지향적이지 못하다.

이에 반해서 Spring 이 직접 Singleton 객체를 만들고 관리하는데, 이를 Singleton Registry라고 부른다.
Singleton Registry의 장점은 아래와 같다.
. static method나 private 생성자 등을 사용하지 않아 좀더 객체지향적 개발이 가능하다.
. test를 하기에 편하다.

다만 Bean 객체 정의 시 주의할점이 존재한다
. Bean 객체가 singleton으로 관리되기 때문에 각 객체는 내부에 상태정보를 지니면 안된다.
-> stateless 를 유지해야 함.
-> multi thread 환경에서 특정 상태를 지니면 위험소지가 존재.


참고 포스트
. https://mangkyu.tistory.com/151

spring에서의 IOC를 사용하는 이유는 어떤 것이 있을까?
객체지향 원칙을 준수하며 객체관리를 framework에 위임하고 개발자가 구현하려는 부분으로
각각의 역할을 분리해 응집도를 높이고 결합도를 낮추어 변경에 유연한 구조를 유지할 수 있기 때문이다.
즉, 추상 class와 구현 class를 만든 뒤 추상 class를 주입 받도록 하여 개발자는 비즈니스 로직에만 집중할 수 있게 된다.

spring에서의 IOC 원리
특정 instance 가 필요할 때 IOC container에서 Bean으로 등록된 class를 확인하여 instance를 생성한다.
그 후 해당 instance 가 필요한 다른 Bean 객체에서 요청 시에 이를 자동으로 주입해준다.

spring에서의 DI 방식은 아래의 3가지 방식이 존재하며 이에 대한 자세한 포스팅은 추후에 다루기로 한다.
. 생성자 주입
. setter 주입
. field 주입

spring의 IOC container
spring에서 IOC를 수행하는 component를 Ioc container 혹은 spring container라고 부른다.
spring container는 객체를 생성, 객체간의 관계를 연관, 객체의 생명주기를 담당한다.
즉, spring container는 의존성을 주입하고 각 객체들끼리 연관지어 Spring application 을 동작할 수 있게 해준다.

spring bean란
spring bean 이란 개념은 Ioc container가 관리하는 오브젝트들을 의미한다.

Spring ApllicatioContext
Spring 에서 ioc container의 역할을 담당하는 bean factory에 여러 기능이 추가된 것 이다.
@Component Annotation을 사용하면 해당 class를 component scan을 통해서 Bean으로 등록해준다.
Spring ApplicationContext에 대해서는 추후에 더 자세하게 다룰 예정이다.

spring 을 공부하면 필연적으로 듣게 되는 단어가 있다

바로 IOC 이다.
IOC는 Inverse of control 이라는 의미로 "제어의 역전"이라는 의미이다.
IOC는 코드의 제어가 유저에게 있는것이 아닌 framework 등 제 3자에게 위임되는 것을 의미한다.
쉽게 예를 들어보자.

class A
{
 public void callMe()
 {
  ....
 }
}

현재 사용하는 framework가 A라는 class의 함수를 내부에서 호출한다고 가정해보자.
즉, 해당 class에 대해서 함수의 호출 혹은 객체 생성등을 framework가 제어하고 있는 상태이다.
이러한 상황에서 우리가 A에 대한 callMe함수 오버라이딩 등을 통해서 정의한다면 해당 코드에 대해서는 framework가 직접 제어하는 상황이 되는 것이다. (DI에 대해서는 추후에 다룰 예정)

IOC의 실제 사용 예는 대표적으로 아래의 예가 존재한다
. Template Method
. DI ( Dependency Injection )
. Strategy Pattern
. Factory Pattern
. Service Locator

DI (Dependency Injection )
DI란 의존성을 주입하는것을 의미한다.
Ioc를 구현하기 위해 사용되는 대표적인 design pattern 중 하나로 특정 객체의 의존 관계를 객체의 외부에서 주입시키는 패턴이다.
전통적인 구현방식에서는 특정 A class에 대한 정의 후 A를 호출하는 식으로 프로그램이 구현된다.
하지만 DI의 경우, 우리가 A를 재정의한 A`를 정의하면 A에 대한 호출은 이미 외부에서 선언이 되어 있는 상태이기 때문에 A`의 code 가 호출된다.

DI는 어떤 조건을 지켜야 만족하는 것인가?
. class code 혹은 class model에서는 의존 관계가 노출되지 않는다.
. runtime 시점의 의존관계는 factory 등의 제 3의 존재가 결정한다.
. 의존관계는 object에 대한 레퍼런스를 외부에서 주입함으로써 만들어진다.

public class A
{
  prviate B b;
  
  public A()
  {
    b = new B();
  }
}

public class C
{
  private D d;
  public C(D d)
  {
    this.d = d;
  }
}

위의 코드 중 A에 대한 내용을 살펴보자.
A의 내부에선 B에 대한 객체 생성을 진행하며 이를 내부 변수로 지닌다.
이 과정은 DI라고 볼수 없는데 우선 B의 생성자가 A에서 호출되기 때문에 추후에 B의 생성자가 변경될 시 A가 영향을 받는 문제가 존재한다.
또한 위의 code를 보면 A는 B를 생성한다는 점에서 사실상 B와 A가 class 수준으로 관계가 생긴것으로 볼 수 있다. 이 점에선 위의 DI가 지켜야할 조건중 하나를 지키지 못한것으로 볼 수 있다.
반면, D와 C의 경우를 살펴보면 C는 외부에서 D에 대한 객체를 전달 받는 것을 볼 수 있다.
이렇게 객체를 전달 받으면 C는 D의 레퍼런스를 전달 받는다.
D와 C는 객체에 대한 의존을 갖고 class 수준의 관계는 맺지 않으며, 의존관계는 외부에서 주입당하여 만들어진다. 또한 runtime 시에 외부에서 의존관계를 지정하기때문에 DI에 필요한 조건들을 만족한다.

위의 예에서는 생성자를 통해 D를 전달 받기는 했지만 의존성은 setter 함수 혹은 interface 구현을 통해서도 삽입 될 수 있다.

public class SetterA
{
  private B b;
  ....
  public void setB(B b)
  {
    this.b = b;
  }
}

public class InterA extends injectorB
{
  private B b;
  @Override
  public void injection(B b)
  {
    this.b = b;
  }
  ...
}

interface injectorB
{
  void injection(B b);
}

이렇게 setter와 interface를 사용하여 의존성을 주입할 수 있지만 setter의 경우 함수 정의를 누락할 여지가 있다.