Spring Core - DI

💡DI(Dependency Injection)

IoC라는 원칙을 구현하기 위해서 사용되는 방법 중 하나로, 용어를 있는 그대로 번역하면 `의존성 주입`입니다.

다음의 예시 코드를 보면 

 

실제 MemberService라는 객체에서 MemberRepository라는 객체에 의존성을 가지고 있습니다.

또, 아래에 구현된 세가지 메서드들은 모두 MemberRepository객체에서 구현한 메서드를 사용하고 있습니다.

이러한 상황에서 MemberRepository라는 객체를 다른 MockRepository 객체로 교체해야 할 경우 어떤 일이 일어날까요?

실제로 private final MemberRepository memberRepository = new MockRepository();로 변경하면 될까요?

 

이렇게 객체를 직접 변경하면 아래의 구현한 메서드들도 모두 변경되어야 합니다. 그리고 객체 간의 관계가 변경될 때다마 우리가 직접 해당 코드를 찾아 수정하고 문제점이 없는지 살펴보는 과정을 거쳐야 합니다. 이렇게 발생하는 문제점들은 의존성 주입을 통해 해결이 가능한데요. 

 

 

위 그림에서 작성된 코드와 같이 생성자를 통해 의존성을 주입받음으로써 우리는 객체가 생성되는 순간 의존관계를 주입할 수 있습니다. 위와 같이 수정하면 MemberService 객체를 생성할 때 직접 해당 파일에서 MemberRepository 객체를 생성해 생성자를 통해 넣어주어야 합니다. 그러면 객체를 생성할 때마다 결국 직접 주입할 객체를 우리가 작성해야 합니다.

 

이를 해결하기 위한 일차적인 방법으로는 다음과 같이 의존성 주입을 관리하는 설정 파일을 만들어 관심사 분리를 통해 해결할 수 있습니다.

package com.codestates;

import com.codestates.coffee.CoffeeRepository;
import com.codestates.coffee.CoffeeService;
import com.codestates.member.MemberRepository;
import com.codestates.member.MemberService;

//의존성 설정 파일
public class DependencyConfig {
    
    public MemberService memberService(){
        return new MemberService(memberRepository());
    }
    
    public MemberRepository memberRepository(){
        return new MemberRepository();
    }
    
    public CoffeeService coffeeService(){
        return new CoffeeService(coffeeRepository());
    }
    
    public CoffeeRepository coffeeRepository(){
        return new CoffeeRepository();
    }
}

이렇게 역할을 명확히 나누어 작성해준다면 더 이상 서비스 내부에서 객체 주입 관련해서 코드를 수정하지 않고, DependencyConfig.java에서 구현 부분만 수정해주면 됩니다.

즉, MemberService, CoffeeService는 생성자를 통해 어떤 구현 객체가 주입되는지 알 필요가 없고 오로지 실행에만 집중하면 됩니다.

 

이렇게 우리는 직접 설정 파일을 통해 의존성 주입을 할 수 있습니다.

하지만, 스프링 프레임워크를 사용하면 직접 설정 파일을 만들지 않아도 의존성 주입이 가능합니다.

 

 

 

 

💡스프링 컨테이너란?

스프링 컨테이너는 스프링 프레임워크의 핵심 컴포넌트로, 스프링 컨테이너 내부에 존재하는 애플리케이션 빈의 생명주기를 관리합니다.

 

 

보통 AppllicatioinContext를 스프링 컨테이너라고 하며, ApplicationContext는 인터페이스로 구현되어 있습니다.

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/ApplicationContext.html

ApplicationContext (Spring Framework 6.0.7 API)

스프링 컨테이너는 XML, 애너테이션 기반의 자바 설정 클래스로 만들 수 있으며, 예전에는 개발자가 xml을 통해 모두 설정해줬으나 이러한 복잡한 부분들을 Spring Boot를 사용하면서 거의 사용하지 않게 되었습니다. 스프링 컨테이너는 DI를 통해 애플리케이션의 컴포넌트를 관리하며, 서로 다른 빈을 연결해 애플리케이션의 빈을 연결하는 역할을 합니다.

 

왜 스프링 컨테이너를 사용할까?

