<Spring> Spring Bean, IoC/DI 정리 1

📌 IoC

🟢 IoC 란?

IoC는 Inversion of Control의 약자로 ‘제어의 역전’이라는 의미를 가진다.

이때, ‘제어의 역전’은 무슨 의미를 가지는 걸까?

 

제어

객체 생명주기나 메서드의 호출을 직접 제어한다 ⇒ 객체 생명주기나 메서드의 호출을 직접 관리한다

직접 객체를 생성하여 코드를 “제어”

public class A {
    private B b;

    public A() {
        this.b = new B();
    }
}

A 클래스에서 B를 필드로 가지고 있고, 생성자 내부에서 직접 생성해 필드를 초기화하고 있다.

이러한 코드를 객체 생명주기를 직접 제어하는 코드라고 말할 수 있다.

 

역전

프로그램의 제어 프름을 직접 제어하는 것이 아니라 외부에서 관리하는 것

public class A {
    private B b;

    public A(B b) {
            this.b = b;
    }
}

이전 코드와 같이 A 클래스가 존재한다.

하지만 이 코드에서는 외부로부터 B를 인자로 받아 초기화하고 있다.

이렇게 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어를 역전시켰다고 말할 수 있다.

 

🟢 IoC가 왜 필요한가?

객체지향 원칙을 잘 지키기 위해!

역할과 관심을 분리해 응집도를 높이고 결합도를 낮추며,

이에 따라 변경에 유연한 코드를 작성할 수 있는 구조가 될 수 있기 때문이다.

 

🟢 IoC와 DIP

목적

한 클래스의 변경에 따른 다른 클래스들의 영향을 최소화따라서 IoC와 DIP는 같이 사용되는 것이 좋다.

즉, 애플리케이션을 지속가능하고 확장성 있게 만든다.

클래스 간 결합을 느슨히 하기 위함

 

 

IoC와 DIP의 비교

같은 목적을 가졌지만 IoC는 제어의 역전, DIP는 의존 방향의 역전이다.

IoC와 DIP는 모두 principle(원칙)이다.

 

📌 Spring Bean

🟢 의존성이란?

public class A {
    private B b;

    public A(B b) {
        this.b = b;
    }
		...
}

public class B {
		...
}

A 클래스를 생성하기 위해선 B 클래스가 존재해야한다.

이때, A 클래스는 B 클래스에 대한 의존성을 가진다고 말한다.

즉, 한 객체가 다른 객체를 사용할 때 의존성이 있다고 한다.

public static void main(String[] args) {
    A a = new A(new B());
}

그래서 A 클래스를 생성하기 위해서 위와 같은 구문이 필요하다.

클래스 간에 의존 관계가 있다는 것은 한 클래스가 바뀔 때 다른 클래스가 영향을 받는다는 것을 의미한다.

Spring은 Spring Bean을 통해 위와 같은 의존성 문제를 더 쉽게 해결할 수 있도록 해준다.

 

🟢 Spring Bean이란?

Spring document에서 Bean에 대해 이렇게 쓰여있다.

In Spring, the objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and managed by a Spring IoC container.

간단히 말해, 스프링 IoC 컨테이너에 의해 관리되는 자바 객체이다.

그렇다면 스프링 IoC 컨테이너란 무엇일까?

 

🟢 스프링 IoC 컨테이너란?

The org.springframework.context.ApplicationContext interface represents the Spring IoC container and is responsible for instantiating, configuring, and assembling the beans.

빈을 관리하는 객체이다.

document에 나온 설명에서 볼 수 있듯이, ApplicationContext 라는 인터페이스가 IoC 컨테이너를 대표한다.

ApplicationContext는 여러 인터페이스를 상속받아 만들어진다.

이에 빈 조회, 이벤트 발행, 환경변수 조회 등 다양한 기능을 구현할 수 있다.

@Test
void findAllBean(){
    String[] beanDefinitionNames = applicationContext.getBeanDefinitionNames();
    for (String beanDefinitionName : beanDefinitionNames) {
        Object bean = applicationContext.getBean(beanDefinitionName);
        log.info("name=" + beanDefinitionName + " object=" + bean);
    }
}

 

위는 모든 빈을 조회하는 테스트다.

위 결과 값에서 볼 수 있듯이 ApplicationContext 를 통해 빈에 대한 작업을 할 수 있다.

 

🟢 빈 스코프

빈은 생성되고 존재하고 적용되는 범위를 지정할 수 있다.

이를 빈 스코프라고 한다.

스프링은 다음과 같은 다양한 스코프를 지원한다.

