당니의 개발자 스토리

롬복과 최신 트랜드 이번 시간에는 롬복과 최신 트렌드입니다. 의존관계 주입을 자동으로 해줄 때 생성자 주입이 다 좋긴 한데 좀 코드가 많아요. 그래서 최근에는 롬복이랑 라이브러리랑 섞어서 아주 기가 막힌 방법이 하나 있습니다. 막상 개발해보면 대부분 다 불변이에요. 거의 한 99% 불변이고 진짜 가끔 불변이 아닌 경우가 있거든요. 그래서 생성자에 final 키워드를 사용하게 돼요. 불변이니깐요. 그런데 참 귀찮은 게 생성자를 만들어야 되고, 주입받은 값을 대입하는 코드도 만들어야 돼요. 필드 인젝션 할 수 있으면 얼마나 좋을까요? 필드에다 @Autowired 하나 해주면 필드에 바로 딱 들어오는데, '필드 주입처럼 좀 편리하게 사용하는 방법이 없을까?' 이런 고민에서 시작하는 거죠. 역시 개발자는 귀찮은..

생성자 주입을 선택해라! 이번 시간에는 '생성자 주입을 선택해라!' 라고 굉장히 단언적으로 얘기를 하죠. 이전에 봤던 여러가지 주입 중에서, 왜 생성자 주입을 선택하는 게 좋은지 설명을 해드리겠습니다. 과거에는 수정자 주입과 필드 주입을 많이 사용을 했어요. 그런데 최근에는 스프링 뿐만 아니라, 다른 DI 프레임워크들도 대부분이 생성자 주입을 권장합니다. 그 이유는 다음과 같아요. 첫번째 불변입니다. 앞에서도 말씀드렸는데 대부분의 의존관계 주입은 처음에 딱 애플리케이션 조립할 때, 마치 비유를 하자면 공연을 하기 전에 배역이 다 정해지는 거예요. 그러면 애플리케이션이 종료할 때까지 의존관계를 변경할 일은 거의 없어요. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안 돼요. 그래서 목적 자체..

옵션 처리 이번 시간에는 옵션 처리에 대해서 알아보겠습니다. 주입할 Spring Bean이 없어도 동작해야 될 때가 있습니다. 예를 들어서, 스프링 빈을 옵션으로 해놓고, 이걸 등록을 안 해도 기본 로직으로 동작한다거나, 디폴트 로직이 동작한다거나 이런 식으로 동작해야 될 때도 있겠죠. 그런데 만약에 @Autowired 애노테이션을 사용하면 여기 내부에 required 라는 기본 옵션이 있는데, 기본값이 True예요. 값이 필수라는 의미겠죠. 그래서 자동 주입 대상이 없으면 무조건 오류가 발생합니다. 그래서 자동 주입 대상으로 스프링 컨테이너에 빈이 등록이 안 돼 있어도 문제 없이 되도록 할 수 있는 방법들이 있는데, 예제로 쭉 설명을 드릴게요. test의 hello.core에다가 패키지 autowire..

7. 의존관계 자동 주입 이번 시간부터는 의존관계 자동 주입에 대해서 알아보겠습니다. 먼저 다양한 의존관계 주입부터 시작해서, 어떻게 옵션 처리를 하는지, 그리고 다양한 방법 중에 어떤 방법이 좋은 건지 설명을 드리고요. 그 다음에 최신 트렌드도 말씀드릴게요. 그리고 문제점들을 해결하고 디테일하게 설명을 드리고요. 마지막에는 컴포넌트 스캔이나 자동 의존관계를 주입하는 거랑 수동으로 직접 @Bean으로 등록하는 거랑 실무에서는 하나의 애플리케이션이 두 개가 보통 섞여서 써지거든요. 그래서 어느 경우에는 자동으로 하고 어느 경우에는 수동으로 하는 게 좋은지 정리를 해드리겠습니다. 그래서 이번 시간에는 먼저 다양한 의존관계 주입 방법에 대해서 설명을 해드리겠습니다. 우선 의존관계 주입 방법은 크게 4가지가 있..

