JArchive 프로그래밍 일기

김영한님의 실전! 스프링부트와 JPA활용1  을 학습하고 복습을 위해 포스팅한다. 

목표

* 실무에 가까운 예제 스프링 프로젝트를 만들면서 jpa에 대한 감을 잡는다. 

* 도메인 주도 설계를 이해한다. 

목차

1. 프로젝트 환경설정
2. 도메인 분석 설계
3. 애플리케이션 구현준비: 요구사항 및 아키텍처
4. 회원 도메인 개발
5. 상품 도메인 개발
6. 주문 도메인 개발
7. 웹 계층 개발

내용출처 : 김영한님의 실전! 스프링부트와 JPA활용1  

목표

1. 빈 생명주기 콜백 시작

2. 인터페이스 InitializingBean, DisposableBean (이번 포스팅)

3. 빈 등록 초기화, 소멸 메서드 

4. 애노테이션 @PostConstruct, @PreDestroy

2.  인터페이스 InitializingBean, DisposableBean 

1) 초기화 콜백: InitializingBean 인터페이스를 구현하자.

들어가보면, afterPropertiesSet() 메서드가 있다. 
"프로퍼티들의 세팅이 끝나면, 즉 의존관계 주입이 끝나면" 호출하는 메서드라는 뜻이다. 

의존관계 주입 후, 초기화 메서드 afterPropertiesSet() 가 호출된다. 

2) 소멸 전 콜백: DisposableBean 인터페이스를 구현하자.

destroy() 메서드는 빈이 소멸될 때 호출된다. 

두 개의 인터페이스를 구현한 후의 코드. 

이전 시간에 작성한 NetworkClient 테스트코드를 실행하고 출력을 확인하자.

스프링 컨테이너를 생성하고 빈을 조회하고, 컨테이너를 종료하는 내용이었다. 

객체 생성(생성자 호출)때는 당연히 url이 값이 없다. 

초기화 콜백  : 의존관계 주입 직후, connect() , call() 이 호출됬다. 

소멸전 콜백  : 컨테이너 종료(빈 소멸) 할 때 close를 출력하는 distroy()가 호출됬다. 

3) 초기화, 소멸 인터페이스의 단점

• 이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
• 초기화, 소멸 메서드의 이름을 변경할 수 없다.
• 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다. 
• 인터페이스 방식은 2003년에 나온 방법이고, 지금은 더 나은 방법들이 있어서 거의 안 쓴다.

3. 빈 등록 초기화, 소멸 메서드 

설정 정보에 @Bean(initMethod = "메서드이름" , destroyMethod = "메서드이름") 으로 초기화, 소멸 메서드를 지정할 수 있다. 

1) 특징 

* 메서드 이름을 자유롭게 줄 수 있다.

* '설정 정보'를 사용하니까 외부 라이브러리에도 초기화, 소멸 메서드를 적용할 수 있다. 

2) 종료 메서드 추론 (inferred)

@Bean( destroyMethod = "메서드이름")에 특별한 기능이 있다. 

대부분 (외부)라이브러리의 종료 메서드 이름이 close, shutdown 임을 이용한 기능이다. 

@Bean 의 destroyMethod의 기본값이 (inferred) 로 등록되어 있다.

그래서 직접 스프링 빈으로 등록하면, close, shutdown 이름의 메서드를 자동으로 호출해준다. 

추론 기능을 사용하지 않으려면, @Bean( destroyMethod = "") 처럼 공백을 지정하면 된다.

4. [권장] 애노테이션 @PostConstruct, @PreDestroy 

내가 정의한 메서드에 애노테이션을 붙이는 방법이다. 편리하다. 

1) 특징 

* 최신 스프링에서 가장 권장하는 방법이다. 

* 패키지가 javax 로 시작하는데. 자바 표준이라는 의미다. 따라서 스프링이 아닌 다른 컨테이너에서도 잘 동작한다. 

* 유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 

* 외부 라이브러리에는 @Bean(initMethod = "메서드이름") 방식을 쓰자. 

다음 시간에는 빈 스코프를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 빈 생명주기 콜백 시작 (이번 포스팅)

2. 인터페이스 InitializingBean, DisposableBean

3. 빈 등록 초기화, 소멸 메서드 

4. 애노테이션 @PostConstruct, @PreDestroy

