[이철우/찰스] 4주차 정리내용 제출

fewolee/스프링_핵심_원리/README.md

@@ -214,4 +214,131 @@
   - 이름이 같은 경우 스프링은 오류를 발생시킨다
 - 자동 빈 등록 VS 수동 빈 등록
   - 수동빈이 우선권을 가짐
-  - 스프링부트의 경우 오류를 발생시킨다.
+  - 스프링부트의 경우 오류를 발생시킨다.
+- ### 의존관계 주입방법
+
+- 생성자 주입 : 생성자 호출 시점에 딱 1번만 호출되는 것이 보장, ‘불변, 필수’ 의존관계에 사용
+- 수정자 주입 (setter 주입) : ‘선택, 변경’ 가능성이 있는 의존관계에 사용
+- 필드 주입 :
+  - 외부에서 변경이 불가하여, 테스트 하기 힘들다.
+  - DI 프레임워크가 없으면 아무것도 할 수 없다.
+- 일반 메서드 : 한번에 여러 필드 주입, 거의 사용 하지 않음
+
+### 옵션 처리
+
+- 주입된 빈이 없어도 동작해야 할 때가 있다.
+  - @Autowired 는 require 옵션이 true가 기본값으로 되어 있어 자동주입 대상이 아니다.
+  - @Nullable : 자동주입 대상이 없으면 null이 입력
+  - Optinal<> : 자동주입 대상이 없으면 Optional, Empty
+
+### 생성자 주입을 선택하자
+
+- 불변
+  - 대부분 의존관계 주입은 한번 일어나면 애플리케이션 종료 시점까지 의존관계를 변경할 수가 없다.
+    - 오히려 대부분 의존관계는 애플리케이션 종료 전까지 변화면 안된다.
+  - 수정자 주입은 set 메서드를 public 으로 열어두어, 누군가 실수로 변경할 수 있다.
+- 누락
+  - 생성자 주입은 주입 데이터를 누락 할 경우 ‘컴파일 오류’가 발생한다.
+    - 수정자 주입은 runtime 에러 발생
+- final 키워드
+  - 생성자 주입시 final 키워드를 사용할 수 있어, 혹시라도 값이 설정되지 않는 오류를 ‘컴파일’ 시점에 알려준다.
+- 정리
+  - 생성자 주입은 순수한 자바언어의 특징을 잘 살리는 방법
+  - 기본적으로 생성자 주입을 사용, 필수값이 아닌 경우 수정자 주입 방식을 옵션으로 부여
+    - 필드 주입은 사용하지 말라.
+- 조치 대상 빈이 2개 이상일 경우
+  - @Autowired 필드명 매칭
+    - 타입 매칭 > 타입매칭 결과가 2개 이상 일때 > 필드명, 파라미터 명으로 빈 이름 매칭
+  - @Quilifier 사용
+    - 주입시 추가 구분자를 붙혀주는 방법 (빈 이름 변경 x)
+    - @Quilifier 끼리 매칭 > 빈 이름 매칭
+  - @Primary 사용 : 우선순위를 정하는 방법 @Autowired 시에 여러 빈이 매칭되면 @Primary가 우선권을 가진다.
+    - @Quilifier와 같이 사용시 @Quilifier가 우선 순위를 가진다.
+
+### 자동, 수동의 올바른 실무 운영 기준
+
+- 자동기능을 기본으로 사용
+- 수동빈을 언제 사용하면 좋을까?
+  - 기술지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 사용
+  - 비지니스 로직 중에서 다형성을 적극 활용 할때
+
+### 빈 생명주기와 콜백
+
+- 스프링 빈의 이벤트 라이프 사이클
+  - 스프링 컨테이너 생성 > 스프링 빈 생성 > 의존관계 주입 > `초기g화 콜백` > 사용 > `소멸전 콜백` > 스프링 종료
+- 객체의 생성과 초기화를 분리하자
+- 스프링의 빈 생명 주기 callback 3가지 방법
+  1. 인터페이스(InitializingBean, DisposableBean)
+  2. 설정 정보에 초기화 메소드, 종료 메소드 지정
+  3. @PostConstructor, @PreDestroy 애노테이션 지원
+
+### 인터페이스 사용
+
+- 초기화, 소멸 인터페이스 단점
+  - 스프링 전용 인터페이스에 의존
+  - 초기화, 소멸 메서드의 이름을 변경할 수 없다.
+  - 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.
+
+    ### 빈 등록 초기화, 소멸 메서드
+
+  - 설정정보에 @Bean(initMethod, destroyMethod) 처럼 초기화, 소멸 메소드를 지정할 수 있다.
+  - 설정정보 사용의 특징
+    - 메서드 이름을 자유롭게 줄 수 있다.
+    - 스프링 빈이 스프링 코드에 의존하지 않는다.
+    - 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드 적용 가능
+  - 종료메서드 추론
+    - @Bean destroyMethod 속성은 별도로 기입하지 않을 경우, close, shutdown 이름의 메서드를 종료메서드로 사용한다.
+      - default 값이 inferred(추론) 으로 등록
+
+### Annotation @PostConstruct, @PreDestroy
+
+- 이 두 annotation을 사용하면 가장 편리하게 초기화와 종료를 실행할 수 있다.
+- @PostConstruct, @PreDestroy
+  - 최신 스프링에서 가장 권장하는 방법
+  - 매우 편리하다
+  - 자바 표준기술로 스프링이 아닌 다른 컨테이너에서도 동작한다.
+  - 컴포넌트 스캔과 잘 어울린다.
+  - 단점은 외부 라이브러리에 적용 할 수 없다.
+    - 외부 라이브러리 초기화, 종료 시 @Bean 의 기능 사용
+
+### 정리
+
+- @PostConstruct, @PreDestroy annotation을 사용하자
+- 코드 수정이 불가한 외부 라이브러리를 초기화, 종료해야 하면, @Bean(initMethod, destroyMethod) 를 사용하자
+
+### 빈 스코프란?
+
+- 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때 까지 유지
+  - 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문
+- 스프링이 지원하는 스코프
+  - 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
+  - 프로토타입 : 빈의 생성과 의존관계 주입까지만 관여하고, 더는 관여하지 않는 매우 짧은 범위의 스코프
+  - 웹 관련 스코프
+    - request : 웹 요청이 들어오고 나갈때까지 유지
+    - session : 웹 세션이 생성되고 종료될 때 까지 유지
+    - application : 웹의 서블릿 컨텍스트와 같은 범위로 유지
+
+### 프로토타입 스코프
+
+- 싱글톤빈과 다르게 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환
+- 스프링 컨테이너는 프로토 타입 빈을 생성하고, 의존관계 주입, 초기화 까지만 처리
+  - 프로토타입 빈을 관리할 책임은 프로토타입 빈을 받은 클라이언트에 있다.
+  - @PreDestroy 메소드가 호출되지 않는다.
+
+### 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점
+
+- 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 새로 생성되기는 하지만 싱글톤 빈과 함께 계속 유지되는 것이 문제다.
+
+### 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결
+
+- ObjectFactory, ObjectProvider
+  - 지정한 빈을 컨테이너에서 대신 찾아주는 DL서비스를 제공
+- JSR-330 Provider
+  - 자바표준을 사용하는 방법, 별도의 라이브러리 필요, 스프링이 아닌 다른 컨테이너에서 사용가능
+- 웹 스포크
+  - 웹 환경에서만 동작, 스프링 종료 시점까지 관리
+  - 웹 스코프의 종류
+    - request : HTTP 요청 하나가 들어오고 나갈때까지 유지, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리된다.
+    - session : HTTP Session과 동일한 생명주기를 가지는 스코프
+    - application : 서블릿 컨텍스트와 동일한 생명주기를 가지는 스코프
+    - websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프