객체를 사용하기 위해 new 생성자를 써야 했었는데, 애플리케이션에서 이러한 객체가 무수히 많이 존재하고 서로 참조하게 되어있으면, 객체 간의 의존성이 높아지고(클래스 간 강한 결합) 그렇게 되면 객체지향프로그래밍의 핵심 중 하나인 낮은 결합도와 높은 캡술화가 지켜지지 못하게 됩니다. 따라서 객체 간의 의존성을 낮추기 위해 스프링 컨테이너를 사용합니다.

 

 

스프링 컨테이너의 생성 과정

스프링 컨테이너는 파라미터로 넘어온 Configuration Metatdata를 사용해서 스프링 빈을 등록합니다.

// Spring Container 생성
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(DependencyConfig.class);

위 코드는 애너테이션 기반의 자바 설정 클래스로 Spring Container를 만드는 것을 의미합니다.

XML 기반으로 만드는 'ClassPathXmlApplicationContext'도 있습니다.

ApplicationContext 인터페이스의 구현체를 통해 다양하게 스프링 컨테이너를 만들 수 있습니다.

 

 

스프링 컨테이너의 종류

오브젝트의 생성과 오브젝트 사잉의 런타임 관계를 설정하는 DI 관점으로 볼 때는 스프링 컨테이너를 BeanFactory라 하고, DI를 위한 BeanFactory에 엔터프라이즈 애플리케이션을 개발하는 데 필요한 여러 가지 컨테이너 기능을 추가한 것을 ApplicationContext라고 합니다.

BeanFactory : 스프링 컨테이너의 최상위 클래스로 빈을 등록하고 생성하고 조회하고 돌려주는 등 빈을 관리하는 역할을 합니다. getBean() 메서드를 통해 빈을 인스턴스화할 수 있으며, @Bean이 붙은 메서드의 명을 스프링 빈의 이름으로 사용해 빈등록을 합니다.

 

ApplicationContext : BeanFactory의 기능을 상속받아 제공하며, 빈을 관리하고 검색하는 기능은 BeanFactory가 제공하고 그 외 부가기능을 제공합니다.

 

ApplicationContext가 제공하는 부가 기능

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

 

 

💡빈(Bean)

스프링 컨테이너에 의해 관리되는 재사용 소프트웨어 컴포넌트로 Spring 컨테이너가 관리하는 자바 객체를 의미하며, 스프링 컨테이너는 하나 이상의 빈을 관리합니다.

빈은 인스턴스화된 객체를 의미하며, 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 합니다. 

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

빈은 클래스의 등록 정보, getter/setter 메서드를 포함하며, 컨테이너에 사용되는 설정 메타데이터로 생성됩니다.

설정 메타 데이터는 XML 또는 자바 애너테이션, 자바코드로 표현하며, 컨테이너의 명령과 인스턴스화, 설정, 조립할 객체를 정의합니다.

 

bean 접근 방법

AppicationContext를 사용하여 bean 정의를 읽고 액세스 가능합니다.

// create and configure beans
ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");

// retrieve configured instance
PetStoreService service = context.getBean("memberRepository", memberRepository.class);

// use configured instance
List<String> userList = service.getUsernameList();

 

BeanDefinition

Bean은 BeanDefinition(빈 설정 메타정보)로 정의되고, BeanDefinition에 따라서 활용할 수 있는 방법이 달라지게 됩니다.

BeanDefinition은 속성에 따라 컨테이너가 Bean을 어떻게 생성하고 관리할지 결정합니다. @Bean or <bean> 당 1개의 메타정보가 생성됩니다. Spring이 설정 메타정보를 BeanDefinition 인터페이스를 통해 관리하기 때문에 컨테이너 설정을 XML, Java로 할 수 있는 것입니다. 

 

 

핵심 정리😉

스프링 IoC는 각 빈에 대한 정보를 담은 설정 메타정보를 읽어들인 뒤에, 이를 참고해 빈 오브젝트를 생성하고 프로퍼티나 생성자를 통해 의존 오브젝트를 주입해주는 DI 작업을 수행합니다. 이 작업을 통해 만들어지고, DI로 연결된 오브젝트들이 모여서 하나의 애플리케이션을 구성하고 동작하게 됩니다. 결국, 스프링 애플리케이션이란 POJO 클래스와 설정 메타정보를 이용해 IoC 컨테이너가 만들어주는 오브젝트의 조합입니다.  

 

 

Bean Scope