• 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
• 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프
• 웹 관련 스코프
  • request : 웹 요청이 들어오고 나갈때까지 유지되는 스코프
  • session : 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프
  • application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

빈의 스코프는 @Scope 어노테이션을 통해 지정할 수 있다.

@Scope("prototype")
@Component
public class Prototype {
    ...
}

스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다.

 

🟢 싱글톤의 단점

1. 다형성을 이용하지 못한다.
   싱글톤 패턴을 사용하면 생성자의 접근 지정자를 private으로 설정해야 한다.
   하지만 이렇게 구현하면 해당 객체는 상속이 불가능하다.
   그러므로 객체지향의 이점인 다형성을 적용하지 못하게 된다.
2. 안정성이 중요한 애플리케이션에서 필수적인 단위 테스트가 어렵다.
   객체를 싱글톤 패턴으로 구현할 경우 해당 객체는 공유 객체가 되므로
   단위테스트를 실행할 때 테스트의 순서에 따라 결과가 달라진다.
3. 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다.
4. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
5. 내부 속성을 변경하거나 초기화하기 어렵다.
6. private 생성자로 자식 클래스를 만들기 어렵다.

종합적으로 유연성이 떨어진다는 특징을 가진다.

 

🟢 스프링과 싱글톤

스프링은 싱글톤 패턴을 사용한다.

애플리케이션이 시작될 때, 인스턴스를 메모리에 딱 하나 할당하고, 뒤의 호출 시마다 해당 인스턴스를 반환해 주는 디자인 패턴이다.

이를 적용하면 이미 만들어진 객체를 공유해서 효율적인 사용이 가능해진다.

스프링에서는 이를 위해 IoC 컨테이너를 사용한다.

이를 이용하여 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

 

🟢 빈과 의존성 주입

의존성을 주입한다고 하면 어디에선가 new 키워드를 사용하여 객체를 생성해야 한다.

public class Service {
    private final Dao dao;

    public Service(Dao dao) {
            this.dao = dao;
    }
}

Service service = new Service(new JdbcDao());

예시 코드를 보면 Service를 초기화하는데 Service의 생성자로 Dao 구현체를 생성하여 넣어주고 있다.

Q. 만약 Dao의 구현체가 바뀐다면 어떻게 될까?

서비스를 생성하는 곳에서도 변경이 일어난다.

서비스를 생성할 때 Dao를 초기화함과 동시에 어떤 Dao의 구현체를 선택할 것인지에 대한 책임도 있기 때문이다.

LineService lineService = new LineServie(new StationsDao(), new LineDao(), new SectionDao());

또한 의존성을 주입할 때 여러 개의 의존성이 필요하다면 해당 의존성 주입 순서를 알아야 한다.

직접 의존성을 주입하기 위해서는 의존 관계를 모두 파악해야 하는 번거로움이 생긴다.

또한 많은 객체가 중복 생성이 되게 된다.

그래서 의존성 주입이 필요한 객체를 빈으로 등록하여,

스프링 IoC 컨테이너가 객체의 생성과 의존성 주입을 관리하도록 해야 한다.

 

🟢 스프링 IoC 컨테이너는 어떻게 빈을 관리할까?

IoC 컨테이너가 빈의 라이프사이클을 관리하는 과정은 이러하다.

 

1. 객체 생성 + property 설정

 

먼저 Spring IoC 컨테이너가 생성이 되면 빈 스코프가 싱글톤인 객체를 생성한다.

이때 빈으로 등록하기 위해서 다양한 Configuration 메타데이터를 이용하여 통일된 Bean Definition을 생성한다.

그리고 빈으로 등록할 POJO와 Bean Definition 정보를 이용하여 빈을 생성한다.

이 과정에서 싱글톤 패턴을 사용하는 것이 아닌 평범한 자바 클래스를 이용하여 객체를 생성한다.

 

2. 의존 설정

빈 객체가 생성이 되면 IoC 컨테이너는 의존 설정을 한다.

이때 의존성 자동 주입이 일어나게 된다.

 

3. 객체 초기화 → 사용 → 소멸

 

모든 객체가 다 초기화가 필요한 것은 아니지만 사용 전에 초기화 과정이 필요한 객체들은 초기화 과정을 진행한다.

초기화가 끝나면 드디어 빈을 사용할 수 있게 된다.

그리고 스프링 컨테이너가 종료될 때 빈 스코프가 싱글톤인 객체들도 함께 소멸된다.

 

🟢 빈 설정 방법

빈을 설정하는 방법은 간단하다.

@Bean 어노테이션을 이용하면 된다.

public class Appconfig {
    @Bean
    public BeanA beanA() {
        return new BeanA();
    }

