devlog

여러 가지 의존관계 주입방법이 있지만 생성자 주입을 사용하는 것이 권장된다. 대부분의 의존관계 주입이 일어나면 종료시점까지 의존관계를 변경할 일이 없고 대부분의 의존관계는 변하면 안 된다. 생성자 주입은 객체 생성 시 딱 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..

스프링 컨테이너는 다양한 형식의 설정 정보를 받아들릴 수 있게 설계되어 있다. 그중 XML로 설정해 보자 XML로 설정하기 위해선 AnnotationConfigApplicationContext 대신 GenericXmlApplicationContext를 사용해야 한다. ApplicationContext ac = new GenericXmlApplicationContext("appConfig.xml"); 그다음 appConfig.xml을 만들어 주어야 한다. xml에서 bean을 설정할 때 id, class를 작성해 주면 된다. 생성자로 의존성을 주입하려면 태그를 이용하면 된다. 속성으로 name, ref를 사용한다 name : 매개변수명으로 연결한다. (기존의 변수명과 동일해야 된다) ref :참조 자료형을..

스프링 컨테이너에서 스프링 빈을 조회하는 기본적인 방법 ac.getBean(빈이름, 타입) ac.getBean(타입) 스프링 빈이 없으면 예외가 발생한다 NoSuchBeanDefinitionException 구체 타입으로도 조회할 수 있는데 유연성이 떨어진다. 빈이 존재하지 않을 때는 assertThrows에 NoSuchBeanDefinitionException.class 에러로 테스트 코드를 작성해야한다. 여기서의 Assertions은 junit의 Assertions을 사용한다. 동일한 타입이 둘 이상인 경우 이렇게 동일한 MemberRepository에 대해 타입이 두개인 경우 NoUniqueBeanDefinitionException이 발생한다. 이 경우에는 빈 이름을 지정하면 해결이 된다. 특정 타..