빈이 존재할 수 있는 버위로, 특정 bean 정의에서 생성된 개체에 연결할 다양한 의존성 및 구성 값 뿐만 아니라 특정 bean 정의에서 생성된 개체의 범위도 제어 가능합니다.

 

싱글톤 스코프

스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지되며, 싱글톤 빈의 하나의 공유 인스턴스만 관리하게 됩니다. (private 생성자를 사용해 외부에서 임의로 new를 사용하지 못하도록 막아야 함)

해당 bean definition과 일치하는 ID 또는 ID를 가진 빈에 대한 모든 요청은 스프링 컨테이너에서 해당 특정 빈 인스턴스를 반환합니다. 스프링 컨테이너 종료 시 소멸 메서드도 자동으로 실행됩니다. 기본적으로 모든 bean은 scope가 명시적으로 지정되지 않으면 싱글톤입니다.

 

 

Singleton 실습

package com.codestates;

import com.codestates.member.MemberService;

public class SingletonTest {
    static DependencyConfig dependencyConfig = new DependencyConfig();
    static MemberService memberService1 = dependencyConfig.memberService();
    static MemberService memberService2 = dependencyConfig.memberService();

    public static void main(String[] args) {
        System.out.println("memberService1 : " + memberService1);
        System.out.println("memberService2 : " + memberService2);
    }
}

같은 memberService를 사용하지만 뒤에 붙은 주소값이 다른 것을 볼 수 있습니다. 이렇게 수많은 객체를 생성하게 되면 위 방식은 메모리 낭비와 효율성이 떨어지게 됩니다.

 

싱글톤 패턴 적용 코드

package com.codestates.singleton;

public class SingletonService {
    //1.static 영역에 객체를 1개만 생성
    public static final SingletonService instance = new SingletonService();

    //2. 객체 인스턴스가 필요하면 아래 public static 메서드를 통해서만 조회할 수 있도록 함.
    public static SingletonService getInstance(){
        return instance;
    }

    //3. 생성자를 private을 선언하여 외부에서 new 키워드를 통해 객체를 생성할 수 없도록 함.
    private SingletonService(){

    }
}

package com.codestates;

import com.codestates.member.MemberService;
import com.codestates.singleton.SingletonService;

public class SingletonTest {
    static SingletonService singletonService1 = SingletonService.getInstance();
    static SingletonService singletonService2 = SingletonService.getInstance();

    public static void main(String[] args) {
        System.out.println("memberService1 : " + singletonService1);
        System.out.println("memberService2 : " + singletonService2);
    }
}

 

싱글톤 패턴의 문제점

싱글톤 패턴을 구현하는 코드 자체가 길고, 의존관계상 클라이언트가 구체 클래스에 의존하게 됩니다. 또, private 생성자를 사용하여 자식 클래스를 만들기 어렵기 때문에 유연성이 떨어집니다.

 

이러한 싱글톤 패턴 문제를 스프링 컨테이너가 해결해줍니다. 스프링 컨테이너는 싱글톤 컨테이너 역할을 합니다.

• private 생성자로 객체의 생성을 막는 방법이 아니라 일반 자바 클래스를 싱글톤으로 활용할 수 있도록 지원
• 생성, 관계 설정, 사용에 대한 제어권이 컨테이너에게 있기 대문에 일반 자바 클래스도 싱글톤으로 관리될 수 있음
• public 생성자를 사용할 수 있기 때문에 필요하다면 새로운 오브젝트를 생성하고, Mock 오브젝트로 대체하는 등의 작업이 가능.
• 객체지향적 설계와 디자인 패턴 적용 가능

이렇게 싱글톤 객체로 생성하고 관리하는 기능을 싱글톤 레지스트리라고 하며, 스프링 컨테이너의 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하며 객체를 싱글톤으로 유지 가능합니다.

 

package com.codestates;

import com.codestates.coffee.CoffeeRepository;
import com.codestates.coffee.CoffeeService;
import com.codestates.member.MemberRepository;
import com.codestates.member.MemberService;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

