1. public 생성자 : 클래스의 인스턴스를 얻는 전통적인 수단
2. 정적 팩토리 메서드 : 클래스의 인스턴스를 반환하는 정적 메서드

   public static Boolean valueOf(boolean b) {
      return b ? Boolean.TRUE : Boolean.FALSE;
   }

   정적 팩터리 메서드

장점

1. 이름을 가질 수 있다.

• 이름을 통해 반환될 객체의 특성을 쉽게 묘사할 수 있다.
  • BigInteger(int, int, Random) vs BigInteger.probablePrime() (값이 소수인 BigInteger를 반환하는 메서드)
• 생성자를 여러 개 만들 때, 시그니처가 같은 생성자가 여러 개 필요할 경우 → 생성자를 정적 팩터리 메서드로 바꾸고 각각의 차이를 잘 드러내는 이름을 짓는다.
  

2. 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.

• 불변 클래스 : 인스턴스를 미리 만들어놓거나 새로 생성한 인스턴스를 캐싱하여 재사용할 수 있음
  • Boolean.valueOf(boolean) : 객체를 아예 생성하지 않음
• 생성 비용이 큰 같은 객체가 자주 요청되는 상황에서 성능을 끌어올려줌 (≒ 플라이웨이트 패턴(Flyweight pattern))

  Flyweight pattern
  

  • 어떤 클래스의 인스턴스 한 개만 가지고 여러 개의 "가상 인스턴스"를 제공하고 싶을 때 사용하는 패턴
  • 즉 인스턴스를 가능한 대로 공유시켜 쓸데없이 new연산자를 통한 메모리 낭비를 줄이는 방식

• 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제할 수 있음 => instance-controlled class(인스턴스 통제 클래스)
  • 클래스를 싱글턴으로도, 혹은 인스턴스화 불가 클래스로도 만들 수 있다.
  • 불변값 클래스에서, 동치인 인스턴스가 단 하나뿐임을 보장할 수 있다.
  • 플라이웨이트 패턴의 근간이 됨
• 열거 타입 : 인스턴스가 하나만 만들어지는 것을 보장함

3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.

• 반환 객체의 클래스를 자유롭게 선택할 수 있음 -> 유연성 ↑!!!
• 구현 클래스를 공개하지 않고도 그 객체를 반환할 수 있음 -> API를 작게 유지할 수 있음
  • 인터페이스를 정적 팩터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워크를 만드는 핵심 기술
  • ~ Java 7 : 인터페이스에 정적 메서드를 선언할 수 없었음 → 이름이 "Type"인 인터페이스를 반환하는 정적 메서드가 필요할 경우, "Types"라는 companion class(동반 클래스)를 만들어 그 안에 정의하는 것이 관례였음
    • Java Collection Framework 중 수정 불가, 동기화 등의 45개 유틸리티 구현체 중 대부분 -> java.util.Collections에서 정적 팩털히 메서드를 통해 얻도록 했음
    • 정적 팩터리 메서드를 사용하는 클라이언트 : 얻은 객체를 구현 클래스가 아닌 인터페이스만으로 다루게 됨 → 좋은 습관
  • Java 8 : 인터페이스도 정적 메서드를 가지게 됨 → 인스턴스화 불가 동반 클래스를 둘 이유가 별로 없음 (인터페이스 자체에 두면 되기 때문)
    • 단, 정적 메서드를 구현한 코드 중 많은 부분은 package-private 클래스에 두어야 함
    • Java 9 : private 정적 메서드까지 허락하지만, 정적 필드와 정적 멤버 클래스는 public이어야 함
      

4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.

• 반환 타입의 하위 타입이기만 하면, 어떤 클래스의 객체를 반환해도 상관 없음

  • EnumSet : 원소가 64개 이하면 long 변수 1개를 관리하는 RegularEnumSet, 원소가 65개 이상이면 long 배열로 관리하는 JumboEnumSet의 인스턴스 반환

• 클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고 알 필요도 없음

  
  

5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

• Service Provider Framework(서비스 제공자 프레임워크)를 만드는 근간이 됨

  • provider = 서비스의 구현체
  • 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제하며, 클라이언트를 구현체로부터 분리해줌

• 3개의 핵심 컴포넌트로 이루어짐

  • service interface (서비스 인터페이스)
  • provider registration API (제공자 등록 API)
  • service access API (서비스 접근 API)
    • 클라이언트가 사용할 때, 원하는 구현체의 조건을 명시할 수 있음 (else, 기본 구현체 반환 or 지원하는 구현체들을 하나씩 돌아가며 반환함)
    • 이것이 바로 서비스 제공자 프레임워크의 근간인 유연한 정적 팩터리
  • service provider interface (서비스 제공자 인터페이스)
    • 네번째 컴포넌트
    • 서비스 인터페이스의 인스턴스를 생성하는 팩터리 객체 설명해줌
    • 이게 없으면, 각 구현체를 인스턴스로 만들 때 리플렉션을 사용해야 함

• ex) JDBC(Java Database Connectivity)

  • Connection : 서비스 인터페이스
  • DriverManager.registerDriver : 제공자 등록 API
  • DriverManager.getConnection : 서비스 접근 API
  • Driver : 서비스 제공자 인터페이스

• 패턴의 변형이 여러 가지 있음

  • Bridge Pattern(브릿지 패턴) : 공급자가 제공하는 것보다 더 풍부한 서비스 인터페이스를 클라이언트에 반환할 수 있음
  • Dependency Injection(의존 객체 주입) Framework : 강력한 서비스 제공자

단점

1. 상속을 하려면 public이나 protected 생성자가 필요함 -> 정적 팩터리 메서드만 제공하면, 하위 클래스를 만들 수 없음

• 컬렉션 프레임워크의 유틸리티 구현 클래스들은 상속할 수 없다.
• 단, 상속보다는 컴포지션을 사용하도록 유도하고, 불변 타입으로 만들려면 이 제약을 지켜야 한다는 점에서 오히려 장점이 될 수 있다.

2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.

• 생성자처럼 API 설명에 명확히 드러나지 않음 -> 사용자가 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 찾아야 함
• 따라서 API 문서를 잘 써놓고, 메서드 이름도 널리 알려진 규약을 따라 짓는 식으로 완화해줘야 함

정적 팩터리 메서드 명명 방식

• from :매개변수를 하나 받아서 해당 타입의 인스턴스 반환하는 형변환 메서드
• of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드
• valueOf : from과 of의 더 자세한 버전
• instance, getInstance : (받는다면) 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지는 않음
• create, newInstance : instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장
• getType : getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 사용함 (Type : 팩터리 메서드가 반환할 객체의 타입)
• newType : newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스의 팩터리 메서드를 정의할 때 사용함 (Type : 팩터리 메서드가 반환할 객체의 타입)
• type : getType, newType의 간결한 버전

정리

• 정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니, 상대적인 장단점을 이해하고 사용하는 것이 좋다.
• 단, 정적 팩터리를 사용하는 것이 유리한 경우가 더욱 많으므로, 무작정 public 생성자를 제공하던 습관이 있다면 고쳐야 한다.

방법 1. Query Parameter를 통한 데이터 전송

• GET
• 정렬 필터(검색어)

방법 2. Message Body를 통한 데이터 전송

• POST, PUT, PATCH
• 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 등

상황 1. 정적 데이터 조회

• ex: 이미지, 정적 텍스트 문서
• 조회 : GET 사용
• 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순히 조회 가능

상황 21. 동적 데이터 조회

• ex: 검색, 게시판 목록에서 정렬 필터(검색어)
• 조회 : GET 사용
  • Query Parameter를 사용해서 데이터 전달
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용

상황 3. HTML Form

• POST -> Message Body에 넣어 전송

• GET -> URL에 넣어 전송

  📌 주의 단, GET은 조회에만 사용! 리소스 변경이 발생하는 곳에 사용 X (ex: 회원가입 등)

• multipart/form-data

• ex: 회원 가입, 상품 주문, 데이터 변경

• GET, POST 가능

• Content-Type : application/x-www-form-urlencoded

  • form의 내용을 메시지 바디를 통해 전송(key-value, 쿼리 파라미터 형식)
  • 전송 데이터를 url encoding 처리 (ex: abc김 → abc%EA%B9%80)

• Content-Type : multipart/form-data

  • 파일 업로드 등의 바이너리 데이터 전송 시 사용
  • 다른 종류의 여러 파일과 폼의 내용을 함께 전송 가능 (그래서 multipart)

상황 4. HTTP API

• ex: 회원 가입, 상품 주문, 데이터 변경
• 용도 : 서버 to 서버(백엔드), 앱 클라이언트(iOS, Android), 웹 클라이언트(Ajax(React, View))
• POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송
• GET : 쿼리 파라미터로 데이터 전달
• Content-Type: application/json 주로 사용 (그 외: TEXT, XML 등)

API 설계

방향

1. Collection

• POST 기반 등록
• ex) 회원 관리 API

2. Store

• PUT 기반 등록
• ex) 정적 컨텐츠 관리, 원격 파일 관리

3. HTML Form 사용

• GET, POST만 지원
• 웹 페이지 회원 관리

1. Collection - POST 기반 등록

• 회원 목록 /members : GET
• 회원 등록 /members : POST
• 회원 조회 /members/{id} : GET
• 회원 수정 /members/{id} : PATCH, PUT, POST
• 회원 삭제 /members/{id} : DELETE

• 클라이언트는 등록될 리소스의 URI를 모름
• 서버가 새로 등록된 리소스 URI를 생성해줌
  • ex) POST /members/100
• Collection
  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스의 URI를 생성하고 관리
  • 여기서 컬렉션 : /members

2. Store - POST 기반 등록

• 회원 목록 /members : GET
• 회원 등록 /members : POST
• 회원 조회 /members/{id} : GET
• 회원 수정 /members/{id} : PATCH, PUT, POST
• 회원 삭제 /members/{id} : DELETE

• 클라이언트가 리소스 URI를 알고 있음
  • PUT /files/{filename}
  • PUT /files/star.jpg
• 클라이언트가 직접 리소스의 URI를 지정함
• Store
  • 클라이언트가 관리하는 리소스 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • /files : 스토어

3. HTML Form 사용

• 회원 목록 /members : GET
• 회원 등록 폼 /members/new : GET
• 회원 등록 폼 /members/new or /members : POST
• 회원 조회 /members/{id} : GET
• 회원 수정 폼 /members/{id}/edit : GET
• 회원 수정 /members/{id}/edit or /members/{id} : POST
• 회원 삭제 /members/{id}/delete : POST

• GET, POST만 지원
  • AJAX 같은 기술을 사용해서 해결 가능
  • 순수 HTML Form만 이용하면 제약이 있음

💡 추가 Tips! 참고하면 좋을 URI 설계 개념

• document 단일 개념 ex) /members/100, /files/star.jpg

• collection 서버가 관리하는 리소스 디렉토리, 서버가 리소스의 URI를 생성하고 관리 ex) /members

• store 클라이언트가 관리하는 자원 저장소 클라이언트가 리소스의 URI를 알고 관리 /files

• controller, control URI 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행. 동사를 직접 사용 ex) /members/{id}/delete

• 리소스 식별
• URI 계층 구조 활용

예시

• 회원 목록 조회 /members
• 회원 목록 조회 /members
• 회원 목록 조회 /members
• 회원 목록 조회 /members

리소스와 행위를 분리한다

• URI : 리소스만 식별하며, 행위는 식별하지 않는다.
• 리소스 = 명사 / 행위 = 동사

URI 네이밍시 참고! 계층 구조상 상위를 컬렉션으로 봄 → 복수단어 사용 권장!      - member (X)      - members (O)

HTTP 메서드 종류

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

기타 메서드

• HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 주로 설명 (주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

GET

• 서버에 전달하고 싶은 데이터는 query parameter(query string)를 통해 전달
• 메시지 바디를 사용해서 데이터 전달도 가능은 하지만, 지원하지 않는 곳이 많아 권장하지 않음

POST

• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리함 (메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능들 수행)
• 전달된 데이터로 신규 리소스를 등록하고, 프로세스 처리에 사용함

기능

1. 새 리소스 생성
2. 요청 데이터 처리 (프로세스 처리)
3. 다른 메서드로 처리하기 어려운 경우
   • JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
   • 애매하면 POST 사용

PUT

• 리소스를 대체함
  • 리소스가 있으면 대체, 없으면 생성
  • 즉, 덮어씌워버림!
• POST와의 차이점 : 클라이언트가 리소스 위치를 알고 URI를 지정한다.

PATCH

• 리소스 부분을 변경함

💡 PUT과 PATCH의 차이 ⇒ 멱등성      : 어떤 대상에 같은 연산을 여러 번 적용해도 결과가 달라지지 않는 성질

• PUT : 멱등성 보장
• PATCH : 멱등성 보장하지 않을 수 있음

DELETE

• 리소스를 제거함

HTTP 메서드의 속성들

• 안전함 여부
• 멱등성 여부
• 캐시 가능 여부

안전함

• 호출해도 리소스를 변경하지 않음 (로그 데이터 고려 X)

멱등성(Idempotent)

• f(f(x)) = f(x)

POST는 멱등 메서드가 아님! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있음

📌 중요한 이유

• 자동 복구 메커니즘을 짤 떄 고려
• 서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가?

캐시 가능 (Cacheable)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용
  • POST, PATCH : 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

HyperText Transfer Protocol

HTTP 메시지에 담길 수 있는 것들

거의 모든 것!

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)

