devlog

동일 타입으로 조회한 빈이 모두 필요한 경우가 있다. 예를 들어 고객이 RateDiscountPolicy를 선택해서 할인을 받을지 FixDiscountPolicy를 선택해서 할인을 받을지 고를 수 있다고 생각해 보자. 이를 위해 같은 타입의 빈을 List나 Map으로 받아와야 한다. @Autowired public DiscountService(Map policyMap, List policies) { this.policyMap = policyMap; this.policies = policies; } 이렇게 Map과 List로 의존관계를 주입 받을 수 있다. Map에는 빈 이름이 key 인스턴스가 value로 저장된다. List에는 각 인스턴스가 저장되어 있다. 이렇게 두개의 discountPolicy를 주..

@Autowired는 타입으로 조회한다 타입으로 조회하면 같은 타입의 빈이 2개 이상일 때 문제가 발생한다. 예를 들어 DiscountPolicy의 하위 타입인 FixDiscountPolicy, RateDiscountPolicy둘다 스프링 빈으로 등록시키고 @Autowired private DiscountPolicy discountPolicy 위와 같이 DiscountPolicy타입으로 의존관계를 주입하면 NoUniqueBeanDefinitionException오류가 발생한다. 해결방법으로 하위타입을 이용해서 의존관계를 주입하면 DIP를 위배하고 유연성이 떨어진다. 해결방법에는 크게 3가지가 있다. @Autowired 필드 명 매칭 @Qualifier사용 @Primary사용 @Autowired 필드 명 ..

여러 가지 의존관계 주입방법이 있지만 생성자 주입을 사용하는 것이 권장된다. 대부분의 의존관계 주입이 일어나면 종료시점까지 의존관계를 변경할 일이 없고 대부분의 의존관계는 변하면 안 된다. 생성자 주입은 객체 생성 시 딱 1번만 호출되므로 불변하게 설계할 수 있다. 수정자 주입을 사용하면 setter 메서드를 public으로 열어 두어야 하는데 이러면 실수로 누군가 변경할 수 있다. 프레임워크 없이 순수한 자바 코드를 단위 테스트 하는 경우에 쉽게 가능하다. 필드에 final 키워드를 사용할 수 있다. 그러면 설정되지 않으면 컴파일 오류로 막아준다. 위와 같은 장점으로 생성자 주입을 선택하는 것이 좋다. 그리고 가끔 필요하면 수정자 주입을 선택하면 된다. 생성자 주입을 좀 더 편하게 이용하기 위해 롬복 ..

의존관계 주입에는 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter) 필드 주입 일반 메서드 주입 생성자 주입 생성자를 통해서 의존관계를 주입하는 방법이다. 생성자 호출될 때 딱 1번만 호출된다 불변하고 필수 적인 의존관계에 사용한다. @Autowired public MemberServiceImpl(MemberRepository memberRepository) { this.memberRepository = memberRepository; } 보통 생성자 위에 @Autowired애노테이션을 붙여서 사용한다. 근데 생성자가 하나만 존재하면 @Autowired를 생략해도 자동주입이 된다. 수정자 주입 setter메서드를 통해서 의존관계를 주입하는 방법이다. 선택, 변경 가능성이 있는 의존관계에 ..

컴포넌트 스캔에서 대상을 추가하거나 제외할 대상을 선택할 수 있다. MyIncluderComponent, MyExcluderComponent 애노테이션을 만들어 보자 Annotation을 선택해서 만들어 주면 된다. @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface MyIncludeComponent { } @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface MyExcludeComponent { } 테스트로 BeanA와 BeanB를 만들어서 위 애노테이션을 사용해 보자 @MyIncl..

모든 클래스를 스캔하려면 시간이 오래 걸리기 때문에 스캔 시작 위치를 설정할 수 있다. @ComponentScan( basePackages = "hello.core", ) hello.core 패키지를 포함해서 하위 패키지를 모두 탐색한다. 여러개 지정도 가능하다. 만약 basePackages를 설정하지 않은 defalut값은 @ComponentScan 애노테이션이 붙은 클래스의 패키지로 설정된다. 그래서 권장하기를 따로 basePackages를 설정하지 않고 @ComponentScan 붙은 클래스를 프로젝트 최상단에 두는 것이다. 컴포넌트 스캔은 @Component뿐만 아니라 아래와 같은 애노테이션도 포함하여 스프링 빈에 등록한다 해당 클래스의 소스를 보면 @Component 애노테이션을 포함하고 있기 ..

@Bean이나 등의 설정 정보를 통해서 스프링 빈을 등록하는 방식은 스프링 빈이 많아 지면 귀찮기도 하고 누락될 수도 있다. 그래서 설정 정보가 없어도 자동으로 스프링 빈이 등록되는 컴포넌트 스캔이라는 기능을 제공한다. 컴포넌트 스캔을 사용하기 위해 Config 파일을 만들어 보자. @Configuration @ComponentScan public class AutoAppConfig { } Config 파일에는 @Configuration, @ComponentScan 두개의 애노테이션이 필요하다. 이전의 설정 정보를 이용해서 스프링 빈을 등록하는 AppConfig와는 다르게 @Bean으로 등록한 클래스가 없다. 컴포넌트 스캔은 @Component 애노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록해 준..

스프링 컨테이너를 등록할 때 사용하는 Appconfig.class를 보자 @Configuration public class AppConfig { @Bean public MemberService memberService() { System.out.println("call AppConfig.memberService"); return new MemberServiceImpl(memberRepository()); } @Bean public MemberRepository memberRepository() { System.out.println("casll AppConfig.memberRepository"); return new MemoryMemberRepository(); } @Bean public OrderServ..

객체 인스턴스를 하나만 만들어서 공유하여 사용하는 싱글톤 방식의 객체는 상태를 stateful 하게 설계하면 안 된다. stateless 하게 설계해야 한다. 즉 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 되고, 특정 클라이언트에 의존적인 필드가 있으면 안 된다. 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다. 문제점 예시를 보자 public class StatefulService { private int price; // 상태를 유지하는 필드, 공유되는 필드 public void order(String name, int price) { System.out.println("name = " + name + " privce = " +price..

웹 애플리케이션은 보통 여러 고객이 동시에 요청하는데 요청할 때마다 스프링 없는 순수한 DI 컨테이너는 객체를 생성해 준다. @Test @DisplayName("스프링 없는 순수한 DI 컨테이너") void pureContainer() { AppConfig appConfig= new AppConfig(); //1. 조회 : 호출할 때 마다 객체를 생성 MemberService memberService1 = appConfig.memberService(); //2. 조회 : 호출할 때 마다 객체를 생성 MemberService memberService2 = appConfig.memberService(); //참조값이 다른 것을 확인 Assertions.assertThat(memberService1).isNo..