//의존성 설정 파일
@Configuration
public class DependencyConfig {
    @Bean
    public MemberService memberService(){
        return new MemberService(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository(){
        return new MemberRepository();
    }
    @Bean
    public CoffeeService coffeeService(){
        return new CoffeeService(coffeeRepository());
    }
    @Bean
    public CoffeeRepository coffeeRepository(){
        return new CoffeeRepository();
    }
}

package com.codestates;

import com.codestates.member.MemberService;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class SingletonTest {
    static AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(DependencyConfig.class);
    static MemberService memberService1 = ac.getBean("memberService", MemberService.class);
    static MemberService memberService2  = ac.getBean("memberService", MemberService.class);

    public static void main(String[] args) {
        System.out.println("memberService1 : " + memberService1);
        System.out.println("memberService2 : " + memberService2);
    }
}

 

싱글톤 방식 사용시 주의점

싱글톤 방식은 여러 클라이언트가 하나의 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 무상태로 설계해야 합니다.

특정 클라이언트가 값을 변경할 수 있으면 안되며, Read-only여야 합니다. 스프링 빈의 공유 값을 설정하면 장애가 발생할 수 밖에 없습니다.

 

 

💡Java 기반 Container 설정

@Bean과 @Configuration

//DependencyConfig 클래스
//컨텍스트를 인스턴스화할 때
@Configuration
public class DependencyConfig{
	@Bean
	public MyService myService() {
		return new MyServiceImpl();
	}
}

ApplicationContext 구현은 아래와 같은 애너테이션이 달린 클래스로 파라미터를 전달받고 있습니다.

• @Configuration 클래스가 입력으로 제공될 경우 : @Configuration 클래스 자체가 Bean 정의로 등록되도 클래스 내에서 선언된 모든 @Bean 메서드도 Bean 정의로 등록됩니다.
• @Component 클래스와 JSR-330 클래스가 제공될 경우 : 빈 정의로 등록되며 필요한 경우 해당 클래스 내에서 @Autowired 또는 @Inject와 같은 DI 메타데이터가 사용되는 것으로 가정합니다.

 

코드

@Configuration 클래스를 입력으로 사용한 경우

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(DependencyConfig.class);
    MyService myService = ctx.getBean(MyService.class);
    myService.doStuff();
}

 

@Component 또는 JSR-330 주석이 달린 클래스는 다음과 같이 생성자에 입력으로 사용

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(MyServiceImpl.class, Dependency1.class, Dependency2.class);
    MyService myService = ctx.getBean(MyService.class);
    myService.doStuff();
}

 

 

@Bean 애너테이션 사용하기

@Bean을 메서드에 추가해서 Bean으로 정의할 수 있습니다.

@Configuration
public class DependencyConfig {

    @Bean
    public TransferServiceImpl transferService() {
        return new TransferServiceImpl();
    }
}

 

Java 기반 컨테이너 설정

// DependencyConfig.java

package com.codestates.section2week4;

import com.codestates.section2week4.coffee.CoffeeRepository;
import com.codestates.section2week4.coffee.CoffeeService;
import com.codestates.section2week4.member.MemberRepository;
import com.codestates.section2week4.member.MemberService;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class DependencyConfig {
  @Bean
  public MemberService memberService() {
    return new MemberService(memberRepository());
  }
  @Bean
  public MemberRepository memberRepository() {
    return new MemberRepository();
  }
  @Bean
  public CoffeeService coffeeService() {
    return new CoffeeService(coffeeRepository());
  }
  @Bean
  public CoffeeRepository coffeeRepository() {
    return new CoffeeRepository();
  }
}

 

 

💡Component Scan

스프링은 설정 정보 없이 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공합니다.

앞에서는 스프링 빈을 등록할 때 자바 코드의 @Bean or XML  등의 설정 정보에 등록한 스프링 빈들을 직접작성을 해야 했습니다. 이렇게 수작업으로 등록하게 되면 설정 정보도 커지고, 누락하는 등 다양한 문제가 발생 가능합니다.

@ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록해주기 때문에 설정 정보에 붙여주면 됩니다. (의존관계도 자동으로 주입하는 @Autowired 기능도 제공합니다.)

package com.codestates.section2week4;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;

@Configuration
@ComponentScan
public class AutoDependencyConfig {

}

기존에 작성하던 DependencyConfig와 비교한다면 @Bean으로 등록한 클래스를 볼 수 없습니다. 단, ComponentScan을 사용하면 @Configuration이 붙은 정보도 자동으로 등록됩니다.(Configuration 내부에 @Component가 붙어있기 때문)

 

 

@Component, @Autowired 추가

@Component는 @ComponentScan이 등록된 곳에서 @Component를 가져오기 위해 사용됩니다. 