즉,

• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
• 지금은 HTTP 시대

역사

• HTTP/0.9 : GET 메서드만 지원. HTTP 헤더 X (1991)
• HTTP/1.0 : 메서드, 헤더 추가 (1996)
• HTTP/1.1 : 가장 많이 사용. 우리에게 가장 중요한 버전 (1997)
  • RFC2068 (1997) → RFC2616 (1999) → RFC7230 ~ 7235 (2014)
• HTTP/2 : 성능 개선 (2015)
• HTTP/3 : TCP 대신 UDP 사용, 성능 개선 (진행 중)

기반 프로토콜

• TCP : HTTP/1.1, HTTP/2
• UDP : HTTP/3

현재는 HTTP/1.1 주로 사용! 단, HTTP/2, HTTP/3도 점점 증가 중

HTTP의 특징

• Client-Server 구조
• Stateless Protocol
• 비연결성
• HTTP 메시지
• 단순함, 확장 가능

1. Client-Server 구조

• Request, Response의 구조
• 클라이언트 : 서버에 요청을 보내고, 응답을 대기
• 서버 : 요청에 대한 결과를 만들어 응답

💡 중요한 이유!

• 클라이언트와 서버를 분리할 수 있음
• 비즈니스 로직 등 필요한 로직 등을 모두 서버에 넣을 수 있음

2. Stateless Protocol

• 서버가 클라이언트의 상태를 보존하지 않음

장점

• 서버 확장성 높음 (Scale-Out) 즉, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있음. 수평 확장 유리
• 응답 서버를 쉽게 바꿀 수 있음 → 무한한 서버 증설 가능

단점

• 클라이언트가 데이터가 필요할 때마다 매번 추가적으로 전송해야 함

실무 한계

• 모든 것을 무상태로 설계할 수 없는 경우도 존재함 (ex: 로그인 - 로그인한 사용자의 경우, 로그인했다는 상태를 서버에 유지해야 함)
• 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
• 상태 유지(Stateful)는 최소한만 사용

3. Connectionless (비연결성)

• HTTP : 기본적으로 연결을 유지하지 않는 모델

만약 비연결성이 아니라면?

비연결성의 장점

• 일반적으로 초단위 이하의 빠른 속도로 응답 가능
• 1시간 동안 수천명이 서비스를 사용해도, 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음 (ex: 웹브라우저에서 연속해서 검색 버튼을 누르지 않음)
• 서버 자원을 매우 효율적으로 사용 가능

비연결성의 한계와 극복

• TCP/IP 연결을 새로 맺어야 함 → 3-way handshake 시간 추가됨
• HTML 뿐만 아니라 JS, CSS, 추가 이미지 등 많은 자원이 함께 다운로드됨
• 현재는 HTTP Persistent Connections (지속 연결)로 문제 해결 (이제는 기본 설정임)

  📌 참고 - HTTP 초기 (지속 연결 X)

• HTTP/2, HTTP/3에서 더 많은 최적화

4. Stateless

서버 개발자들이 어려워하는 업무

• 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 등에도 잘 대처할 수 있음

HTTP 구조

Request

단! 요청 메시지도 body 본문을 가질 수 있음

• start-line = request-line / status-line
  • request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
  • request-target = /search?q=hello&hl=ko. 절대경로[?]쿼리 (/로 시작함)

Response

• start-line = request-line / status-line
• status-line = HTTP-version SP status-code SP reason-phrase CRLF
  • reason-phrase : 짧은 상태코드 설명 글

HTTP Header

• header-field = field-name``: OWS field-value OWS(띄어쓰기 허용)
  • field-name : 대소문자 구분 없음

특징

• HTTP 전송에 필요한 모든 부가 정보
  • 메시지 바디의 내용
  • 메시지 바디의 크기
  • 압축
  • 인증
  • 요청 클라이언트(브라우저) 정보
  • 서버 애플리케이션 정보
  • 캐시 관리 정보
• 표준 헤더가 너무 많음
• 필요시 임의의 헤더 추가 가능

HTTP Message Body

• 실제 전송할 데이터
• HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

자원 식별자

• Locator, Name 또는 둘 다 추가로 분류될 수 있다.

URL vs URN

URL이란?

Uniform Resource Locator

• 리소스가 있는 위치를 지정
• 보통 리소스를 찾는 방법으로는 보편적으로 URL을 사용

따라서, 편의상 앞으로 URI를 URL과 같은 의미로 이야기할 것임

URN이란?

Uniform Resource Name

• 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• 단, 반대로 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음
• 책의 isbn 등에 유용 - ex)urn:isbn:89607773331

URL 문법

• https : 프로토콜
• www.google.com : 호스트명 (도메인명 또는 IP 주소)
• 443 : 포트 번호
• /search : 패스 (= path = 리소스 경로, 계층적 구조)
• q=hello&hl=ko : 쿼리 파라미터 (key=value 형태, ?로 시작) (=query parameter, query string)

• #fragment : HTML 내 북마크 등에서 사용함 (블록으로 이동 등) (서버에 전송하는 정보 X)

특징

• 주로 프로토콜 사용

  📌 프로토콜 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙

  • ex) http, https, ftp 등
  • http 80 포트 주로 사용 (생략 가능)
  • https http에 보안 추가된 것 (HTTP Secure) 443 포트 주로 사용 (생략 가능)

웹 브라우저의 요청 흐름

HTTP Request

Packet

요청 Packet 전송

HTTP Response

응답 Packet 전송

모든 것이 HTTP 위에서 동작함! (데이터를 주고 받음)

IP

Internet Protocol

• 지정한 IP Address(IP 주소)에 데이터 전달
• Packet이라는 통신 단위로 데이터 전달
  • 패킷 구조
  • Client가 패킷을 전달하기
  • Server가 패킷을 전달하기

한계

• 비연결성 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송됨

• 비신뢰성

  • 중간에 패킷이 사라지면?
  • 패킷이 순서대로 안 오면?

• 프로그램 구분

  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

인터넷 4계층

계층별로 올라가면서, 다음과 그림과 같이 데이터를 덧붙여 씌움

다음은 전송계층 / 인터넷계층을 지나면서 덧붙여지는 내용들

TCP/UDP

TCP

전송 제어 프로토콜 (Transmission Control Protocol)

• 연결 지향 - TCP 3 handshake (가상 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

3-way handshake

4-way handshake

UDP

사용자 데이터그램 프로토콜 (User Datagram Protocol)

• 기능이 거의 없음
• 연결 지향 X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• 정리
  • IP와 거의 같지만, PORT, CHECKSUM 정도만 추가됨
  • Application에서 추가 작업 필요

PORT 정보란?

• 0 ~ 65535 : 할당 가능

• 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음

  • 20, 21 : FTP
  • 23 : TELNET
  • 80 : HTTP
  • 443 : HTTPS
  
  

  DNS란?

  Domain Name System

  • 전화번호부
  • 도메인 명을 IP 주소로 변환

: 빈이 존재할 수 있는 범위

다양한 Scope

• Singleton
  • 기본 스코프
  • 스프링 컨테이너의 시작과 종료까지 유지되는, 가장 넒은 범위의 스코프
• Prototype
  • 스프링 컨테이너는 생성과 의존관계 주입가지만 관여
  • 그 이후는 관리하지 않음
  • 매우 짧은 범위의 스코프

Web 관련 Scope

• request : 웹 요청이 들어오고 나갈 때까지 유지되는 스코프
• session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프
• application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프

Singleton Bean Scope

• 스프링 컨테이너가 소멸때까지 관리함

Prototype Bean Scope

• 스프링 컨테이너는 생성과 의존관계 주입, 초기화까지만 관리하고, 다시 유저에게 반환해버림
• 즉, 보관하지 않기 때문에 매번 생성해서 반환함
• 따라서 @PreDestroy와 같은 종료메서드가 호출되지 않는다.

문제 사항

• 스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 된다.
• 단, 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 생성 단계에서 생성된 후 유지되는 것이 문제!!

보통은, 이런 경우를 피하고 싶어서 프로토타입 빈을 사용한다. 따라서 의도와 다르게 동작할 가능성 ↑

Singleton Bean + Prototype Bean

• Client Bean : 싱글톤이기 때문에, 스프링 컨테이너 생성 시점에 생성된 후 의존관계 주입도 발생
  • Prototype Bean을 스프링 컨테이너에 요청
  • 그 후 clientBean이 prototypeBean을 내부 필드에 보관

• clientBean은 요청이 들어올 때마다 같은 빈을 반환함
• clientBean.logic()이 호출되면, clientBean은 prototypeBean의 addCount() 호출 → prototype의 count 1 증가

이 경우, prototypeBean의 count는 2로 증가하게 된다 → 프로토타입 빈의 특성과 맞지 않는 결과!

Provider 사용하기

방법 0. 싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 새로 요청

• Dependency Lookup(DL) : 의존관계 조회(탐색)

  • 외부에서 의존관계를 주입받는 것이 아니라, 직접 필요한 의존관계를 찾는 것

• 단, 이렇게 스프링 ApplicationContext 전체를 주입받는 것은 권장되지 않는다!

  • 스프링 컨테이너에 종속적인 코드가 됨
  • 단위 테스트가 어려워짐

• 지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는, DL 정도의 기능만 제공하는 무언가만 있으면 됨

방법 1. ObjectProvider

원래는 ObjectFactory가 있었는데, 여기에 편의 기능을 추가해서 ObjectProvider가 만들어짐!

• 지정한 Bean을 컨테이너에서 대신 찾아주는 DL 서비스를 함

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

public int logic() {
     PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
     prototypeBean.addCount();
     int count = prototypeBean.getCount();
     return count;
}

• getObject() 메서드를 통해, 항상 새로운 프로토타입 빈을 생성함
  • 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아 반환함

특징

• ObjectFactory
  • 기능이 단순함
  • 별도의 라이브러리 필요 없음
  • 스프링에 의존함
• ObjectProvider
  • ObjectFactory 상속
  • 옵션, 스트림 처리 등 편의 기능이 많음
  • 별도의 라이브러리 필요 없음
  • 스프링에 의존

방법 2. JSR-330 Provider

javax.inject.Provider (jakarta.inject.Provider - Spring Boot 3.0 이상)

• JSR-330 자바 표준을 사용

@Autowired
private Provider<PrototypeBean> provider;

public int logic() {
     PrototypeBean prototypeBean = provider.get();
     prototypeBean.addCount();
     int count = prototypeBean.getCount();
     return count;
}

특징

• get() 메서드 하나 - 기능이 매우 단순
• 별도의 라이브러리가 필요함
• Java 표준임 → 스프링이 아닌 다른 컨테이너에서도 사용할 수 있음

📌 하나 더!

• 스프링이 제공하는 메서드 중 @Lookup 애노테이션도 있음
  • 단, 위의 방법들로도 충분함
  • 고려해야 할 내용도 많음

👉🏻 참고 사항

• 다만, 실무에서 웹 애플리케이션을 개발해보면 싱글톤 빈만 사용해도 대부분의 문제를 해결할 수 있음 → 프로토타입 빈을 직접적으로 사용하는 일은 매우 드묾

💡 Tip!

• ObjectProvider, JSR330 Provider 등 : 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용 가능
  • ex) 순환 참조 방지용

Java 표준 vs Spring 제공 기능?

위의 방법 2와 3을 보면, 둘 중 어느 것을 사용할지 고민이 될 수 있다.

• 만약 (거의 없지만) 코드를 스프링이 아닌 다른 컨테이너에서도 사용할 수 있어야 한다면, 자바 표준을 써야 한다.

• 스프링은 이제 사실상 기술의 표준에 가까움

• 다만, 대부분의 경우 위와 같은 일이 엇고, 스프링이 대부분 더 다양하고 편리한 기능을 제공해주기 때문에 특별한 일이 없다면 스프링이 제공하는 기능을 사용해도 좋다.

Web Scope

• 웹 환경에서만 동작한다.
• 프로토타입과 다르게 스프링이 해당 스코프의 종료 시점까지 관리한다.
• 따라서 종료 메서드가 호출된다.

종류 1. request

• HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 Scope
• 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리된다.

종류 2. session

• HTTP Session과 동일한 생명주기를 가짐

종류 3. application

• ServletContext와 동일한 생명주기를 가짐

종류 4. websocket