1.  빈 생명주기 콜백 시작

데이터베이스 커넥션 풀이나 네트워크 소켓처럼 tcp ip handshaking 등 연결을 위한 작업이 좀 많은 경우, 

미리 연결을 해두고 요청이 오면 연결을 바로 재활용 한다. 소켓도 미리 잡아놓아야 요청이 왔을 때 즉시 응답을 줄 수 있다. 

이런 건 애플리케이션 시작 시점에 필요한 연결을 미리 해둬야 한다.

DB 연결 종료와 소켓 닫는것도 애플리케이션 종료 직전에 해둬야 한다. 

이번 시간에는 스프링을 통해 객체의 초기화 작업과 종료 작업을 어떻게 진행하는지 예제로 알아보자. 

간단하게 외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가정해보자. 

실제 네트워크에 연결하는 건 아니고 문자만 출력한다. 

1) NetworkClient 클래스 

• 애플리케이션 시작 시점에 connect() 를 호출해서 연결을 맺어두어야 한다.
• 애플리케이션이 종료되면 disConnect() 을 호출해서 연결을 끊어야 한다. 

생성자에서 connect()를 호출하도록 했다. 

2) NetworkClient 클래스 테스트 코드 

1. 애플리케이션을 시작할 때 스프링 빈이 등록된다. 

    -> NetworkClient 클래스의 생성자에서 connect() 가 호출된다. 

// 스프링 컨테이너 생성
ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);

2. 애플리케이션 종료할 때 스프링 컨테이너의 close() 를 호출한다. 

ac.close();

 출력 결과는 아래와 같다. 

너무 당연한 얘기지만, 빈이 등록될 때 생성자를 호출하는데 이 때는 url 이 없으니까 url 이 null 로 출력된다. 

3) 스프링 빈의 라이프 사이클 

객체 생성 -> 의존관계 주입 

스프링 빈은 객체를 생성하고, 의존관계 주입이 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다.

즉, 의존관계 주입이 끝나야 필드나 메서드를 변경하거나 사용할 수 있게 된다는 의미다. 필드를 수정하는 이러한 작업을 초기화 작업이라고 한다. 

객체 생성 -> 의존관계 주입 -> 초기화 작업 가능 시점 

4) 개발자는 초기화 작업을 할 수 있는 시점을 어떻게 알까 ?

스프링은 의존관계 주입이 끝나면, 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려준다. 

그리고 스프링 컨테이너가 종료되기 직전에, 소멸 콜백을 준다. 따라서 안전하게 종료 작업을 진행할 수 있다. 

스프링 빈의 이벤트 라이프사이클 

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용
-> 소멸전 콜백 -> 스프링 종료 

 * 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출되는 콜백.

 * 소멸전 콜백 : 빈이 소멸되기 직전에 호출되는 콜백.

5) 객체의 생성과 초기화를 분리하자 

생성자는 필수 정보만 파라미터로 받아서 메모리를 할당해서 객체를 생성하는 것만 해야 한다. 딱 생성하는 것에만 집중해야 한다. 

반면에 초기화는 외부 커넥션을 생성하는 등 무거운 동작을 수행한다. 

대부분의 경우, 둘을 합쳐놓는 것 보다는 객체 생성과 초기화를 분리하는 것이 유지보수 관점에서 좋다. 

물론 초기화 작업이 내부 값을 약간 변경하는 정도의 단순 작업이면 생성자에서 다 처리하는 것이 나을 수 있다. 

6) 객체의 생성과 초기화를 분리했을 때 장점

이런 것을 '지연' 이라고 하는데. 

예를 들어, DB 커넥션 풀을 애플리케이션 시작 할 때 100개 연결 생성만 만들어 둔다고 하자. 이 때 초기화는 안 한다. 
최초에 액션이 (실제 요청이) 들어오면 초기화를 해서 사용하는 동작을 지연시키는 장점이 있다. 

[ 참고 ] 

스프링 컨테이너가 종료될 때 싱글톤 빈들이 함께 종료된다. 그래서 스프링이 종료될 때 소멸전 콜백이 일어난다. 

뒤에서 '스코프'를 설명할 때 자세히 배우겠지만, 생명주기가 짧은 빈들은 스프링 컨테이너 종료와는 무관하게 해당 빈이 종료하기 직전에 소멸전 콜백이 일어난다. 

