개발 블로그 개발 블로그

스프링 빈의 라이프 사이클 (생성자 주입 등 몇 개는 제외) 객체 생성 -> 의존관계 주입 스프링 빈은 객체를 생성하고 의존관계 주입이 다 끝나고나서 필요한 데이터를 사용할 준비가 된다. 개발자는 자동 의존관계 주입을 했을 때 의존관계 주입이 끝나는 시점을 모르기때문에 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 기능을 제공한다. 또한, 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다. 스프링 빈의 이벤트 라이플사이클 스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료 초기화 콜백 : 빈이 생성되고 빈의 의존관계 주입이 완료된 후 호출 소멸전 콜백 : 빈이 소멸되기 직전..

@Component public class FixDiscountPolicy implements DiscountPolicy{ .... } @Component public class RateDiscountPolicy implements DiscountPolicy{ .... } 위와 같이 DiscountPolicy라는 빈이 2개 이상 존재할 경우에 어떻게 해결하면 좋을지에 대한 3가지 해결책이 존재한다. 1. Autowired에 필드명 매칭 @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this.di..

1. 생성자 주입 @Component public class MemberServiceImpl implements MemberService { private final MemberRepository memberRepository; @Autowired public MemberServiceImpl(MemberRepository memberRepository) { this.memberRepository = memberRepository; } // 생성자 주입 -> 추상화에만 의존 } 생성자를 통해서 스프링 컨테이너의 빈들의 의존관계를 주입하는 방법이다. 의존관계를 자동 주입하기를 원할 때 @RequiredArgsConstructor를 사용했다. 어노테이션 하나로 스프링 빈을 주입받을 수 있는 이유는 생성자 주입..

컴포넌트 스캔이란 빈을 따로 등록하지 않아도 @Component라는 어노테이션이 붙은 객체들을 스프링 컨테이너가 관리해주는 기능이다. @Configuration @ComponentScan( excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class) ) public class AutoAppConfig { } classes = Configuration.class는 AppConfig를 빼주는 용도이다. 보통 설정 정보를 컴포넌트 스캔 대상에서 제외하지 않지만 기존 예제 코드를 유지하기 위해서 이 클래스에서 제외하는 것을 했다. 코드를 보면 알겠지만 @Bean으로 따로 빈을 등록해주지 않았다...

@Configuration // Configuration이라고 선언 public class AppConfig { @Bean // 스프링 컨테이너에 등록 public MemberService memberService() { return new MemberServiceImpl(memberRepository()); } @Bean public MemoryMemberRepository memberRepository() { return new MemoryMemberRepository(); } @Bean public OrderService orderService() { return new OrderServiceImpl(memberRepository(), discountPolicy()); } @Bean public D..

스프링에서의 싱글톤 컨테이너 @Test @DisplayName("스프링 컨테이너와 싱글톤") void springContainer() { ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); MemberService memberService1 = ac.getBean("memberService", MemberService.class); MemberService memberService2 = ac.getBean("memberService", MemberService.class); // 참조값이 같은 것을 확인 System.out.println("memberService1 = " + memberService1); Sys..

간단한 웹 사이트를 제작하고 고객에게 웹 사이트를 보낸다고 가정해보자. 만약 웹 사이트를 설계할 때 스프링 없는 DI 컨테이너를 요청할 때마다 객체를 계속 실행한다면 실행할 때마다 그만큼의 객체가 계속해서 생성된다. 즉, 100명의 고객이 웹 사이트를 들어오면 100개의 객체가 생성되어서 효율적이지 않다. public class SingletonTest { @Test @DisplayName("스프링을 사용하지 않는 순수한 DI 컨테이너") void pureContainer() { AppConfig appConfig = new AppConfig(); // 1. 조회 : 호출할 때 마다 객체 생성 MemberService memberService1 = appConfig.memberService(); // 2..

객체지향 설계시 고려해야할 사항들 1. SRP 단일 책임 원칙 - 한 클래스는 하나의 책임만 가져야한다. 구현 객체를 생성하고 연결하는 책임은 구성만 관리하는 다른 Configuration 클래스를 생성해서 담당 클라이언트 객체는 실행 logic만 담당할 수 있게 함 2. DIP 의존관계 역전 원칙 - 프로그래머는 추상화에 의존하고 구체화에 의존 x 의존성 주입 원칙을 따르는 방법 생성자 주입 등을 통해서 새로운 객체를 주입하기 위해서는 구체화에 의존하지말고 추상화에 의존해야만 한다. 1번에서 말했던 Configuration 클래스에서 의존관계 주입을 통해 DIP 원칙을 따르면 된다. 3. OCP 원칙 - 소프트웨어 요소는 확장에는 열려 있으나 닫혀 있어야 한다. 애플리케이션을 사용 영역과 구성 영역으로..