• 웹 소켓과 동일한 생명주기를 가짐

📌 실습 시 참고! spring-boot-starter-web 라이브러리를 추가하면 스프링 부트는 내장 톰켓 서버를 활용해서 웹 서버와 스프링을 함께 실행시킨다.

📌 실습 시 참고! 2

• 스프링 부트는 웹 라이브러리가 없으면 우리가 지금까지 학습한 AnnotationConfigApplicationContext을 기반으로 애플리케이션을 구동한다.
• 웹 라이브러리가 추가되면 웹과 관련된 추가 설정과 환경들이 필요하므로 AnnotationConfigServletWebServerApplicationContext를 기반으로 애플리케이션을 구동하면 된다.

request Scope

• 동시에 여러 HTTP 요청이 오면 → 정확히 어떤 요청이 남긴 로그인지 구분하기 어려워짐
• 이럴 때 request 스코프를 사용하면 좋음!
• @Scope(value = "request")
  • HTTP 요청 당 하나씩 생성됨
  • HTTP 요청이 끝나는 시점에 소멸됨
  • 다른 HTTP 요청 때문에 섞이는 걱정 안해도 됨

📌 참고!

• requestURL 로그를 남기는 부분 등은 컨트롤러보다는 스프링 인터셉터나 서블릿 필터 등을 활용하는 것이 좋음

Provider

• Controller

  @Controller
   @RequiredArgsConstructor
   public class LogDemoController {
       private final LogDemoService logDemoService;
       private final ObjectProvider<MyLogger> myLoggerProvider;
  
      @RequestMapping("log-demo")
      @ResponseBody
       public String logDemo(HttpServletRequest request) {
          String requestURL = request.getRequestURL().toString();
  
            MyLogger myLogger = myLoggerProvider.getObject();
          myLogger.setRequestURL(requestURL);
          myLogger.log("controller test");
  
            logDemoService.logic("testId");
  
            return "OK";
     }
  }

• Service

  @Service
   @RequiredArgsConstructor
   public class LogDemoService {
       private final ObjectProvider<MyLogger> myLoggerProvider;
       public void logic(String id) {
           MyLogger myLogger = myLoggerProvider.getObject();
          myLogger.log("service id = " + id);
      }
  }