스프링은 3가지 방법으로 빈 생명주기 콜백을 지원한다. 다음 시간에 배우자. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 다양한 의존관계 주입 방법 

2. 옵션 처리 

3. 생성자 주입을 선택해라!  

4. 롬복과 최신 트랜드

5. 조회 빈이 2개 이상 - 문제

6. @Autowired 필드 명, @Qualifier, @Primary

7. 애노테이션 직접 만들기 

8. 조회한 빈이 모두 필요할 때 List, Map (이번 포스팅)

9. 자동, 수동의 올바른 실무 운영 기준

8.  조회한 빈이 모두 필요할 때 List, Map에 담기 

고객이 주문할 때 할인 정책을 어떤 것을 이용할지(Rate or Fix) 선택할 수 있게 됬다. 

인터페이스 DiscountPolicy 를 구현한 클래스 RateDiscountPolicy와 클래스 FixDiscountPolicy 는 타입이 똑같다. 

타입이 같은 스프링 빈을 둘다 등록해서 사용해야 한다. 어떻게 해결할 수 있을까? 

1) AutoAppConfig.class -> 컴포넌트 스캔 및 Autowired 로 스프링 빈을 생성하고 의존관계를 주입한다. 

2) DiscountPolicy.class -> DiscountPolicy 타입의 스프링 빈을 등록한다. 

DiscountPolicy 타입들의 빈을 Map 에 담을 때 { 스프링 빈 이름 = 인스턴스 레퍼런스} 쌍으로 담겨있다. 

policyMap = 
{fixDiscountPolicy=hello.corebasic.discount.FixDiscountPolicy@5d1659ea, 
rateDiscountPolicy=hello.corebasic.discount.RateDiscountPolicy@793138bd}

DiscountPolicy 타입들의 빈을 List에 담을 때  [ 인스턴스 레퍼런스 , 인스턴스 레퍼런스, ... ]  로 담겨있다. 

policyList = 
[hello.corebasic.discount.FixDiscountPolicy@5d1659ea, 
hello.corebasic.discount.RateDiscountPolicy@793138bd]

3) 고객이 10000원 주문했다면, VIP 고객일 때 1000원의 할인금액이 계산되는지 확인하자. 

discount() 메서드 : 고객의 주문 금액과 할인코드 문자열을 입력받아서 할인금액을 리턴하는 메서드가 필요하다. 

3) DiscountService.class  에  discount() 메서드를 작성한다. 

"할인코드"에 대응하는 "스프링 빈"이름을 찾아서 인스턴스를 꺼낸다.

인터페이스 DiscountPolicy 에 선언된 discount() 메서드를 호출하여 할인금액을 계산하여 리턴한다. 

rate 할인 정책일 때와 fix 할인 정책일 때의 discount() 메서드 구현 내용은 다르다. -> 다형성을 기반으로 유연한 전략 패턴 제공

4) rate 할인 정책일 때와 fix 할인 정책에 맞게 할인금액을 계산하는지 테스트 코드를 작성해서 확인한다. 

9.  자동, 수동의 올바른 실무 운영 기준 

1) 편리한 자동 기능을 기본으로 사용하자. 

스프링은 점점 자동화를 선호하는 추세로 발전하고 있다. 최근에 범용으로 쓰는 스프링 부트는 컴포넌트 스캔을 기본으로 사용한다. 

설정 정보를 기반으로 애플리케이션을 구성하는 구분과, 실제 동작하는 부분을 명확하게 나누는 것이 이상적이긴 하다. 

하지만 개발자 입장에서는 일일히 @Configuration 설정 정보에 가서 @Bean 을 적고 객체 생성, 주입 하는 것은 고역이다. 프로젝트가 커지면 수 백개 클래스에 이 작업이 필요하다. 

그리고 결정적으로 자동 빈 등록을 사용해도 DIP와 OCP를 지킬 수 있다.

2) 수동 빈 등록은 언제 사용해야 좋을까? 

애플리케이션 개발해보면 비즈니스 업무 로직과 기술 지원 로직으로 나뉜다. 

* 업무 로직 빈
: 비즈니스 요구사항에 따라 변경된다.
웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층 로직을 처리하는 리포지토리. 

* 기술 지원 빈

