Spring

자동 빈 등록을 기본으로 사용하자 어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에 설정 정보를 통해서 수동으로 빈을 등록하고, 의존관계도 수동으로 주입해야할까 → 자동을 선호하는 추세 스프링은 @Component뿐만 아니라 @Controller , @Service , @Repository 처럼 계층에 맞추어 일반적인 애플 리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있다 설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누는 것이 이상적 이지만, 개발자 입장에서 스프링 빈을 하나 등록할 때 @Component 만 넣어주면 끝나는 일을 @Configuration 설정 정보에 가서 @Bean 을 적..

할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자. 스프링을 사용하면 소위 말하는 전략 패턴을 매우 간단하게 구현할 수 있다 public class AllBeanTest { @Test void findAllBean() { ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class); DiscountService discountService = ac.getBean(DiscountService.class); Member member = new Member(1L, "userA", Grade.VIP); int discountPric..

@Autowired 는 타입(Type)으로 조회한다. 타입으로 조회하기 때문에, 마치 다음 코드와 유사하게 동작한다. ac.getBean(DiscountPolicy.class) 타입으로 조회하면 선택된 빈이 2개 이상일 때 문제가 발생한다 예를 들어서 DiscountPolicy 타입의 빈 2개가 등록되고 DiscountPolicy 타입의 빈을 주입받으려고 한다고 하자 @Component public class FixDiscountPolicy implements DiscountPolicy {} @Component public class RateDiscountPolicy implements DiscountPolicy {} @Autowired private DiscountPolicy discountPolicy..

생성자 주입을 하게 되면 필드에 fnal 키워드를 사용하고, 생성자 만들고 주입받을 값을 대입하는 코드를 만들어야한다. @Component public class OrderServiceImpl implements OrderService { private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(MemberRepository memberRepository, @MainDiscountPolicy DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this...

다양한 의존관계 주입 방법 생성자 주입 수정자 주입(Setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 생성자를 통해서 의존 관계 주입 생성자 호출 시점에 딱 1번만 호출되는 것이 보장 불변, 필수 의존관계에 사용 스프링 빈 등록될 때 자동으로 주입이 일어난다. (1단계로 다 빈등록 의존관계 주입) 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입이 된다. (스프링 빈에만 해당: 아래 코드에서는 @Component로 스프링 빈으로 등록함) @Component public class OrderServiceImpl implements OrderService { private final MemberRepository memberRepository; private final Disco..

컴포넌트 스캔과 의존관계 자동 주입 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다 이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀 찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다 아래 코드처럼 컴포넌트 스캔을 사용하려면 먼저 @ComponentScan 을 설정 정보에 붙여주면 된다. @Configuration //@ComponentScan: 스프링 빈을 다 끌어다가 자동으로 스프링 빈으로 끌어올리는.. @ComponentScan( //스프링 빈 등록에서 제외할 것 excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuratio..

웹 애플리케이션과 싱글톤 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다. 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸 → 메모리 낭비가 심하다. 해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다. → 싱글톤 패턴 싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다. → private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다. public class SingletonService { //1. static 영역에 객체를 딱 1개만..

스프링 컨테이너 생성 //스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class) ApplicationContext 를 스프링 컨테이너라 한다. new AnnotationConfigApplicationContext(AppConfig.class); 이 클래스는 ApplicationContext 인터페이스의 구현체이다. 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것이다. 스프링 컨테이너의 생성 과정 1. 스프링 컨테..

새로운 할일 정책 적용 할인 정책을 FixDiscountPolicy에서 RateDiscountPolicy로 변경하려고 한다. public class OrderServiceImpl implements OrderService { // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); } 문제점 위 코드처럼 할인 정책을 변경하려면 클라이언트인 OrderServiceImpl코드를 고쳐야 한다. SOLID의 원칙에 따르면 DIP와 OCP를 위반하고 있다. SRP: 단일 책임 원칙(single responsibi..