아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라.

핵심 정리

정적 팩터리와 생성자에 선택적 매개변수가 많을 때 고려할 수 있는 방안 (필수적 필드는 생성자 주입이 좋다.)
- 대안1: 점층적 생성자 패턴 또는 생성자 체이닝
  - 매개변수가 늘어나면 클라이언트 코드를 작성하거나 읽기 어렵다.
대안2: 자바빈즈 패턴
- 완전한 객체를 만들려면 메서드를 여러번 호출해야 한다. (일관성이 무너진 상태가 될 수도 있다.)
- 어디까지 세팅을 해야 사용 가능한 상태인지 알기가 힘들다.
- 클래스를 불변으로 만들 수 없다.
권장하는 방법: 빌더 패턴
- 플루언트 API 또는 메소드 체이닝을 한다.
- 계층적으로 설계된 클래스와 함께 사용하기 좋다.
  - 하위 계층에서 기존의 빌더를 사용하게 되면(Builder가 반환 타입) 타입 캐스팅도 해야하고,
    하위 계층의 메소드 체이닝도 사용하지 못하기 때문에 abstract T self() - 본인 타입을 반환 메소드를 사용해 해결할 수 있다.
- 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈 보다 훨씬 안전하다.
- 롬복 @Builder를 사용하더라도 생성자는 생긴다. 다른 곳에서 사용이 헤깔릴 수도 있다.
  - @AllArgsConstructor(access = AccessLevel.PRIVATE) 로 처리하면 밖에서는 Builder를 통해서만 생성 가능하게 된다.

(주로 GUI에서) 재사용 가능한 소프트웨어 컴포넌트
java.beans 패키지 안에 있는 모든 것
그 중에서도 자바빈이 지켜야 할 규약
- 아규먼트 없는 기본 생성자
- getter와 setter 메소드 이름 규약
- Serializable 인터페이스 구현
하지만 실제로 오늘날 자바빈 스펙 중에서도 getter와 setter가 주로 쓰이는 이유는?
- JPA나 스프링과 같은 여러 프레임워크에서 리플렉션을 통해 특정 객체의 값을 조회하거나 설정하기 때문이다.

임의의 객체를 불변 객체로 만들어주는 기능.
Object.freeze()에 전달한 객체는 그 뒤로 변경될 수 없다,
- 새 프로퍼티를 추가하지 못함.
- 기존 프로퍼티를 제거하지 못함.
- 기존 프로퍼티 값을 변경하지 못함.
- 프로토타입을 변경하지 못함.
strict 모드에서만 동작함
비슷한 류의 펑션으로 Object.seal()과 Object.preventExtensions() 존재
가변 객체인데 어느 시점부터 freeze하여 불변 객체로 만드는 방식을 사용하는 것은 코딩하기 너무 어려운 조건이다.

잘못된 인자를 넘겨 받았을 때 사용할 수 있는 기본 런타임 예외
- 잘못된 인자를 출력해주는 것이 도움이 된다. (왜 에러가 났는지 명시적으로 알 수 있기 때문이다.)
질문1) checked exception과 unchecked exception의 차이?
- checked exceptions : (컴파일타임) 다시 checked exceptions를 던지거나, 예외를 처리하며, 복구가 가능한 상황에 던진다.
- unchecked exceptions : (런타임) 던지거나 예외처리를 하지 않아도 되며, 예외를 던졌을 때 뭔가를 하지 못하는 상황.
질문2) 간혹 메소드 선언부에 unchecked exception을 선언하는 이유는?
- 일어날 수 있는 unchecked exception(RuntimeException 류)을 다 명시하다보면 코드가 너무 많아지고 가독성이 떨어지기 때문에 잘 사용하지 않지만, 명시적으로 메소드의 사용 방법을 알려주기 위해 사용한다.
질문3) checked exception은 왜 사용할까?
- 강제성이 높으나, 에러가 발생했을 때 클라이언트 코드가 후속 작업을 통해 복구를 원하는 경우에 사용한다.
과제1) 자바의 모든 RuntimeException 클래스 이름 한번씩 읽어보기.
과제2) 읽어보기