• ObjectProvider을 사용하면?

  • ObjectProvider.getObject()를 호출하기 전까지 request scope 빈의 생성 지연 가능

  • ObjectProvider.getObject()` 호출 시점에는 HTTP 요청이 진행 중이므로 request scope 빈의 생성이 정상 처리됨

  • ObjectProvider.getObject()를 LogDemoController, LogDemoService에서 각각 한번씩 따로 호출해도, 같은 HTTP 요청이면 같은 스프링 빈이 반환됨

Proxy

활용 방법

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}

• MyLogger의 가짜 프록시 클래스를 만들어두고, HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 주입해둘 수 있다.
  • 적용 대상이 클래스 : TARGET_CLASS
  • 적용 대상이 인터페이스 : INTERFACES

주입된 myLogger

  System.out.println("myLogger = " + myLogger.getClass());

  myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d

• CGLIB라는 바이트코드를 조작하는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
• 스프링 컨테이너는 CGLIB를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성한다.
• 스프링 컨테이너에 "myLogger"라는 이름으로 진짜 대신에 이 가짜 프록시 객체를 등록한다
• 그래서 의존관계 주입도 이 가짜 프록시 객체가 주입된다!

그럼 어떻게 동작하는가?

• 가짜 프록시 객체

  • 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있음
  • 내부에 진짜 myLogger를 찾는 방법을 알고 있음
  • 클라이언트가 myLogger.logic()을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것 → 가짜 프록시 객체가 request scope를 가진 진짜 myLogger.logic()를 호출한다.
  • 원본 클래스를 상속 받아서 만들어짐 → 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있음(다형성)

  정리! 가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤 처럼 동작한다.

장점

• 프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
• 사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다.
• Proxy : 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. (이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.)
• 꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다 (나중에 나오는 AOP 원리가 딱 이것임)

주의점

• 마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
• 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자 (무분별하게 사용하면 유지보수하기 어려워진다!)

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

• 스프링 빈 : 객체를 생성하고, 의존 관계 주입 후에야 필요한 데이터를 사용할 준비가 제대로 완료됨
  • 준비 완료 시점을 알려주기 위한 콜백 메서드 필요함!

Bean Lifecycle Callback

스프링은 다양한 콜백 기능을 제공함

• 초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출(초기화 시점을 알려줌)

• 소멸전 콜백: 빈이 소멸되기 직전에 호출 (스프링 컨테이너가 종료되기 직전)

💡 객체의 생성과 초기화를 분리해야만 하는가?

• 객체의 생성 : 생성자가 필수 정보(파라미터)를 받아서 메모리를 할당해서 객체를 생성
• 초기화 : 이 값들을 활요해서 외부 커넥션과 연결하는 등 무거운 동작 수행 (단, 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우, 생성자에서 한 번에 다 처리하는 게 더 나을 수 있음)

방법

1. 인터페이스(InitializingBean, DisposableBean)
2. 설정 정보에 초기화 메서드, 종료 메서드 지정
3. @PostConstruct, @PreDestroy 애너테이션

방법 1. InitalizingBean, DisposableBean

• InitializingBean - afterPropertiesSet() 메서드

• DisposableBean - destroy() 메서드

단점

• 스프링 전용 인터페이스. 즉, 해당 코드가 스프링 전용 인터페이스에 의존함
• 초기화, 소멸 메서드의 이름을 변경할 수 없음
• 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없음

• 초창기 방법!
• 다른 방법들이 더 낫기 때문에, 거의 사용하지 않음!

방법 2. 빈 등록 초기화, 소멸 메서드 지정

• 빈 등록할 때, 초기화/소멸 메서드 지정

@Bean(initMethod = "init", destroyMethod = "close")

특징

• 메서드 이름을 자유롭게 지정할 수 있음
• 스프링 빈이 스프링 코드에 의존하지 않음
• 코드가 아니라 설정 정보를 사용함 → 코드를 고칠 수 없는 외부 라이브러리에도 초기화/종료 메서드 지정 가능

+) 독특한 기능 - 종료 메서드 추론

• @Bean의 destroyMethod 속성 - 기본값이 (inferred)(추론)으로 되어 있음
• close, shutdown이라는 이름의 메서드를 종료 메서드로 추론해서 자동으로 호출해줌
• 추론 기능을 사용하기 싫으면 → destroyMethod="" 처럼 공백 지정하면 됨 (단, 설정을 아주 꼬이게 할 수 있으므로, 추천하지 않음)

방법 3. 애노테이션 @PostConstruct, @PreDestroy

특징

• 가장 편리하고 간단하게 초기화/종료 메서드 실행 가능
• 최신 스프링에서 가장 권장하는 방법
• 애너테이션 하나만 붙이면 됨
• javax.annotation.PostConstruct 패키지 : 스프링에 종속적인 기술이 아닌 자바 표준 → Spring이 아닌 다른 컨테이너에서도 동작함
• Component Scan과 잘 어울림
• 유일한 단점 : 외부 라이브러리에는 적용하지 못함(까볼 수 없으니까) → 외부 라이브러리 이용 시에는 방법2(@Bean) 기능 활용하기

1. 생성자 주입
2. 수정자 주입(setter 주입)
3. 필드 주입
4. 일반 메서드 주입

1. Constructor Injection (생성자 주입)

방법

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy 
discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

특징

• 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.
• 불변, 필수 의존관계에 사용
• 요즘 가장 많이 쓰임

💡 중요! 해당 클래스에 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. (물론 스프링 빈에만 해당한다.)

⭐ 생성자 주입을 선택해라!

최근에는 스프링 뿐만 아니라 다른 DI 프레임워크들도 대부분 생성자 주입을 권장한다.

이유 1 : 불변성

• 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변해야 한다.)

• 수정자 주입 : setXxx 메서드를 public으로 열어두어야 한다.

• 누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다.

  👉🏻 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

이유 2 : 누락 방지

• @Autowired : 프레임워크 없이 순수한 자바 코드로만 단위 테스트를 수행하게 되면 의존관계가 없어도 오류가 발생하지 않는다.
• 수정자 주입 : 의존관계를 실수로 누락하면, 실행은 되는데 NPE가 발생한다.
• 생성자 주입 : 주입 데이터를 누락 했을 때 컴파일 오류가 발생한다.
• 그리고 IDE에서 바로 어떤 값을 필수로 주입해야 하는지 알 수 있다.

이유 3 : final 키워드

• 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다. 그래서 생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에 막아준다.
• 발생하는 오류 : java: variable discountPolicy might not have been initialized

💡 참고

• 수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출되므로, 필드에 final 키워드를 사용할 수 없다.
• 오직 생성자 주입 방식만 final 키워드를 사용할 수 있다.

2. Setter Injection (수정자 주입)

방법

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;

    @Autowired    // 빼면 당연히 안 들어옴!
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

참고

• @Autowired 의 기본 동작은 주입할 대상이 없으면 오류가 발생한다.
• 주입할 대상이 Spring Container에 없어도 동작하게 하려면 @Autowired(required = false) 로 지정하면 된다.

특징

• 선택, 변경 가능성이 있는 의존관계에 사용 (중간에 필드 의존 관계를 바꾸고 싶을 때, 외부에서 냅다 setter 사용해서 바꿀 수 있음)
• 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다.
• 생성자 주입과 달리, 생성과 동시에 의존관계 주입이 되는 원리는 아님
• 종종 쓰임

💡 참고: 자바빈 프로퍼티란?

• 자바에서는 과거부터 필드의 값을 직접 변경하지 않고, setXxx, getXxx 라는 메서드를 통해서 값을 읽거나 수정하는 규칙을 만들었는데, 그것이 자바빈 프로퍼티 규약이다.

3. Field Injection (필드 주입)

방법

@Component
public class OrderServiceImpl implements OrderService {

    @Autowired
     private MemberRepository memberRepository;
     @Autowired
     private DiscountPolicy discountPolicy;
}

💡 참고

• 순수한 자바 테스트 코드에는 당연히 @Autowired가 동작하지 않는다.
• @SpringBootTest처럼 스프링 컨테이너를 테스트에 통합한 경우에만 가능하다

특징

• 안티 패턴! - 코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 있다.
• DI 프레임워크가 없으면 아무것도 할 수 없다. 사용하지 말자!
• 사용해도 좋을 특별한 용도들
  • 애플리케이션의 실제 코드와 관계 없는 테스트 코드
  • 스프링 설정을 목적으로 하는 @Configuration 같은 곳

참고 위의 방법이 아닌, 그냥 new로 바로 직접 자동 주입하는 방식도 역시 추천되지 않는다.

• 자동 등록 : 다음 코드와 같이 @Bean에서 파라미터에 의존관계는 자동 주입된다.

  @Bean
  OrderService orderService(MemberRepository memberRepoisitory, DiscountPolicy 
  discountPolicy) {
     new OrderServiceImpl(memberRepository, discountPolicy)
  }

• 수동 등록 : 자동 등록된 빈의 의존관계가 필요할 때 문제를 해결할 수 있다.

4. 일반 메서드 주입

방법

@Component
public class OrderServiceImpl implements OrderService {
     private MemberRepository memberRepository;
     private DiscountPolicy discountPolicy;

    @Autowired
    public void init(MemberRepository memberRepository, DiscountPolicy 
discountPolicy) {
         this.memberRepository = memberRepository;
         this.discountPolicy = discountPolicy;
     }
}

특징

• 한번에 여러 필드를 주입 받을 수 있다.
• 일반적으로 잘 사용하지 않는다

💡 참고

• 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다.
• 스프링 빈이 아닌 클래스에서 @Autowired 코드를 적용해도 아무 기능도 동작하지 않는다!

📌 정리 - 생성자 주입 방식을 선택하자!

• 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법이다.
• 항상 생성자 주입을 선택해라! 그리고 가끔 옵션이 필요하면 수정자 주입을 선택해라. (생성자 주입과 수정자 주입을 동시에 사용할 수 있다.)
• 필드 주입은 사용하지 않는게 좋다
• Lombok의 @RequiredArgsConstructor를 보통 사용한다.

Options

자동 주입을 옵션으로 처리하기

• 주입할 스프링 빈이 없어도 동작해야 할 때가 있다.
• 그런데 @Autowired만 사용하면 required 옵션의 기본값이 true로 되어 있어서 자동 주입 대상이 없으면 오류가 발생한다.

방법 3가지

방법 1. @Autowired(required=false)

: 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨

  //호출 안됨
  @Autowired(required = false)
  public void setNoBean1(Member member) {
      System.out.println("setNoBean1 = " + member);
  }

방법 2 : org.springframework.lang.@Nullable

: 자동 주입할 대상이 없으면 null이 입력된다.

  //null 호출
  @Autowired
  public void setNoBean2(@Nullable Member member) {
     System.out.println("setNoBean2 = " + member);
  }

방법 3 : Optional<>

: 자동 주입할 대상이 없으면 Optional.empty가 입력된다.

  //Optional.empty 호출
  @Autowired(required = false)
  public void setNoBean3(Optional<Member> member) {
      System.out.println("setNoBean3 = " + member);
  }

출력 결과

setNoBean2 = null
setNoBean3 = Optional.empty

• Member는 스프링 빈이 아니다.
• setNoBean1() 은 @Autowired(required=false) 이므로 호출 자체가 안된다.

참고

• @Nullable, Optional은 스프링 전반에 걸쳐서 지원된다.
• 예를 들어서 생성자 자동 주입에서 특정 필드에만 사용해도 된다.

Lombok

@RequiredArgsConstructor

• final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다.
• 롬복이 자바의 애노테이션 프로세서라는 기능을 이용해서 컴파일 시점에 생성자 코드를 자동으로 생성해준다.

@Autowired와 중복 타입의 빈 충돌

• @Autowired : Type으로 조회함 타입으로 조회하면 선택된 빈이 2개 이상일 때 문제가 발생한다.
  • 발생하는 오류 : NoUniqueBeanDefinitionException

해결 방법

• 하위 타입으로 지정 : DIP를 위배하고 유연성이 떨어진다.
• 타입이 똑같은 빈 여러 개 or 자식 여러 개 : 해결이 안된다.
• 빈 수동 등록도 방법이지만, 의존관계 자동 주입에서도 해결 가능

방법 1 : @Autowired 매칭 방법

1. 타입 매칭
2. 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

방법 2 : @Qualifier

: 추가 구분자를 붙여주는 방법

• 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아니다

즉,

1. @Qualifier끼리 매칭
2. 빈 이름 매칭
3. NoSuchBeanDefinitionException 예외 발생

방법

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}

• 생성자 자동 주입

  @Autowired
  public OrderServiceImpl(MemberRepository memberRepository,
                          @Qualifier("mainDiscountPolicy") DiscountPolicy 
  discountPolicy) {
      this.memberRepository = memberRepository;
      this.discountPolicy = discountPolicy;
  }

• 수정자 자동 주입

  @Autowired
  public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy")
  DiscountPolicy discountPolicy) {
      this.discountPolicy = discountPolicy;
  }

  참고

  • @Qualifier 로 주입할 때 @Qualifier("mainDiscountPolicy")를 못찾으면 → mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는다.
  • 하지만 경험상 @Qualifier는 같은 @Qualifier를 찾는 용도로만 사용하는게 명확하고 좋다.

방법 3 : @Primary

@Primary는 우선순위를 정하는 방법이다. @Autowired 시에 여러 빈이 매칭되면 @Primary가 우선권을 가진다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Qualifier vs @Primary

• Main-DB Connection 획득 스프링 빈 : @Primary를 적용해서 조회하는 곳에서 @Qualifier 지정 없이 편리하게 조회
• Sub-DB Connection 획득 스프링 빈 : @Qualifier를 지정해서 명시적으로 획득 하는 방식으로 사용

→ 코드를 깔끔하게 유지할 수 있다.

둘 중 적용되는 우선순위는?

• 스프링은 자동보다는 수동이, 넒은 범위의 선택권 보다는 좁은 범위의 선택권이 우선 순위가 높다. → 여기서도 @Qualifier 가 우선권이 높다

Annotation 직접 만들기

package hello.core.annotataion;

import org.springframework.beans.factory.annotation.Qualifier;
import java.lang.annotation.*;

@Target({ElementType.FIELD, ElementType.METHOD,ElementType.PARAMETER,ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}

• 애노테이션에는 상속이라는 개념이 없다. 이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다. - @Qulifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다.
  • 단적으로 @Autowired도 재정의 할 수 있다. 물론 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의 하는 것은 유지보수에 더 혼란만 가중할 수 있다.

Spring과 전략 패턴

• 의도적으로 정말 해당 타입의 스프링 빈이 다 필요한 경우도 있다. 예를 들어서 할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자.
• 스프링을 사용하면, 정말 쉽게 전략 패턴을 사용할 수 있다.

package hello.core.autowired;

import hello.core.AutoAppConfig;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import java.util.List;
import java.util.Map;

import static org.assertj.core.api.Assertions.assertThat;

public class AllBeanTest {

    @Test
    void findAllBean() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);

        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");

        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
    }

    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;

        @Autowired
        public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }

        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);

            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);

            return discountPolicy.discount(member, price);
        }
    }
}

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

1) 기본 권장 - 편리한 자동 기능 사용

• 스프링은 @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다.
• 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계했다.
• 결정적으로 자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있다.

2) 그러면, 수동 기능은 언제?

2-1) 기술 지원 빈에 사용

: 애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체에 사용!

Tip 애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다.

• 업무 로직 빈
  • 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리 등등
  • 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
• 기술 지원 빈
  • 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용됨
  • 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들

업무 로직

• 숫자도 매우 많음
• 한번 개발해야 하면 컨트롤러, 서비스, 리포지토리 처럼 어느정도 유사한 패턴이 있음
• 보통 문제가 발생해도 어떤 곳에서 문제가 발생했는지 명확하게 파악하기 쉬움

기술 지원 로직

• 업무 로직과 비교해서 그 수가 매우 적음
• 보통 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미침
• 적용이 잘 되고 있는지 아닌지 조차 파악하기 어려운 경우가 많음
• 이런 기술 지원 로직은 가급적 수동 빈 등록을 사용해서 명확하게 드러내는 것이 좋다.

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

2-2) 특이 케이스 : 비즈니스 로직 중에서도 수동이 필요할 경우

: 다형성을 적극 활용할 때!

• 위의 AllBeanTest 같은 경우, 어떤 빈들이 주입될지, 각 빈의 이름이 무엇일지 등은 코드만 보고 파악하기 어렵다.

  • 자동 등록을 사용하고 있기 때문에, 파악하려면 여러 코드를 찾아봐야 함!

• 이럴 경우에는, 수동 빈으로 등록하거나 또는 자동으로 하면 특정 패키지에 같이 묶어두는 게 좋다!

  👉🏻 핵심은, 딱 보고 이해가 되어야 한다!

  • 수동 빈으로 등록하기

    @Configuration
    public class DiscountPolicyConfig {
    
       @Bean
       public DiscountPolicy rateDiscountPolicy() {
            return new RateDiscountPolicy();
       }
    
       @Bean
       public DiscountPolicy fixDiscountPolicy() {
            return new FixDiscountPolicy();
       }
    }

💡 참고!

• 스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외다.
  • 이런 부분들은 스프링 자체를 잘 이해하고 스프링의 의도대로 잘 사용하는게 중요하다.
  • ex) Spring Boot : DataSource 같은 데이터베이스 연결에 사용하는 기술 지원 로직까지 내부에서 자동으로 등록하는데, 이런 부분은 메뉴얼을 잘 참고해서 스프링 부트가 의도한 대로 편리하게 사용하면 된다.
• 반면에 스프링 부트가 아니라 내가 직접 기술 지원 객체를 스프링 빈으로 등록한다면 수동으로 등록해서 명확하게 드러내는 것이 좋다.

• 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다.

• Bean 이름 : 기본설정) 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.

• 단, 이름을 직접 설정하고 싶으면@Component("memberService2") 처럼 애너테이션에다 입력하여 설정

1-1. 탐색할 패키지 지정

• 모든 자바 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다. 그래서 꼭 필요한 위치부터 탐색하도록 시작 위치를 지정할 수 있다.

• basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다.

  @Configuration      // Component Scan 사용하기 위해 붙이는 Annotation
  @ComponentScan(
          basePackages = "hello.core.member",
          excludeFilters = @ComponentScan.Filter(type= FilterType.ANNOTATION, classes = Configuration.class)
  )
  public class AutoAppConfig {
  }

• basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.

• 지정 X : @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.

⭐ 권장하는 방법 패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것이다.

💡 참고 스프링 부트도 위와 같다. 스프링 부트를 사용하면 스프링 부트의 대표 시작 정보인 @SpringBootApplication를 이 프로젝트 시작 루트 위치에 두는 것이 관례이다. 이 설정안에 바로 @ComponentScan이 들어있다.

1-2. Filter

• includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다.
• excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정한다

FilterType 옵션

• ANNOTATION - 기본값, 애노테이션을 인식해서 동작한다. (org.example.SomeAnnotation)
• ASSIGNABLE_TYPE - 지정한 타입과 자식 타입을 인식해서 동작한다. (org.example.SomeClass)
• ASPECTJ - AspectJ 패턴 사용 (org.example..*Service+)
• REGEX - 정규 표현식 (org\.example\.Default.*)
• CUSTOM - TypeFilter 이라는 인터페이스를 구현해서 처리(org.example.MyTypeFilter)

💬 참고

• @Component면 충분하기 때문에, includeFilters를 사용할 일은 거의 없다.
• excludeFilters는 여러가지 이유로 간혹 사용할 때가 있지만 많지는 않다.
• 특히 최근 스프링 부트는 컴포넌트 스캔을 기본으로 제공하는데, 옵션을 변경하면서 사용하기보다는 스프링의 기본 설정에 최대한 맞추어 사용하는 것이 권장되는 편이다.

1-3. Component Scan 기본 대상

• @Component : 컴포넌트 스캔에서 사용
• @Controlller : 스프링 MVC 컨트롤러에서 사용
• @Service : 스프링 비즈니스 로직에서 사용
• @Repository : 스프링 데이터 접근 계층에서 사용
• @Configuration : 스프링 설정 정보에서 사용

💡 참고 사실 애노테이션에는 상속관계라는 것이 없다. 그래서 이렇게 애노테이션이 특정 애노테이션을 들고 있는 것을 인식할 수 있는 것은 자바 언어가 지원하는 기능은 아니고, 스프링이 지원하는 기능이다.

1-4. 위의 Annotation들의 스프링 부가 기능

• @Controller : 스프링 MVC 컨트롤러로 인식
• @Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다.
• @Configuration : 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다.
• @Service : 사실 특별한 처리를 하지 않는다. 대신 개발자들이 핵심 비즈니스 로직이 여기에 있겠구나 라고 비즈니스 계층을 인식하는데 도움이 된다.

💬 참고 useDefaultFilters 옵션은 기본으로 켜져있는데, 이 옵션을 끄면 기본 스캔 대상들이 제외된다. (그냥 알고만 넘어가기)

1-5. 중복 등록과 충돌

Case 1 : 자동 빈 등록 vs 자동 빈 등록

• 컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다.
• 발생하는 예외 : ConflictingBeanDefinitionException

Case 2 : 수동 빈 등록 vs 자동 빈 등록

• 수동 빈 등록이 우선권을 가진다. (수동 빈이 자동 빈을 오버라이딩 해버린다.)

• 의도했다면 모르겠지만, 보통은 여러 설정들이 꼬여서 이런 결과가 만들어진다. 그러면 정말 잡기 어려운 버그가 만들어진다.

• 그래서 최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꾸었다.

  Consider renaming one of the beans or enabling overriding by setting 
  spring.main.allow-bean-definition-overriding=true

  • 오버라이딩하도록 하고 싶다면 spring.main.allow-bean-definition-overriding=true 설정하면 됨

⭐ 개발을 하다 보면 중요한 교훈 명확하지 않은 것은 피하라.

• 어설픈 추상화나, 어설픈 우선 순위는 나중에 정말 잡기 힘든 버그를 만든다.

2. @Autowired

• 스프링은 의존관계를 자동으로 주입하는 @Autowired라는 기능도 제공한다.
• 생성자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.
• 이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다.

💡 Singleton Container가 필요한 이유? 스프링 없는 순수한 DI 컨테이너 : 요청을 할 때 마다 객체를 새로 생성

• 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성 / 소멸 : 메모리 낭비

👉🏻 해결방안 : 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하기 : 싱글톤 패턴

Singleton Pattern

: 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

구현 방법

• 객체 인스턴스를 2개 이상 생성하지 못하도록 막기
  • 간단한 방법 :private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 함

    그러면 생성자 쓰면 Compile Error 터짐 세상에서 제일 좋은 오류 = 컴파일오류

💡 참고 싱글톤 패턴을 구현하는 방법은 여러 가지가 있다. 여기에서는 객체를 미리 생성해두는, 가장 단순하고 안전한 방법을 선택했다.

Singleton Pattern의 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. → DIP를 위반한다.
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어진다.
• 안티패턴으로 불리기도 한다.

Singleton Container

• 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다.
• 스프링 빈 : 싱글톤으로 관리됨

SingletonRegistry

: 싱글톤 객체를 생성하고 관리하는 기능

• 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.
  • 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다.
  • DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤을 사용할 수 있다.

💡 참고

• 스프링의 기본 빈 등록 방식 = 싱글톤
• 단, 싱글톤 이외의 방식도 존재! 요청때마다 새로운 객체를 생성해서 반환하는 기능도 제공

Singleton 방식의 주의점

• 싱글톤 방식 : 무상태(stateless)로 설계해야 한다
  • 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문!
  • 특정 클라이언트에 의존적인 필드가 있으면 안됨
  • 가급적 읽기만 가능해야 함
• 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
• 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!!

💡 정리

• 실무에서 이런 경우를 종종 보는데, 이로인해 정말 해결하기 어려운 큰 문제들이 터진다.(몇년에 한번씩 꼭 만난다.)
• 진짜 공유필드는 조심해야 한다! 스프링 빈은 항상 무상태(stateless)로 설계하자.

@Configuration

: 싱글톤을 위해 존재함!

방법

• 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.

  • AnnotationConfigApplicationContext에 파라미터로 넘긴 값은 스프링 빈으로 등록된다. 그래서 AppConfig도 스프링 빈이 된다.
  • 단, 순수한 클래스로 등록되지 않는다.
  • 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한다.

• AppConfig@CGLIB 예상 코드

  @Bean
  public MemberRepository memberRepository() {
  
     if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
             return 스프링 컨테이너에서 찾아서 반환;
     } else { //스프링 컨테이너에 없으면
             기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
             return 반환
     }
  }

  💡 참고 AppConfig@CGLIB는 AppConfig의 자식 타입이므로, AppConfig 타입으로 조회 할 수 있다.

그럼, @Configuration 적용하지 않을 경우?

• @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.

👉🏻 정리 크게 고민할 것이 없다. 스프링 설정 정보는 항상 @Configuration을 사용하자

• API를 쓸모 있게 하려면 문서를 잘 작성해야 함
• 사람이 직접 작성하려면 코드가 수정될 때마다 매번 함께 수정해줘야 함

Javadoc

• Javadoc(자바독): API 문서 수정 등을 사람 대신 해줄 수 있는 자바의 유틸리티
• 소스코드 파일에서 문서화 주석(doc comment; 자바독 주석)이라는 특수한 형태로 기술된 부분을 추려서, API 문서로 변환함

doc comment 업계 표준 규칙

• 공식 언어 명세에는 속하지는 앟지만, 자바 프로그래머라면 응당 알아야 하는 업계 표준 API
• 「문서화 주석 작성법（How to Write Doc Comments）」웹페이지에 기술되어 있음 👉🏻 How to Write Doc Comments for the Javadoc Tool
• 자바 버전이 올라가며 추가된 몇 가지 중요한 태그
  • Java 5 - @literal, @code
  • Java 8 - @implSpec, @index
  • Java 9 - @index

API 문서화 주석 작성하기

공개 클래스

• API를 올바로 문서화하려면, 공개된 모든 클래스, 인터페이스, 메서드, 필드 선언에 문서화 주석을 달아야 함
• 직렬화할 수 있는 클래스라면 직렬화 형태에 관해서도 적어야 함
• 기본 생성자에는 문서화 주석을 달 방법이 없으니 공개 클래스는 절대 기본 생성자를 사용하면 안 됨

📌 문서화 주석을 제대로 작성하지 않으면?

• 문서화 주석이 없다면 Javadoc도 그저 공개 API 요소들의 선언만 나열해주는 것이 전부임!
• 문서가 잘 갖춰지지 않은 API는 쓰기 헷갈려서 오류의 원인이 되기 쉬움

공개되지 않은 클래스

• 유지보수까지 고려한다면 대다수의 공개되지 않은 클래스, 인터페이스, 생성자, 메서드, 필드에도 주석을 달아야 함(공개 API보다는 덜 상세해도 됨)

메서드용 문서화 주석

• 해당 메서드와 클라이언트 사이의 규약을 명료하게 기술하기

• 상속용으로 설계된 클래스의 메서드가 아니라면, 무엇을 하는지를 기술하기 - how (x), what (o)

• 메서드의 계약(contract)를 완벽히 기술하려면,

  • 모든 매개변수에 @param 태그
  • 반환타입이 void가 아니라면 @return 태그
  • 발생할 가능성이 있는 모든 예외에 @throws 태그 (검사 예외, 비검사 예외 모두)

    📌 참고! 만약 여러분이 따르는 코딩 표준에서 허락한다면 @return 태그의 설명이 메서드 설명과 같을 때에는 @return 태그 생략 가능

• 전제조건(precondition)

  • 클라이언트가 해당 메서드를 호출하기 위한 조건들
  • 전제조건을 모두 나열해야 함
  • @throws 태그 : 비검사 예외를 선언하여 암시적으로 기술함. 비검사예외 하나가 전제조건 하나와 연결됨!
  • @param 태그 : 그 조건에 영향받는 매개변수에 기술함

• 사후조건(postcondition)

  • 메서드가 성공적으로 수행된 후 만족해야 하는 조건들
  • 사후조건도 모두 나열하기

• 부작용

  • 사후조건으로 명확히 나타나지는 않지만 시스템의 상태에 어떠한 변화를 가져오는 것을 뜻함
  • ex) 백그라운드 스레드를 시작시키는 메서드 - 그 사실을 문서에 밝혀야 함

태그 사용법

메서드용 주석 태그들

  /**
  * 이 리스트에서 지정한 위치의 원소를 반환한다.
  *
  * <p>이 메서드는 상수 시간에 수행됨올 보장하지 <i>않는다</i>. 구현에 따라
  * 원소의 위치에 비례해 시간이 걸릴 수도 있다.
  *
  * @param  index 반환할 원소의 인덱스; 0 이상이고 리스트 크기보다 작아야 한다.
  * @return 이 리스트에서 지정한 위치의 원소
  * @throws IndexOutOfBoundsException index가 범위를 벗어나면,
  *         즉, ({@code index < 0 || index >= this.size()}》이면 발생한다.
  */
  E get(int index);

(영어 버전)

  /**
  * Returns the element at the specified position in this list.
  *
  * <p>This method is <i>not</i> guaranteed to run in constant
  * time. In some implementations it may run in time proportional
  * to the element position.
  *
  * @param index index of element to return; must be
  *        non-negative and less than the size of this list
  * @return the element at the specified position in this list
  * @throws IndexOutOfBoundsException if the index is out of range
  *         ({@code index < 0 || index >= this.size()})
  */
  E get(int index);

💬 Javadoc 유틸리티는 문서화 주석을 HTML로 변환함

• 문서화 주석에 HTML 태그를 사용 - <p>, <i>
• HTML 표(table)까지 집어넣는 프로그래머도 있음

• @param

  • 해당 매개변수가 뜻하는 값이나 반환값을 설명하는 명사구를 씀
  • 드물게는 명사구 대신 산술 표현식을 쓰기도 함
  • 관례상 설명에 마침표를 붙이지 않음

• @return

  • 해당 매개변수가 뜻하는 값이나 반환값을 설명하는 명사구를 씀
  • 드물게는 명사구 대신 산술 표현식을 쓰기도 함
  • 관례상 설명에 마침표를 붙이지 않음

• @throws

  • if로 시작해 해당 예외를 던지는 조건을 설명하는 절이 뒤따름
  • 관례상 설명에 마침표를 붙이지 않음

• {@code} 태그

  • 첫번째 효과 : 태그로 감싼 내용을 코드용 폰트로 렌더링함
  • 두번째 효과 : 태그로 감싼 내용에 포함돈 HTML 요소나 다른 자바독 태그를 무시함 (HTML 메타 문자도 사용 가능)

    📌 여러 줄로 코드 예시를 넣으려면?

    • {@code} 태그를 다시 <pre> 태그로 감싸면 됨 (<pre> {@code ... 코드 ... } </pre> 형태)
    • 단，@ 기호에는 무조건 탈출문자를 붙여야 하니 문서화 주석 안의 코드에서 애너테이션을 사용한다면 주의!

• this

  • 관례상 인스턴스 메서드의 문서화 주석에 쓰인 this는 호출된 메서드가 자리하는 객체를 가리킴

상속용 클래스

• 자기사용 패턴(self-use pattern)에 대해서도 문서에 남겨 다른 프로그래머들에게 그 메서드를 올바로 재정의하는 방법을 알려줘야 함

/**
* 이 컬렉션이 비었다면 true를 반환한다.
*
* @implSpec
* 이 구현은 {@code this.sizeO = 0}의 결과를 반환한다.
*
* @return o| 컬렉션이 비었다면 true, 그렇지 않으면 false
*/
public boolean isEmpty() { ... }

(원어 버전)

/**
* Returns true if this collection is empty.
*
* @implSpec
* This implementation returns {@code this.size() = 0}.
*
* @return true if this collection is empty
*/
public boolean isEmpty() { ... }

• @impleSpec

  • 해당 메서드와 하위 클래스 사이의 계약을 설명함
  • 하위 클래스들이 그 메서드를 상속하거나, super 키워드를 이용하여 호출할 때 그 메서드가 어떻게 동작하는지를 명확히 인지하고 사용하기

  💬 impleSpec이 독특한 케이스! 일반적인 문서화 주석은 해당 메서드와 클라이언트 사이의 계약을 설명함

  💬 @impleSpec 활용 방법 자바 11까지도 자바독 명령줄에서 -tag "implSpec:a:Implementation Requirements:" 스위치를 켜주지 않으면@implSpec 태그를 무시해버린다. 다음 버전에 서는 기본값으로 적용되길 기대해본다.

주석에 <, >, & 등의 HTML 메타문자 포함시키기

특별한 처리가 필요함!

• {@literal}
  • 가장 좋은 방법
  • HTML 마크업이나 자바독 태그를 무시하게 해줌
  • 앞서 본 {@code} 태그와 비슷하지만, 코드 폰트로 렌더링하지는 않음 ```java
  • {@literal |r| < 1}이면 기하 수열이 수렴한다. ```
  • 기호만 {@literal}로 감싸도 결과는 같지만, 그러면 코드에서의 가독성이 떨어짐

    💡 원칙

    • 문서화 주석은 코드에서건 변환된 API 문서에서건 읽기 쉬워야 한다!
    • 단, 양쪽을 만족하지 못하겠다면 API문서에서의 가독성을 우선시!

문서화 주석 form

  /**
  * 이 리스트에서 지정한 위치의 원소를 반환한다.
  *
  * <p>이 메서드는 상수 시간에 수행됨올 보장하지 <i>않는다</i>. 구현에 따라
  * 원소의 위치에 비례해 시간이 걸릴 수도 있다.
  *
  * @param  index 반환할 원소의 인덱스; 0 이상이고 리스트 크기보다 작아야 한다.
  * @return 이 리스트에서 지정한 위치의 원소
  * @throws IndexOutOfBoundsException index가 범위를 벗어나면,
  *         즉, ({@code index < 0 || index >= this.size()}》이면 발생한다.
  */
  E get(int index);

첫 번째 문장 : summary descripsion

• 해당 요소의 요약 설명

  • 반드시 대상의 기능을 고유하게 설명해야 함
  • 헷갈리지 않으려면, 한 클래스/인터페이스 안에서 요약 설명이 똑같은 멤버/생성자가 둘 이상이면 안 됨
  • 다중정의된 메서드는 특히 더 조심하기! 같은 문장으로 시작하는 것이 허용되지 않음

• 마침표(.) 주의하기!

  • 첫 번째 마침표가 나오는 부분까지만 요약 설명이 됨

    * 머스터드 대령이나 Mrs. 피콕 같은 용의자.

    📌 요약 설명이 끝나는 판단 기준

    • {<마침표><공백><다음 문장 시작>} 패턴의<마침표>
    • <다음 문장 시작>은 ‘소문자가 아닌’문자
    • 예시에서는 “Mrs.” 다음에 공백이 나오고 다음 단어인 ‘피’가 소문자가 아니므로 요약 설명이 끝났다고 판단한 것!

  • 가장 좋은 해결책은 의도치 않은 마침표를 포함한 텍스트를 {@literal}로 감싸주는 것

    /**
     * 머스타드 대령이나 {@literal Mrs. 피콕} 같은 용의자.
     */

    💡 Tip

    • 자바 10부터는 {@summary}라는 요약 설명 전용 태그가 추가되어, 다음처럼 한결 깔끔하게 처리할 수 있다. ```java /**
    • {@summary 머스타드 대령이나 Mrs. 피콕 같은 용의자.}
    • / public enum Suspect { ... } ```

• 주석 작성 규약에 따르면, 요약 설명은 완전한 문장이 되는 경우가 드뭄(즉, 주어가 없을 때가 많음)

  • 메서드/생성자의 요약 설명 : 해당 메서드와 생성자의 동작을 설명하는 (주어가 없는) 동사구
    • ArrayList(int initialcapacity) : Constructs an empty list with the specified initial capacity.
    • Collection.size() : Returns the number of elements in this collection.
    • 2인칭 문장(return the number)이 아닌 3인칭 문장(returns the number)으로 써야 한다.
  • 클래스/인터페이스의 요약 설명 : 인스턴스를 설명하는 명사절
    • Instant : 타임라인상의 특정 순간(지점)
  • 필드의 요약 설명 : 필드 자신을 설명하는 명사절
    • Math.PI : 원주율(pi)에 가장 가까운 double 값

JavaDoc과 색인 기능

• Java 9부터 추가됨
• API 문서 페이지 오른쪽 위에 있는 검색창에 키워드를 입력하면 관련 페이지들이 드롭다운 메뉴로

방법

• 클래스，메서드，필드 같은 API 요소의 색인은 자동으로 만들어짐
• 원하면 {@index} 태그를 사용해 색인으로 만들 용어를 태그로 감싸 중요한 용어를 추가로 색인화할 수 있음

  * 이 메서드는 {@index IEEE 754} 표준을 준수한다.

제네릭

제네릭 타입이나 제네릭 메서드를 문서화할 때는 모든 타입 매개변수에 주석을 달아야 한다.

/**
* 키와 값을 매핑하는 객체. 맵은 키를 중복해서 가질 수 없다.
* 즉，키 하나가 가리킬 수 있는 값은 최대 1개다.
*
* （나머지 설명은 생략》
*
* @param <K> 이 맵이 관리하는 키의 타입
* Qparam <V> 매핑된 값의 타입
*/
public interface Map<K, V> { ... }

