싱글톤 빈 우리가 평소에 쓰던 스프링 빈은 기본적으로 싱글톤 스코프로 생성된다. 싱글톤은 클라이언트 A, B, C가 동시에 요청하든 따로 요청하던지 간에 같은 객체를 반환한다. @Test void singletonBeanFind() throws Exception{ AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class); System.out.println("================================"); SingletonBean singletonBean1 = ac.getBean(SingletonBean.class); SingletonBean singletonBean2 ..

콜백 메서드가 필요한 이유 애플리케이션 시작할 때 외부 네트워크와 연결을 하고, 종료 시점에 연결을 모두 종료하는 상황 애플리케이션 시작 시점에 NetworkClient를 생성하면서 connect를 통해 연결을 함 종료 시점에는 disconnect를 통해 연결을 끊기 빠른 결론 처음 이 부분을 공부했을 때, 머릿 속으로 도저히 이해가 되질 않았다. 그래서 이 글을 본 분들이나 미래의 나에게 빠른 이해를 돕고 싶다. 유치할 수도 있지만 빠르게 이해하기 위해서 각 코드 사이마다 숫자를 넣어보았다. 실행 순서를 알기 위함이지 의미 있는 숫자들은 아님!! BeanLifeCycleTest.class public class BeanLifeCycleTest { @Test void lifeCycleTest() thro..

다양한 의존관계 주입 방법 의존관계 주입은 생성자 주입, setter 주입, 필드 주입, 일반 메서드 주입이 있다. 생성자 주입 생성자를 통해 의존 관계를 주입 받는 방법 생성자가 딱 1개만 있으면 @Autowired를 붙이지 않아도 자동 주입 된다. private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy rateDiscountPolicy) { this.memberRepository = memberRepository; this.discountP..

@ComponentScan 이전에 우리는 빈 등록을 수동으로 등록했다. AppConfig에서 의존관계 주입을 하고, 거기에 @Bean을 입력하여 스프링 컨테이너에 빈 등록을 했다. 그러나 빈이 수 백개가 있다면 하나하나 빈을 등록해야 하기 때문에 번거로움이 있다. 그래서 등장한 것이 ComponentScan이다. ComponentScan은 설정 정보에 붙여주고, Component가 붙은 클래스를 찾아 빈으로 등록한다. 클래스를 찾을 때, 우리는 basePackages를 이용하여 탐색할 경로를 지정해줄 수 있다. default값은 ComponentScan이 있는 설정 정보 클래스의 패키지가 시작 위치가 된다. 그렇다면 빈은 등록이 됐지만, 의존관계 주입은 어떻게 해줄까? Component가 붙은 클래스에서..

싱글톤 패턴 AppConfig을 보면 객체를 호출할 때마다 새로운 객체를 생성한다. 그렇다면 고객이 동시에 요청을 했다면, 매 호출마다 새로운 객체를 생성해야해서 시간도 오래 걸리고, 메모리 낭비도 시하게 된다. 그래서 해당 객체를 한 개만 생성하고, 요청이 들어올 때마다 하나의 객체를 가지고 공유하는 싱글톤 패턴이라는 것이 있다. 싱글톤 패턴이란 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 싱글톤 패턴을 적용한 코드는 여러 종류가 있지만 그 중 하나인 private 생성자를 사용하여 외부에서 새로운 클래스 인스턴스를 막는다. SingletonService 객체를 private static final로 선언하고, getInstance 메서드를 통해서만 인스턴스를 얻을 수 있다...

빈 등록 빈을 등록하기 위해서는 @Bean 설정된 메서드를 모두 호출하게 된다!! 스프링 컨테이너에 저장하기 위해서이다 ApplicationContext를 스프링 컨테이너라고 한다. 모든 걸 관리해준다. AppConfig.class는 구성 정보가 저장된 클래스 (@Configuration)이다. 그래서 AppConfig에 있는 @Bean들을 모두 applicationContext라는 스프링 컨테이너에 저장(호출)을 한다. 여기서 이제 Bean을 get해야하는데, 이 때 getBean 메서드를 이용하여 가져온다. 이 때, getBean의 인자로는 Bean 이름과, 타입이 온다. Bean을 저장할 때, 메서드 이름으로 저장하기 때문에 메서드 이름을 인자로 사용하면 된다. 스프링 컨테이너에 등록된 빈 들의 이..

FixDiscountPolicy -> RateDiscountPolicy로 바꾸기 new 부분만 바꿔주면 된다. 하지만 여기서 중요한 부분이 있다. 현재 클래스는 분명 DiscountPolicy(추상적)에 의존하지만, FixDiscountPolicy, RateDiscountPolicy(구현체)에도 의존하고 있는 것이 보인다. 그래서 DIP 위배된다. 또한 클라이언트 코드를 변경하기 때문에 *OCP를 위반한다. OCP(Open/Closed principle) 계방-폐쇄 원칙 -> 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. ex) 기름차 -> 전기차로 변경할 때, 나는 운전면허증만 있으면 운전할 수 있어야 하는데, 나한테 뭘 요구함. 잘못된거임 생성자 주입 주석 처리 된 부분이 원래 구현체를 의존하는 ..

MemberServiceImpl은 MemberRepository interface를 의존한다. 그러나 실제 할당하는 인스턴스는 구현체를 의존함. --> 추상화와 구체화 모두 의존함. DIP 위반 *DIP(dependency inversion principle) 의존관계 역전 원칙 -> 구체화에 의존하지 말고, 추상화에 의존해야함. 설계가 잘되었다. 위 클래스(orderservice) 입장에서는 할인에 대해선 모름. 그냥 discountPolicy가 알아서 해줘라고 던져주는 것임. 만약 할인이 변경된다? 하면 할인 부분만 변경하면 됨. 전체 코드를 변경할 필요가 없음. --> *단일 책임 원칙이 잘 지켜짐. *SRP(Single responsibility principle) 단일 책임 원칙 -> 한 클래스..