@Autowired는 생성자 의존성 주입에 필요한 설정 정보 대신 의존관계 자동 주입을 해주게 됩니다.

package com.codestates.section2week4.member;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class MemberService {

  private final MemberRepository memberRepository;
  
  @Autowired
  public MemberService(MemberRepository memberRepository) {
    this.memberRepository = memberRepository;
  }


  public void createMember(Member member) {
    memberRepository.postMember(member);
  }

  public Member getMember(Long memberId) {
    return memberRepository.getMember(memberId);
  }

  public void deleteMember(Long memberId) {
    memberRepository.deleteMember(memberId);
  }
}

package com.codestates.section2week4.coffee;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class CoffeeService {

  private static CoffeeRepository coffeeRepository;

  @Autowired
  public CoffeeService(CoffeeRepository coffeeRepository) {
    this.coffeeRepository = coffeeRepository;
  }

  public void createCoffee(Coffee coffee) {
    coffeeRepository.postCoffee(coffee);
  }

  public Coffee editCoffee(Long coffeeId, String korName, int price) {
    return coffeeRepository.patchCoffee(coffeeId, korName, price);
  }

  public Coffee getCoffee(Long coffeeId) {
    return coffeeRepository.getCoffee(coffeeId);
  }
  public void deleteCoffee(Long coffeeId) {
    coffeeRepository.deleteCoffee(coffeeId);
  }
}

package com.codestates.section2week4.member;

import org.springframework.stereotype.Component;

import java.util.HashMap;
import java.util.Map;

@Component
public class MemberRepository {

  private static Map<Long, Member> members = new HashMap<>();

  public void postMember(Member member) {
    members.put(member.getMemberId(), member);
  }

  public Member getMember(Long memberId) {
    return members.get(memberId);
  }

  public void deleteMember(Long memberId) {
    members.remove(memberId);
  }

}

package com.codestates.section2week4.coffee;

import org.springframework.stereotype.Component;

import java.util.HashMap;
import java.util.Map;

@Component
public class CoffeeRepository {

  private static Map<Long, Coffee> drinks = new HashMap<>();

  public void postCoffee(Coffee coffee) {
    drinks.put(coffee.getCoffeeId(), coffee);
  }

  public Coffee patchCoffee(Long coffeeId, String korName, int price) {
    Coffee drink = drinks.get(coffeeId);
    drink.setKorName(korName);
    drink.setPrice(price);

    return drinks.put(coffeeId, drink);
  }

  public Coffee getCoffee(Long coffeeId) {
    return drinks.get(coffeeId);
  }

  public void deleteCoffee(Long coffeeId) {
    drinks.remove(coffeeId);
  }

}

 

컴포넌트 스캔 기본 대상

@Component : 컴포넌트 스캔에서 사용됨.

@Controller, @RestController : 스프링 MVC 및 REST 전용 컨트롤러에서 사용됨.

@Service : 스프링 비즈니스 로직에서 사용됨.

@Repository : 스프링의 데이터 접근 계층에서 사용됨.

@Configuration : 스프링 설정 정보에서 사용됨.(해당 클래스의 소스 코드에는 @Component를 포함하고 있음)

 

 

💡다양한 의존관계 주입 방법

• 생성자 주입
• 수정자 주입(setter 주입)
• 필드 주입
• 일반 메서드 주입

생성자 주입

생성자에 @Autowired를 하면 스프링 컨테이너에 @Component로 등록된 빈에서 생성자에 필요한 빈들을 주입합니다.

 

특징)

• 생성자 호출 시점에 딱 1번만 호출되는 것이 보장됨.
• 불변과 필수 의존관계에 사용됨
• 생성자가 1개만 존재하는 경우에는 @Autowired를 생략해도 자동 주입됨
• NullPointerException을 방지할 수 있음
• 주입받을 필드를 final로 선언 가능

수정자 주입(setter 주입)

setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존 관계를 주입하는 방법

 

특징)

• 선택과 변경 가능성이 있는 의존관계에 사용됨.
• 자바 Bean 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법

@Component
public class CoffeeService {
  private MemberRepository memberRepository;
  private CoffeeRepository coffeeRepository;

  @Autowired
  public void setMemberRepository(MemberRepository memberRepository) {
    this.memberRepository = memberRepository;
  }

  @Autowired
  public void setCoffeeRepository(CoffeeRepository coffeeRepository) {
    this.coffeeRepository = coffeeRepository;
  }
}