열거 타입

열거 타입을 문서화할 때는 상수들에도 주석을 달아야 한다. 열거 타입 자체와 그 열거 타입의 public 메서드도 물론이다. 설명이 짧다면 주석 전체를 한 문장으로 써도 된다.

/**
* 심포니 오케스트라의 악기 세션.
*/
public enum Orchestrasection {
    /** 폴루트，클라리넷, 오보 같은 목관악기. */
    WOODWIND,

    /** 프렌치 호른，트럼펫 같은 금관악기. */
    BRASS,

    /** 탐파니, 심벌즈 같은 타악기. */
    PERCUSSION,

    /** 바이울린，젤로 같은 현악기. */
    STRING；
}

애너테이션

애너테이션 타입을 문서화할 때는 멤버들에도 모두 주석을 달아야 한다. 애너테이션 타입 자체도 물론이다.

• 필드 설명은 명사구로 한다.
• 애너테이션 타입의 요약 설명은 프로그램 요소에 이 애너테이션을 단다는 것이 어떤 의미인지를 설명하는 동사구로 한다. (한글로 쓴다면 동사로 끝나는 평범한 문장이면 된다.)

/**
* 이 애너테이션이 달린 메서드는 명시한 예외를 던져야만 성공하는
* 테스트 메서드임을 나타낸다.
*/
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ExceptionTest {
    /**
    * 이 애너테이션을 단 테스트 메서드가 성공하려면 던져야 하는 예외.
    * (이 클래스의 하위 타입 예외는 모두 허용된다.》
    */
    Class<? extends Throwable> valueO;
}