: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 로직을 지원하기 위한 하부 기술이나 공통 기술. 
DB 연결이나 공통 로그 처리 등이 있다. 

애플리케이션에 광범위하게 영향을 주는 기술지원 객체는
수동 빈으로 등록해서 설정 정보에 딱! 티나게 나타내는 것이 유지보수 하기 좋다.

* 업무 로직 빈의 경우, 굉장히 개수가 많지만 어느 정도 유사한 패턴이 있다. -> 자동 빈 사용이 적절하다. 

* 기술 지원 빈의 경우, 업무 로직 빈에 비해 개수가 매우 적다. 하지만 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미친다. 올바르게 동작하고 있는지 파악하기가 어려운 경우가 많다. -> 수동 빈 사용이 적절하다. 

3) 비즈니스 로직 중에서 다형성을 적극 활용할 때 수동 빈을 쓰자 

방금 전에 DiscountPolicy 인터페이스의 다형성을 기반으로 적절한 인스턴스를 쓰는 방법을 배웠다. 

하지만 실무에서 이러한 코드를 만나면, 인터페이스의 다형성을 이용한다는 점을 바로 알기 어렵다.

자동 등록을 사용하고 있기 때문이다. 파고 들어가야 한다. 
   " DiscountPolicy 관련이긴 한데 Map 은 왜 쓰지 ... (어리둥절) " 내가 할 땐 좋은데. 남이 해논 추상화가 힘들 때가 있다.

다형성을 적극 활용하는 경우에는 이 부분을 별도의 설정 정보로 만들고 수동 등록하자. 

   " DiscountPolicy 에는 rate와 fix가 있구나! " -> 한 눈에 들어온다. 유지보수에 훨씬 도움되는 구조!

그리고 반드시 특정 패키지에 같이 묶어둬야 한다. 

결론 :
자동을 하든 수동을 하든, 다형성을 사용할 땐 한눈에 들어오도록 신경써줘야 한다. 혼자 개발하는게 아니기 때문이다.

다음 강의에서는 빈 생명주기 콜백을 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 다양한 의존관계 주입 방법 

2. 옵션 처리 

3. 생성자 주입을 선택해라!  

4. 롬복과 최신 트랜드

5. 조회 빈이 2개 이상 - 문제

6. @Autowired 필드 명, @Qualifier, @Primary

7. 애노테이션 직접 만들기 (이번 포스팅)

8. 조회한 빈이 모두 필요할 때, List, Map

9. 자동, 수동의 올바른 실무 운영 기준

7.  애노테이션 직접 만들기

지난 시간에 @Qualifier에 @Qualifier("mainDiscountPolicy") 이름을 지정해서 사용했다. 

그런데 컴파일러는 @Qualifier("mainnnDiscountPolicy")  라는 실수가 있는지 @Qualifier("nainDiscountPolicy")  인지 모른다.

이런 문자 실수는 컴파일 타임에 잡을 수 없다. 

@Qualifier 용도로 쓸 @MainDiscountPolicy 라는 애노테이션을 만들어서 해결하자. 

1) 애노테이션 파일 MainDiscountPolicy 를 생성한다. 

2) @Qualifier 에 있던 애노테이션들을 다 복사해서 애노테이션 파일 MainDiscountPolicy 에 붙여넣는다. 

Qualifier 용도의 애노테이션이니까 @Qualifier("mainDiscountPolicy") 도 넣어준다. 

3) rate할인정책에 main할인정책이라는 @Qualifier 애노테이션을 붙이고 싶다. 

4) 혹시 @MainnnDiscountPolicy 로 애노테이션 이름에 에러가 나면? 

바로 컴파일 에러가 난다. 

5) RateDiscountPolicy 를 의존관계로 주입하려는 클래스 OrderServiceImpl 코드를 열어보자. 

DiscountPolicy 에 @Qualifier 를 지정하되, 방금 만든 @MainDiscountPolicy를 쓰자. 

6) 로그를 보면 정상적으로 스프링 빈이 등록되고 의존관계도 주입됬음을 확인할 수 있다. 

Creating shared instance of singleton bean 'orderServiceImpl'
Autowiring by type from bean name 'orderServiceImpl' via constructor to bean named 'memoryMemberRepository'
Autowiring by type from bean name 'orderServiceImpl' via constructor to bean named 'rateDiscountPolicy'