생성자 주입과의 차이점은 생성자 대신 set 필드명 메서드를 생성하여 의존관계를 주입하게 된다는 것입니다.

수정자의 경우 @Autowired를 입력하지 않으면 실행되지 않습니다.

 

생성자는 1개일때 @Autowired가 없어도 작동이 되는 이유가 무엇?

스프링이 해당 클래스 객체를 생성하여 빈을 넣어야 하는데 생성할 때 생성자를 부를 수 밖에 없습니다. 그렇기 때문에 빈을 등록하면서 의존관계 주입도 같이 발생하게 됩니다.

 

필드 주입

필드에 @Autowired 붙여서 바로 주입하는 방법입니다.

 

특징)

• 코드가 간결해서 예전에 많이 사용된 방식이나, 외부에서 변경이 불가능하여 테스트하기 힘들다는 단점이 있습니다.
• DI 프레임워크가 없으면 아무것도 할 수 없습니다.
• 실제 코드와 상관없는 특정 테스트를 하고 싶을 때 사용 가능합니다.
• 정상적으로 작동되게 하려면 결국 setter가 필요해 수정자 주입을 사용하는 것이 더 편리합니다.

@Component
public class CoffeeService {
  @Autowired
  private MemberRepository memberRepository;
  @Autowired
  private CoffeeRepository coffeeRepository;
}

 

일반 메서드 주입

말그대로 일반 메서드를 사용해 주입하는 방법입니다.

 

특징)

• 한번에 여러 필드를 주입받을 수 있습니다.
• 일반적으로 사용되지 않습니다.

package com.codestates;

import com.codestates.member.Member;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.lang.Nullable;


import java.util.Optional;

public class AutowiredTest {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
    }

    static class TestBean{
        @Autowired(required=false) //자동 주입할 대상이 없으면 수정자 메서드 자체가 호출되지 않음.
        public void setNoBean1(Member noBean1){
            System.out.println("noBean1 = "+noBean1);
        }

        @Autowired
        public void setNoBean2(@Nullable Member noBean2){//자동 주입할 대상이 없으면 null이 입력됨.
            System.out.println("noBean2 = " + noBean2);
        }

        @Autowired
        public void setNoBean3(Optional<Member> noBean3){//Optinoal.emty가 입력됨.
            System.out.println("noBean3 = " + noBean3);
        }
    }
}

 

생성자 주입을 사용해야 하는 이유

• 불변
  • 의존관계 주입은 처음 애플리케이션이 실행될 때 대부분 정해지고, 종료 전까지 변경되지 않고 변경되어서는 안됨.
  • 수정자 주입 같은 경우에는 이름 메서드를 public으로 열어두어 변경이 가능하기 때문에 적합하지 않음.
  • 누군가 실수로 변경할 수도 있고, 애초에 변경하면 안되는 메서드가 변경할 수 있게 설계하는 것은 좋은 방법이 아님.
  • 생성자 주입은 객체를 생성하 때 최초로 1번만 호출되고 그 이후에는 다시는 호출되는 일이 없기 때문에 불변하게 설계할 수 있음.
• 누락
  • 호출했을 때는 NPE(Null Pointer Excpetion)이 발생하는데 의존관계 주입이 누락되었기 때문에 발생함.
  • 생성자 주입을 사용하면 주입 데이터 누락 시 컴파일 오류가 발생함.
• final 키워드 사용 가능
  • 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있음.
  • 생성자에서 값이 설정되지 않으면 컴파일 시점에서 오류를 확인 할 수 있음.
  • java: variable (데이터 이름) might not have been initialized
  • 생성자 주입을 제외한 나머지 주입 방식은 생성자 이후에 호출되는 형태이므로 final 키워드를 사용 불가
• 순환 참조
  • 순환 참조를 방지할 수 있음.
  • 개발하다보면 여러 컴포넌트 간에 의존성이 생기게 됨 (A→B를 참조하고, B→ A를 참조)
  • 필드 주입과 수정자 주입은 빈이 생성된 후에 참조를 하기 때문에 애플리케이션이 어떠한 오류와 경고 없이 구동됨
    • 실제 코드가 호출될 때까지 문제를 알 수 없음.
  • 생성자를 통해 주입하게 되면 BeanCurrentlyInCreationException이 발생하게 됨.