빈 생명주기 콜백 네트워크 소켓처럼 어플리케이션 시작 시점에 필요한 연결을 미리 해두고, 어플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면 객체의 초기화와 종료 작업이 미리 필요하다. 미리 연결을 해두면 빠르게 처리가 가능하고, 종료 전에 객체의 종료가 완료되면 안전하게 종료할 수 있는 장점이 있기 때문이다. 이를 코드로 미리 한번 해보는 작업을 해보려고 한다. public class NetworkClient { private String url; public NetworkClient() { System.out.println("생성자 호출, url = " + url); connect(); call("초기화 연결 메세지"); } private void connect() { System.out..
빈 등록, 자동? 수동? 선택 기준은 무엇일까? 앞서 정리된 게시글들은 모두 스프링 빈을 자동, 수동으로 등록하는 것들에 대한 정리였다. 이번 정리글에서는 이런 수동, 자동등록들 중 어떤 것들을 주로 사용해야 될지에 대해 정리한다. 결론부터 말하면 자동을 위주로 사용하는 것이 좋다고 한다. 자동등록은 코드가 간결해지는 장점이 있으나, 의존관계 같은 것들이 명확하지 않다는 단점이 있다. 수동 등록은 의존관계를 명확하게 파악할 수 있으나, 등록해야 할 것들이 많아지면 매우 부담스럽게 작용한다. 최근 스프링에는 @Component 뿐만 아니라 @Controller, @Service @Repository 등의 어노테이션이 추가되면서 점점 자동등록에 힘을 싣고 있다. 개발이 복잡해질수록 등록해야 할 스프링 빈이 ..
조회한 빈이 모두 필요할 때? 이런 경우를 한번 생각해보자. 쇼핑몰에서 고객이 물건을 살 때 할인을 해준다고 가정하자. 이 때 할인 정책은 정액 할인 정책과 정율 할인 정책이 있다. 이 때, 할인 정책을 고객이 선택할 수 있는 경우를 가정해보자. 어떤 고객은 정율 할인 정책을 원할 것이고, 어떤 고객은 정액 할인 정책을 원할 것이다. 위 상황은 특정 할인 정책으로만 의존관계 주입이 필요한 것이 아니라, 입력이 오는대로 동적으로 의존관계 주입이 필요한 상황이다. 이럴 때는 조회된 2개 이상의 빈을 모두 불러와서, 그 중에 필요한 빈을 동적으로 사용해야한다. 이를 위해서 조회된 빈을 List나 Map 형식으로 가져오고, 여기서 필요한 빈으로 잠시 객체를 만든다. 그리고 그 객체를 활용해 할인 정책을 제공하는..
어노테이션 만들기 with @Qualifer 앞의 Qualifer를 활용한 경우 문제점을 보완하기 위해 어노테이션을 만든다. @Qualifier의 문제점은 @Qualifer 안에 있는 "xxxx"값이 문자열이라는 것이다. 예를 들어 @Qualifier("mainDiscountPolicy")라고 치고 싶은데, @Qualifer("maiiiiiinDiscountPolicy")처럼 의도치 않게 칠 수 있다. 이 경우, 문자 상태이기 때문에 코드 작성단계부터 에러를 감지하지 못한다. 어노테이션 만들기는 코드 작성단계부터 이런 오타를 잡아주기 위해 도입되었다고 보면 된다. 어노테이션 만들기 with @Qualifier 코드 @Target({ElementType.FIELD, ElementType.METHOD, El..
@Autowired에서 조회되는 빈이 2개 이상인 경우? @Autowired는 의존관계 주입 단계에서 요구하는 객체에 대해 같은 타입을 가지는 빈을 스프링 컨테이너에서 조회한다. 이 때 조회된 빈이 1개면 문제가 없다. 2개 이상일 경우, getBean(Type) 검색에서 빈이 2개 이상 조회되었을 때와 동일한 에러가 발생한다. 먼저 아래에서 조회되는 빈이 2개 이상이 되도록 유발해본다. @Component public class FixDiscountPolicy implements DiscountPolicy @Component public class RateDiscountPolicy implements DiscountPolicy 위와 같이 Component를 설정하면, 스프링 컨테이너에는 Discount..