클라우드 낚시꾼

1. 조회 빈이 2개 이상인 문제 // 1번 코드 @Autowired private DiscountPolicy discountPolicy // 2번 코드, ac는 스프링 컨테이너 변수명 ac.getBean(DiscountPolicy.class) @Autowired는 타입(Type)으로 조회한다. 그렇기에 위의 1번 코드와 2번 코드는 사실상 같은 코드이다. @Component public class FixDiscountPolicy implements DiscountPolicy {} @Component public class RateDiscountPolicy implements DiscountPolicy {} //의존관계 자동주입 실행 @Autowired private DiscountPolicy disco..

의존관계 주입 방법에는 다음과 같은 4가지가 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 이 글에서는 위 4가지의 의존관계 주입 방법과 @Autowired에 대해 알아볼 것이다. 1. @Autowired와 required @Autowired는 스프링 빈 클래스 내의 필드에 의존관계를 자동으로 주입한다. 참고로, 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다. 스프링 빈이 아닌 클래스에 @Autowired 코드를 적용해도 아무 기능이 작동하지 않는다. @Autowired의 옵션인 required는 해당 의존성이 필수인지를 나타내는데 사용된다. @Autowired의 디폴트 required 값은 true 이다. 즉, @Autowired가 붙은 곳에..

1. ComponentScan 탐색 위치 @ComponentScan 애노테이션이 붙은 설정 클래스로 스프링 컨테이너를 생성할 때, @Component 애노테이션이 붙은 클래스들은 Bean으로 등록된다. 그런데 @Component 애노테이션이 붙은 클래스들을 탐색할 때 시작점은 어딜까? basePackages: 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다. basePackageClasses: 지정한 클래스의 패키지를 탐색 위치로 지정한다. 미지정: @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다. 권장하는 방법 위와 같은 프로젝트 구조가 있다고 해보자. 설정 정보 클래스를 어디에다 둬야 될까? 권장되는 방법은 따로 탐색 위치를 지..

1. 스프링 빈 수동 주입의 불편함 위 코드처럼 스프링 빈을 수동으로 주입할 때는 @Configuration 설정 정보 클래스의 메서드에 @Bean을 붙여 스프링 Bean을 등록했다. 또한, Bean들 사이의 의존관계도 개발자가 일일이 설정해주었다. 만약 등록해야 될 @Bean이 10000개이면... 개발자가 일일이 10000개의 @Bean 어노테이션을 붙여야하며 복잡한 의존관계도 직접 설정해야 한다. 이러한 불편함을 해결하기 위해 스프링은 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능을 제공한다. 또한, 의존관계도 자동으로 주입하는 @Autowired 에노테이션도 제공한다. 2. 스프링 빈 자동 주입 과정 1 - @ComponentScan 컴포넌트 스캔을 사용하려면 @ComponentScan 애노테..

1. @Configuration과 싱글톤이 깨지는 것처럼 보이지만... AppConfig 클래스에 @Configuration 어노테이션을 사용했다. @Configuration이 붙은 클래스는 Spring의 설정 클래스로서 스프링 컨테이너에 Bean을 등록할 수 있게 해준다. 설정 클래스 AppConfig에는 @Bean 어노테이션이 붙은 3개의 메서드가 있다. 그래서 총 3개의 Bean이 싱글톤 객체로 컨테이너에 등록될 것이다. 왼쪽 그림은 등록된 Bean들 사이의 의존관계이다. 오른쪽 코드를 보면, memberService, orderService, memberRepository를 Bean으로 등록할 때 memberRepository 메서드가 3번 호출되어 싱글톤이 깨지는 것처럼 보인다. 하지만, 실상 ..

1. 싱글톤 패턴이 필요한 이유 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 순수 DI 컨테이너일 경우에는 고객이 요청을 보낼때 마다 객체를 생성할 것이다. 이능 굉장한 메모리 낭비를 유발한다. 만약, 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다. 이런 메모리 낭비 문제 때문에 고객의 요청이 동시에 발생할 경우에는 해당 객체를 딱 1개만 생성하고, 공유하도록 설계할 필요가 있다. 이것이 바로 싱글톤 패턴이다. 2. 싱글톤 패턴과 문제점 public class SingletonService { // 클래스의 인스턴스가 1개가 되도록 보장한다. // 구체 클래스에 의존 -> OCP 위반 private static final SingletonService single..

이 글에서 BeanDefinition과 스프링 빈을 조회하는 방법을 중점으로 빈에 대하여 알아 볼 것이다. 그럼 시작해보자! 1. BeanDefinition BeanDefinition은 Spring Framework에서 빈(Bean)의 메타 정보를 나타내는 인터페이스이다. 스프링 컨테이너에 스프링 빈을 등록할 때 BeanDefinition에 의해 빈 메타정보를 설정하게 되어 있다. BeanDefinition은 빈 이름, 역할, 스코프 등 다양한 정보를 제공한다. BeanDefiniton이 제공하는 정보는 아래를 참고하자. BeanDefinition (Spring Framework 6.1.4 API) Return the current bean class name of this bean definition...

이 글에서는 IoC(제어의 역전), DI(의존관계 주입)으로 스프링 컨테이너를 이해해 볼 것이다. 차근 차근 알아가보자. 1. IoC(Inversion of Control, 제어의 역전) IoC란 프로그램의 흐름이 외부에서 제어되는 것을 뜻한다. 이것을 라이브러리와 프레임워크의 차이로 이해해보자. JAVA를 사용하다보면 Scanner, List 등과 같이 유용한 기능을 제공하는 java.util 라이브러리를 사용하게 된다. 우리가 이 라이브러리를 사용했을 때 코드의 제어는 누가 가져가는가? 개발자가 가져간다. 라이브러리를 사용하더라도 코드의 실행 흐름은 개발자가 꾸민대로 진행된다. 다음으로, 우리가 Spring 프레임워크를 사용할 때를 생각해보자. 우리는 Spring이라는 Frame에 맞춰 작업을 한다...