패키지 & 모듈

• 패키지를 설명하는 문서화 주석은 package-info.java 파일에 작성한다.

  • 이 파일은 패키지 선언을 반드시 포함해야 하며 패키지 선언 관련 애너테이션을 추가로 포함할 수도 있다.

• 자바 9부터 지원하는 모듈 시스템을 사용한다면 모듈 관련 설명은 module-info.java 파일에 작성하면 된다

유의 사항

API 문서화에서 자주 누락되는 설명이 두 가지 있으니，바로 스레드 안전성과 직렬화 가능성이다.

• 클래스 혹은 정적 메서드가 스레드 안전하든 그렇지 않든, 스레드 안전 수준을 반드시 API 설명에 포함해야 한다.

• 직렬화할 수 있는 클래스라면 직렬화 형태도 API 설명에 기술해야 한다.

• 자바독은 메서드 주석을 ‘상속’시킬 수 있다.

  • 문서화 주석이 없는 API 요소를 발견하면 자바독이 가장 가까운 문서화 주석을 찾아준다. 이때 상위 ‘클래스’보다 그 클래스가 구현한 ‘인터 페이스’를 먼저 찾는다.
  • {@inheritDoc} 태그를 사용해 상위 타입의 문서화 주석 일부를 상속할 수 있다. 클래스는 자신이 구현한 인터페이스의 문서화 주석을 (복사해 붙여넣지 않고) 재사용할 수 있다는 뜻이다. 이 기능을 활용하면 거의 똑같은 문서화 주석 여러 개를 유지보수하는 부담을 줄일 수 있지만，사용하기 까다롭고 제약도 조금 있다.

• 비록 공개된 모든 API 요소에 문서화 주석을 달았더라도，여러 클래스가 상호작용하는 복잡한 API라면 문서화 주석 외에도 전체 아키텍처를 설명하는 별도의 설명이 필요할 때가 왕왕 있다.

  • 이런 설명 문서가 있다면 관련 클래스나 패키지의 문서화 주석에서 그 문서의 링크를 제공해주면 좋다.

JavaDoc

• 자바독은 프로그래머가 자바독 문서를 올바르게 작성했는지 확인하는 기능을 제공하며，이번 아이템에서 소개한 권장사항 중 상당수를 검사해준다.
• 자바 9와 10의 자바독은 기본적으로 HTML4.01 문서를 생성하지만，명령줄에서 -htmI5 스위치를 켜면 HTML 5 버전으로 만들어준다.

검사 방법

• 자바 7에서는 명령줄에서 -Xdoclint 스위치를 켜주면 이 기능이 활성화되고，자바 8부터는 기본으로 작동한다.
• 체크스타일(checkstyle) 같은 IDE 플러그인을 사 용하면 더 완벽하게 검사된다.

HTML 유효성 검사기

• 자바독이 생성한 HTML 파일을 HTML 유효성 검사기로 돌리면 문서화 주석의 오류를 한층 더 줄일 수 있다.
• HTML 유효성 검사기는 잘못 사용한 HTML 태그를 찾아준다.
• 로컬에 내려받아 사용할 수 있는 설치형 검사기도 있고，웹에서 바로 사용할 수 있는 W3C 마크업 검사 서비스[W3C-validator]도 있다.

참고 사이트

• 문서화 주석 작성법

정리

• 문서화 주석은 여러분 API를 문서화하는 가장 훌륭하고 효과적인 방법이다.

• 공개 API라면 빠짐없이 설명을 달아야 한다.

• 표준 규약을 일관되게 지키자.

  • 문서화 주석에 임의의 HTML 태그를 사용할 수 있음을 기억하라.
  • 단, HTML 메타문자는 특별하게 취급해야 한다.

• 잘 쓰인 문서인지를 확인하는 유일한 방법은 자바독 유틸리티가 생성한 웹페이지를 읽어보는 길뿐이다.

• 다른 사람이 사용할 API라면 반드시 모든 API 요소를 검토하라.

스프링 컨테이너와 빈

• 이전 포스팅까지는 개발자가 AppConfig를 사용해서 직접 조회했지만, 이제는 스프링 컨테이너에서 필요한 스프링 빈(객체)을 찾는다.
• 찾는 방법 : applicationContext.getBean() 메서드 이용

Spring Container

• ApplicationContext : 스프링 컨테이너
• @Configuration을 설정(구성) 정보로 사용
• 스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)한다.
• 단순히 자바 코드를 호출하는 것 같지만, 차이가 있다. 이 차이는 뒤에 싱글톤 컨테이너에서 설명한다.

ApplicationContext

• 스프링 컨테이너
• 인터페이스
• XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수도 있다.

  // 스프링 컨테이너 생성
  // 애노테이션 기반의 자바 설정을 하겠다는 코드
  ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

• 자바 설정 클래스를 기반으로 스프링 컨테이너를 만들 수 있다.
  • 단, 그러기 위해서는 스프링 컨테이너를 생성할 때 구성 정보를 지정해주어야 한다.

Spring Container의 생성 과정

💡 참고 정확하게는, 스프링 컨테이너를 부를 때는 BeanFactory와 ApplicationContext를 구분해서 이야기한다. 단, BeanFactory를 직접 사용하는 경우는 거의 없으므로, 일반적으로 ApplicationContext = 스프링 컨테이너라고 이야기한다.

Spring Bean

• @Bean이라 적힌 메서드를 모두 호출해서, 반환된 객체를 스프링 컨테이너에 등록한다.
• 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다.
• @Bean이 붙은 메서드 명을 스프링 빈의 이름으로 사용

빈 이름

• 빈 이름은 메서드 이름을 사용한다.
• 빈 이름을 직접 부여할 수도 있다.
• 설정 방법 : @Bean (name="memberService2)"

💡 주의 단, 빈 이름은 항상 다른 이름을 부여해야 한다. 같은 이름을 부여하면, 다른 빈이 무시되거나 기존 빈을 덮어버리거나 등 설정에 따라 오류가 발생한다.

의존관계 주입

• 스프링은 ①빈을 생성하고, ②의존관계를 주입하는 단계가 나누어져 있다.
• 그런데 이렇게 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다.
• 여기서는 이해를 돕기 위해 개념적으로 나누어 설명했다. 자세한 내용은 의존관계 자동 주입에서 다시 설명하겠다.

빈 조회

• 부모 타입으로 조회하면, 자식 타입도 함께 조회된다.
• 그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈이 조회된다.

Application & BeanFactory

BeanFactory

• 스프링 컨테이너의 최상위 인터페이스
• 스프링 빈을 관리하고 조회하는 역할을 담당

ApplicationContext

• BeanFactory 기능을 모두 상속받아서 제공

그럼 BeanFactory와 ApplicationContext의 차이점은?

• Application을 개발할 때, 빈을 관리하고 검색해주는 기능 외에도 수많은 부가기능이 필요하다.

• MessageSource : 국제화 기능 ex) 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력
• EnvironmentCapable : 환경변수 로컬 / 개발 / 운영 등을 구분해서 처리
• ApplicationEventPublisher : 애플리케이션 이벤트 이벤트를 발행하고 구독하는 모델을 편리하게 지원
• ResourceLoader : 편리한 리소스 조회 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

💬 요약

• BeanFactory나 ApplicationContext를 스프링 컨테이너라 한다.
• BeanFactory를 직접 사용할 일은 거의 없다. 부가기능이 포함된 ApplicationContext를 사용한다.
  • ApplicationContext는 BeanFactory의 기능을 상속받는다.
  • ApplicationContext는 빈 관리기능 + 편리한 부가 기능을 제공한다.

Spring Container 설정

스프링 컨테이너는 다양한 형식의 설정 정보를 받아들일 수 있게 유연하게 설계되어 있음

• Java 코드
• XML
• GRoovy ...

스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까? -> BeanDefinition 이라는 추상화 덕분!

BeanDefinition

BeanDefinition 정보

• BeanClassName: 생성할 빈의 클래스 명(자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음)
• factoryBeanName: 팩토리 역할의 빈을 사용할 경우 이름, 예) appConfig
• factoryMethodName : 빈을 생성할 팩토리 메서드 지정, 예) memberService
• Scope: 싱글톤(기본값)
• lazyInit : 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아니라, 실제 빈을 사용할 때 까지 최대한 생성을 지연처리 하는지 여부
• InitMethodName : 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명
• DestroyMethodName : 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명
• Constructor arguments, Properties: 의존관계 주입에서 사용한다. (자바 설정처럼 팩토리 역할의 빈을 사용하면 없음)

1. AnnotationConfigApplicationContext : AnnotatedBeanDefinitionReader 를 사용해서 AppConfig.class를 읽고 BeanDefinition을 생성
2. GenericXmlApplicationContext : XmlBeanDefinitionReader를 사용해서 appConfig.xml 설정 정보를 읽고 BeanDefinition 을 생성
3. 새로운 형식의 설정 정보를 추가하려면, XxxBeanDefinitionReader를 만들어서 BeanDefinition을 생성하면 됨!

💬 정리

• BeanDefinition을 직접 생성해서 스프링 컨테이너에 등록할 수도 있다. (하지만 실무에서 BeanDefinition을 직접 정의하거나 사용할 일은 거의 없다.)
• 스프링이 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용하는 것 정도만 이해하면 된다. (가끔 스프링 코드나 스프링 관련 오픈 소스의 코드를 볼 때, BeanDefinition 이라는 것이 보일 때가 있다. 이때 이러한 메커니즘을 떠올리면 된다.)

제어의 역전

• Spring에만 국한된 용어는 아님
• 프로그램의 제어 흐름을 직접 제어하는 것이 아니라, 외부에서 관리하는 것
  • ex) AppConfig가 프로그램의 제어 흐름을 가져감

📌 Framework vs Library

• 프레임워크 : 내가 작성한 코드를 제어하고, 대신 실행함 (ex: JUnit)
• 라이브러리 : 내가 작성한 코드가 직접 제어의 흐름을 담당함

2. DI (Dependency Injection)

의존성 주입