OrderServiceImpl 싱글톤 빈이 생성됬고,

생성자를 통해 memoryMemberRepository와 rateDiscountPolicy 빈이 의존관계 주입이 됬다.

다음 강의에서는 조회한 빈이 모두 필요할 때 List, Map 으로 처리하는 방법을 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 다양한 의존관계 주입 방법 

2. 옵션 처리 

3. 생성자 주입을 선택해라!  

4. 롬복과 최신 트랜드

5. 조회 빈이 2개 이상 - 문제  (이번 포스팅)

6. @Autowired 필드 명, @Qualifier, @Primary

7. 애노테이션 직접 만들기

8. 조회한 빈이 모두 필요할 때, List, Map

9. 자동, 수동의 올바른 실무 운영 기준

5. 조회할 빈이 2개 이상일 때의 문제 해결하기

@Autowired 는 타입으로 빈을 조회한다.

1) 만약 타입이 같은 빈이 2개가 조회되면 문제가 생길까? 

인터페이스 DiscountPolicy의 구현체 2개가 있다. RateDiscountPolicy와 FixDiscountPolicy 는 타입이 같다. 

RateDiscountPolicy 만 컴포넌트 스캔으로 스프링 빈 등록했었는데. FixDiscountPolicy도 스프링 빈 등록하려고 한다. 

스프링 빈 등록을 위해 컴포넌트 스캔을 하자.

2) orderServiceImple 에서 의존성 예외 발생했는데, DiscountPolicy 싱글 빈이 매칭되기를 기대했는데, 2개가 발견됬기 때문이다. 

beans.factory.UnsatisfiedDependencyException: 
Error creating bean with name 'orderServiceImpl' Unsatisfied dependency 
nested exception is NoUniqueBeanDefinitionException: 
No qualifying bean of type 'DiscountPolicy' available: 
expected single matching bean but found 2: fixDiscountPolicy,rateDiscountPolicy

@Autowired 로 의존관계를 주입하려고 DiscountPolicy 타입의 스프링 빈을 뒤져봤더니

1개 매칭을 기대했는데, 2개의 스프링 빈이 RateDiscountPolicy와 FixDiscountPolicy 발견되서 에러가 났다. 

3) 하위 타입인 fixDiscountPolicy 나 rateDiscountPolicy 를 적어야 할까? 아니다. 하위타입에 의존하면 DIP를 위반한다. 

다음 시간에 해결책을 배워보자. 

6. @Autowired 필드 명, @Qualifier, @Primary

타입이 같은 빈이 여러개 조회되면, 3가지 방법으로 해결할 수 있다.

1) @Autowired 필드 명을 매칭한다

@Autowired 의 스프링 빈 조회 순서->   1. 타입 매칭,  2. 필드 명 또는 파라미터 명을 매칭 

@Autowired 는 가장 먼저 스프링 빈의 타입을 매칭해보고. 빈이 2개 이상 조회되면 필드 명을 확인해서 매칭되는 하나를 조회한다. 

이전 코드 

@Autowired 필드 명을 매칭시키도록 변경한 코드 

2) @Qualifier 추가 구분자를 붙여주기

추가적인 방법을 제공하는 것이지 빈 이름을 변경하는건 아니다. 

예를 들어, RateDiscountPolicy 에 @Qualifier("mainDiscountPolicy") 를 지정하고, 

FixDiscountPolicy 에는 @Qualifier("fixDiscountPolicy") 를 지정한다. 

생성자 주입을 할 때 @Qualifier를 써주면 된다.

만약 해당 @Qualifier를 못찾으면 스프링은 그 이름으로 등록된 빈을 찾아본다. 

@Qualifier의 스프링 빈 조회 순서->   1.  @Qualifier 끼리 매칭,  2. 빈 이름 매칭 

@Qualifier 는 @Qualifier 를 찾는 용도로만 사용하는게 명확하고 좋다. 헷갈리게 하는 요소를 만들지 말자. 

3) @Primary 우선순위를 지정하기 [ 편하고 자주 사용한다 ] 

rate 할인정책을 항상 먼저 적용하고 싶다면, RateDiscountPolicy에 @Primary 를 붙인다. 

생성자에는 DiscountPolicy 타입 그대로 둔다. 

[ 참고 ] @Primary 는 언제 사용할까? 