    @Bean
    public BeanB beanB() {
        return new BeanB(beanA());
    }

    @Bean
    public BeanC beanC() {
        return new BeanC(beanA());
    }
}

@Test
void notSingleton(){
    Appconfig appConfig = new Appconfig();

    BeanA beanA1 = appConfig.beanA();
    BeanA beanA2 = appConfig.beanA();

    log.info("beanA1 = " + beanA1);
    log.info("beanA2 = " + beanA2);

    assertThat(beanA1).isNotSameAs(beanA2);
}

위 예시에서 볼 수 있듯이, 같은 객체를 출력했지만 값이 다르다.

BeanA 객체가 2번 만들어진 것이다.

이는 싱글톤이 아니다.

그렇다면 어떻게 싱글톤을 만들 수 있을까?

스프링에서 빈을 싱글톤으로 관리하기 위해, @Configuration 어노테이션을 이용해야 한다.

@Configuration
public class Appconfig {
    @Bean
    public BeanA beanA() {
        return new BeanA();
    }

    @Bean
    public BeanB beanB() {
        return new BeanB(beanA());
    }

    @Bean
    public BeanC beanC() {
        return new BeanC(beanA());
    }
}

@Test
void singleton(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(Appconfig.class);

    BeanA beanA1 = ac.getBean("beanA",BeanA.class);
    BeanA beanA2= ac.getBean("beanA",BeanA.class);

    log.info("beanA1 = " + beanA1);
    log.info("beanA2 = " + beanA2);

    assertThat(beanA1).isSameAs(beanA2);
}

@Test
void singleton2(){
    ApplicationContext ac = new AnnotationConfigApplicationContext(Appconfig.class);

    BeanB beanB = ac.getBean("beanB",BeanB.class);
    BeanC beanC= ac.getBean("beanC",BeanC.class);
    BeanA beanA1 = beanB.getBeanA();
    BeanA beanA2= beanC.getBeanA();

    log.info("beanA1 = " + beanA1);
    log.info("beanA2 = " + beanA2);

    assertThat(beanA1).isSameAs(beanA2);
}

ApplicationContext의 구현체인 AnnotationConfigApplicationContext 에 파라미터로 넘긴 값은 스프링 빈으로 등록된다.

위 코드에서 AppConfig 를 파라미터로 넘겼으므로, AppConfig 와 해당 파일에 빈으로 등록한 것들이 스프링 빈으로 등록된다.

BeanB를 만들기 위해 BeanA가 생성되어야 하고, BeanC를 만들기 위해 BeanA가 또 생성되어야 한다.

이렇게 한다면 싱글톤이 아니게 된다.

하지만 스프링이 이를 싱글톤으로 유지할 수 있게 도와준다.

@Configuration 어노테이션을 사용하면,

스프링이 바이트 코드를 조작해서 싱글톤이 보장할 수 있게 다른 객체를 생성해서 저장한다고 한다.

 

간단히 말해서, 빈을 싱글톤으로 생성하기 위해선,

@Configuration 어노테이션을 사용한 객체를 ApplicationContext의 파라미터로 넘기면 된다 할 수 있다.

 

🟢 빈 설정 시 주의점

1. 싱글톤 스코프의 빈이 상태를 가지면 안된다.

예를 들어 싱글톤 스코프의 빈이 value라는 상태를 가질 때 Thread 1은 value의 값을 증가시킨다고 가정해보자.

그리고 Thread2는 value라는 값을 가져와 사용한다고 하면 Thread2는 매번 다른 값을 사용할 수 있다.

해당 빈의 상태를 항상 예측할 수 없기 때문에 우리가 의도한 결과가 나올 수 없다.

그러므로 빈 스코프는 싱글톤으로 설정할 경우 상태를 가지면 안된다.

 

2. 의존성을 자동 주입해야 할 인터페이스의 구현체가 두 개 이상일 경우

@Repository
public class StationInMemoryStationDao implements StationDao {
}

@Repository
public class StationJdbcStationDao implements StationDao {
}

@Service
public class StationService {

		private final StationDao stationDao;

		public StationService(final StationDao stationDao) {
				this.stationDao = stationDao;
		}
}

의존성을 자동 주입해야할 인터페이스의 구현체가 두 개 이상이라면,

스프링은 어떤 구현체를 자동 주입할지 정하지 못해서 충돌이 일어나게 된다.

그렇다면 충돌로 인해서 다형성을 이용하지 못하는 건가?

어노테이션을 사용하여 의존성 주입 시 우선순위를 정하면 된다 - Primary, Qualifier