당니의 개발자 스토리

빈 등록 초기화, 소멸 메서드 지정 이번 시간에는 빈을 등록하는 시점에서 "얘가 초기화야, 얘가 소멸이야" 라고 딱 지정해주는 방법이 있어요. 간단하게 @Bean에다가 initMethod랑 destroyMethod로 이름을 주면 됩니다. 코드로 바로 해보겠습니다. implements 부분이랑 import 한 부분 지워주고요. 이름도 맘에 안드니까 바꾸겠습니다. 직관적으로 init()과 close()로 바꿨습니다. 그 다음에 이제 BeanLifeCycleTest로 가서, 빈을 등록해주면 됩니다. 'networkClient를 빈으로 등록할 건데, 얘의 초기화 메서드는 init이고, 소멸 메서드는 close야' 하고 알려주는 겁니다. 다시 테스트를 돌려보겠습니다. 아까와 마찬가지로 잘 호출됐습니다. 간단하죠...

인터페이스 InitializingBean, DisposableBean 먼저 인터페이스로 초기화랑 소멸 전 콜백을 받는 방법에 대해서 알아보겠습니다. InitializingBean, DisposableBean 두 가지를 사용하면 되는데요. 바로 코드로 보여드릴게요. 우리가 만들었던 NetworkClient 에 들어가서, implements 해서 InitializingBean을 받습니다. 이름 그대로 초기화 빈이에요. option + enter 해서 메서드를 구현하면 됩니다. InitializingBean에 들어가보면, afterPropertiesSet() 메서드가 있죠. 프로퍼티들이 세팅이 끝나면, 그러니까 의존관계 주입이 끝나면 호출 해주겠다는 의미입니다. 여기에다가 뭘 호출해주면 될까요? 이 부분을 복..

8. 빈 생명주기 콜백 이번 시간부터는 이제 빈 생명 주기 콜백에 대해서 알아보겠습니다. 이거는 스프링 빈이 생성되거나 죽기 일보 직전에 스프링이 빈 안에 있는 메서드를 호출해줄 수 있는 기능이거든요. 되게 간단해요. 그래서 생성되고 나서 초기화할 때 호출하고, 또 빈이 사라지기 일보 직전에 안전하게 종료할 수 있는 메서드를 호출해주고 이런 간단한 내용인데, 하면 금방 끝낼 수 있는데, 세 가지 방식이 있거든요. 각 방식별로 특징이 있는데 거기에서 배울 게 있어요. 그래서 좀 내용을 풀어서 설명을 드리겠습니다. 현업에 있는 분들은 너무 당연하게 알텐데, 데이터베이스 커넥션 풀이라는 게 있어요. 우리가 보통 애플리케이션은 관계형 데이터베이스를 쓰거든요. 아니면 다른 데이터베이스를 쓰기도 하는데, 미리 애플..

자동, 수동의 올바른 실무 운영 기준 드디어 자동 의존관계 주입의 마지막 시간이네요. 마무리하는 겸 자동과 수동의 올바른 실무 운영 기준에 대해서 말씀드릴께요. 컴포넌트 스캔이랑 의존관계 자동주입 다 포함해 가지고요. 먼저, 편리한 컴포넌트 스캔이나 자동 의존관계 주입을 기본으로 사용하는 게 좋습니다. 고민이 되실 거예요. 어떤 경우에는 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에는 설정 정보를 통해서 수동으로 빈을 등록하고, 의존관계도 수동으로 주입하는 게 좋은지 고민이 되실 텐데, 결론부터 얘기하면 스프링이 나오고 시간이 갈수록 점점 자동으로 진화하고 있는 추세예요. 스프링은 @Component 뿐만 아니라 @Controller , @Service , @Repository 처럼 계층에 맞추어서..

조회한 빈이 모두 필요할 때, List, Map 이번 시간에는 조회한 빈이 모두 필요할 때, 리스트나 맵으로 한번에 조회하는 방법에 대해서 알아보겠습니다. 실무에서 쓸만한 예제로 말씀을 드리겠습니다. 의도적으로 정말 해당 타입의 스프링 빈이 다 필요한 경우가 있어요. 예를 들어서 우리가 할인과 관련된 어떤 서비스를 제공하는데, 클라이언트가 할인의 종류를 선택할 수 있는 거예요. 클라이언트가 "저는 비율로 할인해주세요", "저는 고정으로 할인해주세요" 라고 하면서 클라이언트가 선택할 수 있어요. 스프링을 사용하면, 소위 말하는 전략 패턴을 매우 간단하게 구현할 수가 있습니다. 제가 이거는 코드를 설명해 드릴게요. test의 autowired에다가 AllBeanTest를 만들겠습니다. 타입으로 조회된 모든 ..

애노테이션 직접 만들기 이번 시간에는 애노테이션을 직접 만들어 보겠습니다. 이것도 실무에서 한 번씩 사용하기 때문에 한번 보여드릴게요. 이전 시간에 @Qualifier를 배울 때 @Qualifier("mainDiscountPolicy") 이런 식으로 만들었는데, 여기에 문제가 한 가지 있어요. mainDiscountPolicy는 문자잖아요. 문자는 컴파일 타입 체크가 안 돼요. 그래서 annotation을 만들어서 좀 더 깔끔하게 운영할 수 있는 방법이 있습니다. 한번 보여드릴게요. 먼저 core에다가 annotation 이라는 패키지를 만들게요. 여기에다가 첫 번째로 MainDiscountPolicy 라는 애노테이션을 만들겠습니다. 애노테이션을 만들었는데, 만약 클래스로 만들었다고 해도 이걸 붙여주시면..

@Autowired 필드 명, @Qualifier, @Primary 이번 시간에는 여러 개의 빈이 선택이 될 때, 어떻게 해결하는지에 대한 3가지 방법을 하나씩 알아보겠습니다. 조회 대상 빈이 2개 이상일 때 해결 방법이 첫 번째는 @Autowired에 필드 명을 매칭시키는 방법이 있어요. 두 번째는 @Qualifier를 @Qualifier끼리 매칭시키는 게 있어요. 세 번째는 @Primary 라는 걸 사용하는 게 있습니다. 먼저, @Autowired에 필드 명을 매칭시킨다는 말은 @Autowired가 좀 특이한 기능이 있어요. @Autowired는 처음에 타입 매칭을 시도해요. 그런데 빈이 두 개잖아요? 여러 빈이 있으면, 필드 이름이나 파라미터 이름으로 빈 이름을 추가 매칭해요. 만약에 필드 주입이라..

조회 빈이 2개 이상 - 문제 이번 시간에는 조회할 빈이 2개 이상인 문제에 대해서 알아보겠습니다. @Autowired는 타입으로 조회를 한단 말이에요. 사실 @RequiredArgsConstructor에 의해서 final이 붙은 두 필드가 자동주입이 된다고 했습니다. @RequiredArgsConstructor에 의해서 생성자가 만들어져서, final 붙은 애들이 자동으로 의존관계 주입이 된다고 했죠. 조금 더 쉽게 설명드리기 위해서, @RequiredArgsConstructor를 빼고 생성자를 다시 만들게요. @Autowired를 하면, 생성자 파라미터로 들어가는 discountPolicy가 타입으로 조회되거든요. 스프링 컨테이너 안에서 Type으로 조회하기 때문에 ac.getBean(Discount..