예를 들어, 메인 DB connection 을 주로 사용하고, 백업용 DB connection 이 있는 상황에서,

메인 DB connection 에 @Primary 를 걸어두자고 팀내에서 룰을 지정할 수 있다. 

다음 강의에서는 애노테이션을 직접 만드는 방법을 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 다양한 의존관계 주입 방법 

2. 옵션 처리 

3. 생성자 주입을 선택해라!  (이번 포스팅)

4. 롬복과 최신 트랜드

5. 조회 빈이 2개 이상 - 문제

6. @Autowired 필드 명, @Qualifier, @Primary

7. 애노테이션 직접 만들기

8. 조회한 빈이 모두 필요할 때, List, Map

9. 자동, 수동의 올바른 실무 운영 기준

3. 생성자 주입을 선택해라! 

최근에는 스프링을 포함한 DI 컨테이너들은 생성자 주입을 권장한다. 그 이유는 다음과 같다. 

1)  불변 

   * 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다. 

   * 불변, 필수 의존관계에 사용한다. 

   * 애플리케이션을 종료할 때 까지 의존관계를 변경할 일이 있을까? 없다. 거의 없다. 오히려 불변해야한다. 

   * 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어둬야 한다. 누군가 실수로 setXxx으로 변경할 수 있어서 위험한 설계다. 

2)  누락 

  * 생성자 주입을 사용하면 주입 데이터를 누락했을 때 바로 컴파일 에러를 낸다.

 가장 좋은 에러는 컴파일에러. 그리고 IDE에서 바로 어떤 값을 주입하라고 알려준다.

2)  final 키워드 

 * 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다. 혹시라도 생성자에 값이 주입되지 않은 오류를 컴파일 시점에 막아준다. 

A. 수정자 주입으로 테스트 코드 작성

setter로 (수정자 주입)을 사용하여 테스트 코드를 작성한 예시를 보자.

 OrderServiceImpl 에서 수정자 주입으로 의존관계를 주입했다. 

순수 자바 코드를 이용해서 OrderServiceImpl 의 '주문 요청'메서드를 테스트하자. 

문제 없이 동작할까? 테스트를 실행해보자. 

NullPointerException 이 발생한다. 

OrderServiceImpl 을 생성해서 테스트 코드를 작성하는 상황에서는 의존관계를 주입해야 하는 것을 발견하지 못하기 때문이다. 

set은 '객체가 생성된 후에' 의존관계 주입을 하는거니까. 생성시에는 별 문제가 안된다. 

B. 생성자 주입으로 테스트 코드 작성

OrderServiceImpl 의 의존관계를 '생성자 주입'으로 변경했다. 

테스트 코드로 돌아가보자. 코드에 빨간 밑줄이 벌써 떠있고 constructor 오류가 난다. 

세상에서 가장 좋은 오류 컴파일 오류.

C. [ final 키워드 시용시 ] 개발자가 생성자 주입에서 필드 하나 주입하는것을 잊어버린다면? 

바로 빨간줄 뜨고 자바 컴파일러가 생성자에 의존관계 주입하라고 컴파일 시점에 잡을 수 있다. 

결론 : 항상 생성자 주입을 사용하자. 

4. 롬복과 최신 트랜드 

막상 개발을 해보면 대부분이 다 불변이다. 그래서 생성자에 final 키워드를 붙이게 된다. 

그런데 생성자도 만들고, 주입 받는 코드도 만들고.. 영 반복 작업 같다. 

아래 OrderServiceImpl 을 최적화 해보자. 

1) 생성자가 딱 1개만 있으면 @Autowired  를 생략할 수 있다. 

2) 롬복 라이브러리를 적용해서 생성자를 자동으로 만들자. 

@RequiredArgsConstructor 가 final 이 붙은 필드를 가지고 생성자 코드를 그대로 만들어준다. 

[ lombok 적용 방법 ] 

lombok 의존성을 build.gradle 에 추가하자. 

intelliJ에 Annotation Processors 를 사용하도록 체크하자.

getter, setter 메서드를 직접 작성할 필요 없이, 클래스에 @Getter, @Setter 를 달아놓으면 자동으로 만들어준다. 

3) OrderServiceImpl 를 최적화한 결과 코드 

다음 강의에서는 조회 빈이 2개 이상일 때의 처리 방법을 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편