2-1. 정적인 클래스 의존관계

• 클래스가 사용하는 import 코드만 보고도 의존 관계를 쉽게 파악할 수 있다.
• 애플리케이션을 실행하지 않아도 분석할 수 있다.

2-2. 동적인 객체(인스턴스) 의존 관계

• 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계

• Dependency Injection(의존관계 주입) : 애플리케이션 런타임(실행 시점)에 외부에서 실제 구현 객체를 생성하고, 클라이언트에 전달해서, 클라이언트와 서버의 실제 의존 관계가 연결되는 것

• 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.

💡 의존관계 주입을 사용하면?

• 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 정적인 클래스 의존관계를 변경하지 않고(Application 코드를 손 대지 않고), 동적인 객체 인스턴스의 의존관계를 쉽게 변경할 수 있다.

3. IoC 컨테이너, DI 컨테이너

: AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것

📌 모두 동의어!

• 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라고 함!
• Assembler라고도 불림 (레고를 조립하듯이 해서)
• Object Factory라고도 불림 (오브젝트를 만들어낸다고 해서)

새로운 할인 정책 개발

• 악덕 기획자 : 고정 금액 할인이 아닌, 10% 정률 할인으로 변경하고자 한다.

📣 참고 : 애자일 소프트웨어 개발 선언

0-1. 설계

RateDiscountPolicy

0-2. 설계 변경에서 발견한 문제들!

• 현재의 코드는 OCP, DIP를 위반하고 있다.

public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
    // ↑ 변경 전
    // OCP 위반! - 결국 코드를 변경해야 하기 때문
    // DIP 위반! - 추상(인터페이스)에만 의존해야 하는데 구현(클래스)에도 의존하고 있기 때문

    // 그러면 이렇게 바꾸면?
    private DiscountPolicy discountPolicy;
    // => 당연히 NPE 발생!

    ...
    }
}

1. 관심사의 분리

• 배우는 본인의 배역을 수행하는 것에만 집중해야 한다.
• 남배우는 어떤 여자 주인공이 되더라도 똑같이 공연할 수 있어야 한다.
• 공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 공연 기획자가 필요하다.

1-1. AppConfig = 공연기획자

• 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 설정 클래스를 만들자.

• 애플리케이션의 실제 동작에 필요한 "구현 객체를 생성"한다.

• 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해 주입(연결)한다.

1-2. 이제는 DIP, OCP를 지키는 것이다.

public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);
        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

• MemberServiceImpl 입장에서 이제는 생성자를 통해 어떤 구현 객체가 들어올지는 알 수 없다.
• 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정한다.
• 이제 의존 관계에 대한 고민은 외부에 맡기고, 담당 배우들은 기능을 실행하는 책임만 지면 된다!

1-3. 변경된 클래스 다이어그램

• 클라이언트인 memberServiceImpl 입장에서 보면, 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection), 우리 말로 의존관계 주입 또는 의존성 주입이라고 한다.

2. 리팩터링

2-1. AppConfig 리팩토링

변경 후

public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    private MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

장점

• 나중에 DB를 바꾸고 싶더라도, 이 AppConfig만 변경하면 됨!
• AppConfig를 통해, 역할과 구현 클래스가 한 눈에 들어옴. 또, 애플리케이션 전체 구성이 어떻게 되어 있는지 빠르게 파악할 수 있음

• 즉, 변경이 생기더라도 구성 영역만 손대면 되고, 사용 영역의 어떠한 코드도 변경할 필요가 없음!
• 구성 영역은 요구사항의 변경에 따라 당연히 변경됨!

회원

• 기능 : 회원 가입, 회원 조회
• 등급 : 일반 회원, VIP 회원 (2가지 등급)
• 회원 데이터는 자체 DB를 구축할 수도 있고, 외부 시스템과 연동할 수도 있다. (미정)

주문/할인 정책

• 회원은 상품을 주문할 수 있다.
• 회원 등급에 따라 할인 정책을 적용할 수 있다.
• 모든 VIP는 1000원을 할인해주는 고정 할인이 있다. (추후 변경 가능)
• 할인 정책 : 변경 가능성이 높다. 오픈 직정까지 고민을 미루고 싶다 (미확정)

📌 참고 이번 프로젝트는 스프링 없는 순수한 자바로만 개발을 진행한다.

2. 설계

2-1. 회원 관련 설계

• 기획자들도 볼 수 있는 다이어그램
  • 이를 바탕으로, 개발자들이 클래스 다이어그램을 그림
• DB를 어떻게 구축할지가 미정이기 때문에, 각 저장소 구현체들을 다양하게 만들어본다.
  • 메모리 회원 저장소 : 서버 켜면 그냥 메모리에만 저장되는, 개발용으로 사용하는 저장소

• 객체(구현체) 다이어그램 : 사실 동적으로 결정됨. 서버가 뜨면 사용자가 '실제로' 사용하는, 유효한 인스턴스와 관련된 다이어그램

📣 백문이불여일타 코드도 직접 쳐보는 것이 가장 좋다!

2-2. 주문과 할인 설계

📌 참고 1 여기에서는, 예제를 단순히 하기 위해 상품 클래스를 만들지 않고 그냥 상품 데이터를 넘겨 주문을 하기로 한다. 실무에서는 당연히 'Item' 등의 객체로 만들어서 하는 것이 일반적이다.

📌 참고 2 주문 정보를 DB에 저장하는 로직도, 예제를 단순히 하기 위해 생략한다.

👉🏻 역할과 구현이 이렇게 명확하게 구분되면, 회원 저장소와 할인 정책을 마치 레고 조립하듯이 자유롭게 조립할 수 있게 된다!

클래스 다이어그램

객체 다이어그램들

📌 Spring과 Java

• Spring : Java 언어 기반의 Framework
• Java : 객체 지향 언어라는 특징이 가장 대표적인 프로그래밍 언어

👉🏻 객체 지향 언어가 가진 강력한 특징을 살려내는 Framework (= 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 Framework)

1. 객체 지향 프로그래밍(Object Oriented Programming)

: 컴퓨터 프로그램을 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것

• 각각의 객체는 메시지를 주고 받고, 데이터를 처리할 수 있다.
• 프로그램을 유연하고 변경이 용이하게 만듦 → 대규모 소프트웨어 개발에 많이 사용됨

  👀 '유연하고 변경이 용이하다'란?

  • 레고 블록을 조립하듯이
  • 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법

1. Polymorphism (다형성)

📌 객체 지향의 특징

• 추상화
• 캡슐화
• 상속
• 다형성

우선, 세상을 역할과 구현으로 구분해보자.

• 운전자는 다른 자동차를 아무 문제 없이 운전할 수 있다.
• 이 말은 즉, 자동차들은 클라이언트에 영향을 주지 않고도 계속 출시 (확장)할 수 있다는 것!

핵심 : 역할과 구현을 분리한다.

• 세상이 단순해지고 유연해지며 변경도 편리해진다.
• 대상의 역할(인터페이스)만 알면 된다.
• 구현 대상의 내부 구조를 몰라도 된다.
• 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
• 구현 대상 자체를 변경해도 영향을 받지 않는다.

2. Java와 다형성

• 역할 = Interface
• 구현 = Interface를 구현한 Class, 구현 객체(Instance)

💡 핵심 구현보다 역할이 더 중요하다. 객체 설계 시에도 인터페이스가 더 먼저다!

• Overriding과 관련 깊음

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있음
• 협력이라는 객체 사이의 관계에서 시작해야 함
• 확장 가능한 설계
  • 클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경 가능
  • 인터페이스를 안정적으로 잘 설계하는 것이 매우 중요

📌 객체의 협력

• 혼자 있는 객체는 없다.
  • 클라이언트 : 요청
  • 서버 : 응답
• 수많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가짐

👀 "의존한다" = "알고 있다."

다형성의 한계

• 역할(인터페이스) 자체가 변하면, 클라이언트/서버 모두에 큰 변경 발생
• 인터페이스를 안정적으로 잘 설계하는 것이 매우 중요!

3. Spring과 객체 지향

• 다형성이 가장 중요하다!

  "객체지향의 꽃은 다형성이에요."

• 스프링 컨테이너 : 다형성을 편리하게 사용할 수 있도록 지원하는 기능. 그것이 거의 전부임

4. 객체지향과 SOLID 원칙

Robert Martin이 정리한 좋은 객체 지향 설계의 5가지 원칙

SRP (Single Reponsibility Principle)

단일 책임 원칙

• 한 클래스는 하나의 책임만 가져야 한다.
• 중요한 기준 : 변경
  • 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
  • ex: 객체의 생성과 사용을 분리

OCP (Open-Closed Principle)

개방-폐쇄 원칙

가장 중요한 원칙!

• 소프트웨어는 확장에는 열려있으나, 변경에는 닫혀있어야 한다.
• 다형성을 활용해보자.
  • 인터페이스를 구현한 새로운 클래스 만드는 것 : 확장
  • 인터페이스는 바뀌지 않는 것 : 변경에 닫혀있음

💡 문제점

• 분명히 다형성을 사용했지만, OCP 원칙을 지킬 수 없다.
• 기존 코드를 변경해야만 새로운 구현 클래스를 선택할 수 있게 된다. 👉🏻 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

LSP (Liskov Substitution Principle)

리스코프 치환 원칙

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

• 단순히 컴파일에 성공하는 것을 넘어서는 이야기

  • ex) 자동차 인터페이스의 엑셀 : 앞으로 가는 기능! 따라서 뒤로 가게 구현하면 LSP 위반. 속도와는 상관 없이 앞으로 가야 함!

ISP (Interface Segregation Principle)

인터페이스 분리 원칙

• 특정 클라이언트를 위한 인터페이스 여러 개가, 범용 인터페이스 하나보다 낫다.
  • 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스
  • 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.

DIP (Dependency Inversion Principle)

의존 관계 역전 원칙

• 추상화에 의존해야지, 구체화에 의존하면 안 된다.
• 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻! 즉, 역할(Role)에 의존하라! 구현체에 의존하게 되면, 변경이 아주 어려워진다.

💡 주의 MemeberService 클라이언트가 구현 클래스를 직접 선택하고 있음

MemberRepository m = new MemoryMemberRepository();

👉🏻 DIP 위반!

• MemberService는 MemberRepository 인터페이스만 의존하도록 설계해야 함

💡 요약

• 객체 지향의 핵심은 다형성
• 다형성만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수는 없음
• 다형성만으로는 OCP, DIP를 지킬 수 없는 경우도 있다. 무언가 더 필요하다.

5. Spring과 객체 지향 설계

• OCP, DIP 원칙을 지키면서 개발을 하려다 보면, 구현해둘 것이 너무 많았음 → 아예 프레임워크로 만들어둠

할 것

• 모든 설계에 역할과 구현을 분리하자
• 이상적으로는 모든 설계에 인터페이스를 부여하자

실무 고민

• 인터페이스를 도입하면, 추상화라는 비용이 발생한다.
• 기능을 확장할 가능성이 없다면, 우선은 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 방법!!

💡 스프링 제대로 공부하는 방법

• 단순히 스프링 기능을 배우고 사용하는 것은 어렵지 않다
• 그러나 IoC, DI 등의 용어 및 SOLID 객체지향 설계 원칙도 이해해야 스프링의 진정한 핵심 가치를 알 수 있게 됨

📌 스프링과 객체지향 프로그래밍

• 스프링 컨테이너가 왜 필요할까?

1. Spring의 탄생

Enterprise Java Beans(EJB)

: Java 진영의 표준 기술 중 최고봉

• 당시에는 EJB가 보급도 잘 되고, 가장 잘 나갔었음
• Container 기술, 설정에 의한 Transaction 관리, 분산 기술 등이 특징
  • Entity Bean(ORM 기술)도 있었음
• 단, 매우 비쌌고, 매우 복잡하고 어렵다는 단점이 있었음
  • 나중에는 옛날 자바 오브젝트로 돌아가자(POJO, Plain Old Java Object)라는 말까지 나왔음

💡 ORM (Object Relational Mapping, 객체-관계-매핑) : Java 객체를 쿼리를 사용하지 않고 DB에 편하게 CRUD할 수 있는 기술!

Spring

• Rod Johnson이 제안
• EJB 컨테이너 대체 기술
• 단순함의 승리
• 현재 사실상 표준 기술

Hibernate

• Gavin King이 제안
• EJB Entity Bean 기술 대체
• JPA 표준에서, JPA (Java Persistence API)를 새로운 표준으로 정의

JPA와 구현체

• JPA : 표준 인터페이스
• Hibernate, EclipseLink ... : JPA 구현체들

2. Spring의 역사

탄생

| 2002년 : Rod Johnson이 책 출간

• EJB의 문제점 지적
• EJB 없이도 충분히 고품질의 확장 가능한 애플리케이션을 개발할 수 있음을 보여주고, 30,000라인 이상의 기반 기술을 예제 코드로 선보임 (지금의 스프링 핵심 개념과 기반 코드)
• 들어있는 개념들
  • BeanFactory
  • ApplicationContext
  • POJO
  • 제어의 역전
  • 의존관계 주입