중복 등록과 충돌 이번에는 중복 등록과 충돌에 대해서 알아보겠습니다. 컴포넌트 스캔에서 같은 빈 이름이 등록되면 어떻게 될까요? 두 가지 상황이 있는데요. 자동 빈 등록, 그러니까 둘 다 컴포넌트 스캔한 빈인데 둘 다 이름이 똑같은 거예요. 이게 한 케이스고, 나머지 하나는 수동으로 빈을 등록한 거랑 자동으로 빈을 등록한 게 있어요. 이 경우는 진짜 많이 생기겠죠. 왜냐면 수동으로 해놨는데, 잘못해서 컴포넌트 스캔으로 등록한 거랑 보니까 둘이 똑같은 거예요. 그러면 꽝 충돌이 나겠죠. 먼저 자동 빈 등록과 자동 빈 등록을 하면, 컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되었는데, 또 등록이 돼요. 만약에 컴포넌트 스캔 했는데, 이름이 A가 있고 여기도 A가 있어요. 그러면 ConflictingBea..

필터 이번 시간에는 필터에 대해서 알아보겠습니다. 이름 그대로 includeFilters랑 excludeFilters가 있고요. 컴포넌트 스캔에 추가할 대상, 컴포넌트 스캔에서 제외할 대상을 각각 지정할 수가 있습니다. 빠르게 그냥 예제로 해볼게요. scan에다가 패키지를 만들어볼게요. filter라는 패키지를 만들겠습니다. 그리고 애노테이션을 만들 거예요. @Annotation을 고르구요. MyIncludeComponent 라는 애노테이션을 임의로 만드는 거에요. 애노테이션 관련해서는 공부를 하셔야 되는데, @Component에 들어가면, @Target 이라고 있습니다. 이거 세 개만 붙여넣기 해줍니다. 이 중에서 @Target이 중요한데, 이 애노테이션이 TYPE에 붙냐, FIELD에 붙냐 이런건데요..

탐색 위치와 기본 스캔 대상 이번 시간에는 컴포넌트 스캔의 탐색 위치와 기본 스캔 대상에 대해서 알아보겠습니다. 먼저, 탐색할 패키지의 시작 위치를 지정을 할 수가 있어요. 우리가 @ComponentScan 이라고 적었잖아요. 그 밑에 basePackages 라는 걸 적을 수가 있습니다. 우리 같은 경우에는 "hello.core"를 적을 수 있고, 이렇게 적으면 이 위치에서부터 시작해서 이 패키지를 포함한 하위 패키지를 모두 찾아들어가는 겁니다. 만약에 "hello.core.member" 로 바꾸면, 이 패키지부터 하위 패키지를 찾아가는 거예요. 그래서 이렇게 해버리면 member만 컴포넌트 스캔의 대상이 됩니다. 한번 돌려볼까요? 기존에 돌렸던 basicScan 테스트를 돌리면, memberServic..

6. 컴포넌트 스캔 이번 시간부터는 컴포넌트 스캔에 대해서 알아볼 건데요. 컴포넌트 스캔이랑 의존관계 자동 주입이라는 게 연결이 되어 있는 부분이 있어서 같이 쭉 설명을 드리겠습니다. 이번 시간은 컴포넌트 스캔과 의존관계 자동 주입에 대해서 시작을 해보겠습니다. 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 태그해서 해가지고 설정정보에 직접 스프링 빈으로 등록하는 정보를 나열을 했었죠. 예제에서는 한 4개 밖에 안됐으니까 괜찮은데, 이렇게 등록해야 할 bean이 실무에서는 수백개가 된단 말이에요. 그러면 일일이 등록하기가 굉장히 귀찮아져요. 그리고 설정 정보가 엄청 커지고, 개발자 친구들이 또 누락한단 말이에요. 무엇보다도 개발자는 반복을 싫어해요. 왜냐면 클래스 만들기도 귀찮은데..