| 책 출간 직후 오픈소스로 개발

• Juergen Hoeller (유겐 휠러), Yahn Caroff(얀 카로프)가 로드 존슨에게 오픈소스 프로젝트를 제안
• Spring의 핵심 코드의 상당수는 유겐 휠러가 지금도 개발 중
• Spring : 전통적인 J2EE(EJB)라는 겨울을 넘어, 새로운 시작이라는 뜻

Release

• 2003 : Spring Framework 1.0 - XML
• 2006 : Spring Framework 2.0 - XML 편의 기능 지원
• 2009 : Spring Framework 3.0 - 자바 코드로 설정
• 2013 : Spring Framework 4.0 - 자바 8
• 2014 : Spring Boot 1.0
• 2017 : Spring Framework 5.0, Spring Boot 2.0 - Reactive Programming 지원
• 2023 현재 : Spring 6.1.x, Spring Boot 3.1.x

3. Spring이란?

Spring 생태계

• Spring Framework : 이 모든 것들 중 핵심
• Spring Boot : 아래의 모든 기술들을 사용하기 편리하도록 도와주는 것
• Spring Data : DBMS에서 CRUD를 편리하게 할 수 있도록 도와주는 기술. 가장 많이 쓰는 건 Spring Data JPA
• Spring Session : 세션 기술을 편리하게 사용하도록 도와줌
• Spring Security : 보안과 관련된 것
• Spring Rest Docs : API 문서화를 편리하게 해주는 것
• Spring Batch : 데이터를 대량으로 처리하기 위해, 단위를 나눠 배치처리를 하는 데에 특화된 기술
• Spring Cloud : 클라우드 기술에 특화된 기술

Spring Framework

• 핵심 기술
  • Spring DI container
  • AOP
  • 이벤트
  • etc
    
    
• 웹 기술
  • Spring MVC
  • Spring WebFlux
    
    
• 데이터 접근 기술
  • 트랜잭션
  • JDBC
  • ORM 지원
  • XML 지원
    
    
• 기술 통합
  • 캐시
  • 이메일
  • 원격 접근
  • 스케줄링
    
    
• 테스트
  • 스프링 기반 테스트 지원
    
    
• 언어
  • Kotlin
  • Groovy
    
    

Spring Boot

: 스프링을 편리하게 사용할 수 있도록 지원

• 최근에는 기본으로 사용
• 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
  • Tomcat 같은 웹 서버를 내장해서, 별도의 웹 서버를 설치하지 않아도 됨
  • 손쉬운 빌드 구성을 위한 starter 종속성 제공
  • 스프링과 3rd parth(외부) 라이브러리 자동 구성
  • 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
• 관례에 의한 간결한 설정

💡 Spring Boot는 Spring과 별개? NO!! Spring Boot는 Spring Framework를 꼭 사용하면서 사용이 편리하게 도와주는 기술임!

Spring이라는 단어

문맥에 따라 다르게 사용된다.

• Spring DI Container 기술
• Spring Framework
• Spring Boot, Spring Framework 등을 모두 포함한 스프링 생태계

💬 한 줄 요약 null을 반환하는 API는 사용하기 어렵고, 오류 처리 코드도 늘어난다. 성능이 더 좋은 것도 아니다.

다음은 컬렉션이 비었다면 null을 반환하는 코드이다.

private final List<Cheese> chessesInStock = ...;

/**
* @return 매장 안의 모든 치즈 목록을 반환한다.
*         단, 재고가 하나도 없다면 null을 반환한다.
*/
public List<Cheese> getCheeses() {
    return cheesesInStock.isEmpty() ? null : new ArrayList<>(cheesesInStock);
}

클라이언트 입장

위와 같은 코드에서 만약 null값을 반환하게 된다면, 클라이언트는 이 null 상황을 처리하는 코드를 추가로 작성해야 한다.

ex)

List<Cheese> cheeses = shop.getCheeses();
if(cheeses != null && cheeses.contains(Cheese.STILTON))
    System. out. printIn("좋았어, 바로 그거야广》;

클라이언트에서 위와 같이 방어하는 코드를 항상 써야 하며, 이걸 빼먹으면 오류가 발생할 수 있따. 실제 객체가 0개일 가능성이 거의 없는 상황에서는 (계속 방치되다가) 수년 뒤에야 오류가 발생하기도 한다.

개발자

Collection null을 반환하려면, 반환하는 쪽에서도 이 상황을 특별히 취급해줘야 해서 코드도 더 복잡해진다. 따라서 빈 컬렉션을 반환하자.

배열 절대 null을 반환하지 말고, 다음과 같이 길이가 0인 배열을 반환하라.

public Cheese[] getCheeses {
    return cheesesInStock.toArray(new Cheese[0]);
}

위의 방식이 성능을 떨어뜨릴 것 같다면, 길이 0짜리 배열을 미리 선언해두고 매번 그 배열을 반환하면 된다. 길이 0인 배열은 모두 불변이기 때문!

public static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0];

public Cheese[] getCheeses {
    return cheesesInStock.toArray(EMPTY_CHEESE_ARRAY);
}

단순히 성능을 개선할 목적이라면 다음과 같이 toArray에 넘기는 배열을 미리 할당하는 건 추천하지 않는다. 오히려 성능이 떨어진다는 연구 결과가 있다.

return cheesesInStock.toArray(new Cheese[cheesesInStock.size()]);

반박 의견 : 빈 컨테이너를 할당하는 데에도 비용이 드니, null 반환이 낫다!

👉🏻 이는 두 가지 면에서 틀린 주장이다.

1. 성능 차이 거의 없음

성능 분석 결과 이 할당이 성능 저하의 주범이라고 확인되지 않는 한, 이 정도의 성능 차이는 신경 쓸 수준이 못 된다.

확실한 해법

단, 작은 가능성으로 사용 패턴에 따라 빈 컬렉션 할당이 성능을 눈에 띄게 떨어뜨릴 수도 있다. 이는 다행히 매번 똑같인 빈 '불변' 컬렉션을 반환하는 것으로 간단히 해결이 가능하다. 알다시피 불변 객체는 자유롭게 공유해도 안전하다.

• Collections.emptySet
• Collections.emptyMap

단, 이 역시 최적화에 해당되니 꼭 필요할 때에만 사용하자. 그리고 최적화가 필요하다고 판단되면, 수정 전과 후의 성능을 측정하여 실제로 성능이 개선되는지 꼭 확인하자.

public List<Cheese> getCheeses() {
    return cheesesInStock.isEmpty() ? Collections.emptyList() : new ArrayList<> (cheesesInStock);
}

2. 빈 컬렉션과 배열은 굳이 새로 할당하지 않고도 반환할 수 있다.

대부분의 상황에서는 아래와 같이 하면 된다.

public List<Cheese> getCheeses() {
    return new ArrayList<>(cheesesInStock)
}

• 메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바람
• 제약사항은 반드시 문서화해야 함
• 메서드 몸체가 시작되기 전에 검사해야 함
• "오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다"는 일반 원칙

📌 제약사항은 반드시 문서화해야 함

• 특히, public, protected 메서드는 매개변수 값이 잘못되었을 때 던지는 예외는 문서화해야 함
• @throws 자바독 태그 사용하여 정리
• 보통은 IllegalArgumentException, IndexOutOfBoundsException, NullPointerException 중 하나
• 매개변수의 제약을 문서화하면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 함

/**
* (현재 값 mod m) 값을 반환한다. 이 메서드는 항상 음이 아닌 Biginteger률 반환하다는 점에서 remainder 메서드와 다르다.
*
* @param m 계수(양수여야 한다.)
* @return 현재 값 mod m
* @throws ArithmeticException mo| 0보다 작거나 같으면 발생한다.
*/
public Biginteger mod(Biginteger m) {
if (m.signum() <= 0)
throw new ArithmeticException ("계수 (m)는 양수여야 합니다. " + m);
... // 계산 수행
}

• 이 메서드는 m이 null이면 m.signum() 호출 때 NullPointerException을 던진다. 그런데 “m이 null일 때 NullPointerException을 던진다”라는 말은 메서드 설명 어디에도 없다.
• 이 설명을 (개별 메서드가 아닌) Biginteger 클래스 수준에서 기술했기 때문

클래스 수준 주석이 필요한 이유

• 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 훨씬 깔끔한 방법

📌 메서드 몸체가 시작되기 전에 검사해야 함

• 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있음

이게 안 될 경우

• 메서드 수행 중간에 모호한 예외를 던지며 실패할 수 있음.

• 더 최악은, 메서드는 문제 없이 수행되었지만 어떤 객체를 이상한 상태로 만들어두어서, 미래의 알 수 없는 시점에 관련 없는 오류를 발생시킬 수 있음.

• 즉, 매개변수 검사에 실패하면 failure atomicity(실패 원자성)을 어기는 결과를 낳을 수 있음!

• 예외는 있다. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산과정에서 암묵적으로 검사가 수행될 때 등이 있음

  • ex) Collections.sort(List) - 리스트 안의 객체들은 모두 상호 비교할 수 있어야 하며, 정렬 과정에서 이 비교가 이루어짐
  • 만약 상호 비교될 수 없는 타입의 객체가 들어있다면, 그 객체와 비교할 때 ClassCastException을 던짐 => 이럴 경우, 비교하기에 앞서 리스트 안의 모든 객체가 상호 비교될 수 있는지 검사해보는 것보다는 버리는 게 나음

    하지만, 암묵적 유효성 검사에 너무 의존했다가는 실패 원자성을 해칠 수 있으니 주의!

📌 오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다

• 오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워지기 때문

기본적인 유효성 검사들

Null 검사

• @Nullable이나 이와 비슷한 애너테이션을 사용해 특정 매개변수는 null이 될 수 있다고 알려줄 수도 있지만，표준적인 방법은 아니다. 그리고 같은 목적으로 사용할 수 있는 애너테이션도 여러 가지다

• 자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니，더 이상 null 검사를 수동으로 하지 않아도 된다. 원하는 예외 메시지도 지정할 수 있다. 또한 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다.

  this.strategy = Objects.requireNonNull(strategy, "전략");

  • 반환값은 그냥 무시하고 필요한 곳 어디서든 순수한 null 검사 목적으로 사용 해도 됨

범위 검사

Objects의 checkFromlndexSize, checkFromToIndex, checkindex라는 메서드들을 사용하면 됨 (null 검사 메서드만큼 유연하지는 않음)

한계들

• 예외 메시지를 지정할 수 없고，리스트와 배열 전용으로 설계됐다.
• 닫힌 범위 (closed range； 양 끝단 값을 포함하는)는 다루지 못한다.

그래도 이런 제약이 걸림돌이 되지 않는 상황에서는 아주 유용하고 편하다

assert을 사용한 유효성 검사

• public이 아닌 메서드라면 단언문(assert)을 사용해 매개변수 유효성을 검증할 수 있다.

private static void sort(long a[], int offset, int length) {
  assert a != null;
  assert offset >= 0 && offset <= a.length;
  assert length >= 0 && length <= a.length - offset;
... // 계산 수행
}

• 여기서의 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언한다는 것
• 이 메서드가 포함된 패키지를 클라이언트가 어떤 식으로 지지고 볶든 상관없다.

유의사항 단언문은 몇 가지 면에서 일반적인 유효성 검사와 다르다.

1. 실패하면 AssertionError를 던진다.
2. 두 번째, 런타임에 아무런 효과도, 아무런 성능 저하도 없다(단，java를 실행할 때 명령줄에서 -ea 혹은 --enableassertions 플래그 설정하면 런타임에 영향을 준다).💬

📌 “나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라”

• 이들은 특히 더 신경써서 검사해야 함
• 메서드가 유효하지 않은 값을 돌려주고, 나중에 그 인스턴스를 사용하려면 비로소 NullPointerException이 발생함
• 이 때가 되면 이 List를 어디서 가져왔는지 추적하기 어려워 디버깅이 상당히 괴로워질 수 있다.

생성자의 유효성 검사

생성자는 “나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라”는 원칙의 특수한 사례

• 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요함

📌 계산 중 잘못된 매개변수 값을 사용해 발생한 예외와 API 문서에서 던지기로 한 예외가 다를 수 있음

• 이럴 경우, 예외 번역(exception translate) 관용구를 사용하여 API 문서에 기재된 예외로 번역해줘야 함

📌 매개변수에 제약을 두는 게 좋다?

-> NO!

• 메서드는 최대한 범용적으로 설계해야 함

• 메서드가 건네받은 값으로 무언가 제대로 된 일을 할 수 있다면, 매개변수 제약은 적을수록 좋다.

• 단, 구현하려는 개념 자체가 특정한 제약을 내재한 경우도 드물지 않다!