> For the complete documentation index, see [llms.txt](https://develop-footprint.gitbook.io/o/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://develop-footprint.gitbook.io/o/java/effective-java/2/item2.md).

# item2) 생성자에 매개변수가 많다면 빌더를 고려하라

생성자에 매개변수가 많을 때에는 빌더 패턴을 사용하자!

## 점층적 생성자 패턴

* 필수 매개변수만 받는 생성자부터 선택 매개변수를 1\~n개 받는 생성자들을 모두 선언해 사용하는 방식
* 매개변수의 개수가 많아지면 점층적 생성자 패턴으로도 클라이언트 코드를 작성하거나 읽기 어렵다.
* 클라이언트가 실수로 매개변수의 순서를 바꾸어 건네주는 경우 런타임에 엉뚱한 동작을 하게 된다.

## 자바빈즈 패턴

* 매개변수가 없는 생성자로 객체를 만든 후(클래스 변수들은 내부에서 기본값으로 초기화), setter 메서드 호출해 원하는 매개변수의 값을 설정하는 방식
* 객체가 완전히 생성되기 전까지는 일관성이 무너지고, 클래스를 불변으로 만들 수 없다.

## 빌더 패턴

* 클래스 내부에 정적 멤버 클래스로 빌더를 만들어둔다.
* 필요한 객체를 클라이언트가 직접 만드는 대신 필수 매개변수만으로 생성자를 호출해 빌더 객체 얻는다
* 이후 빌더 객체가 제공하는 setter 메서드로 원하는 선택 매개변수만 설정한다.
* 매개변수가 없는 build() 메서드 호출해 필요한 최종 객체를 얻는다.
* 잘못된 매개변수를 검사하려면 다음 두 방식을 사용할 수 있다.
  * 1\) 빌더의 생성자와 메서드에서 입력 매개변수 검사
  * 2\) build 메서드가 호출하는 생성자에서 여러 매개변수가 걸친 불변식을 검사
* 계층적으로 설계된 클래스와 함께 쓰기 좋다 (추상 클래스와 하위 클래스가 각각 빌더를 갖도록 하여 사용)
* 가변인수 매개변수를 여러 개 사용할 수 있다.
* 객체를 만들기 위해 빌더 객체부터 만들어야 하므로 성능 상 문제 발생할 수도 있다.
* 매개변수가 점점 많아질 경우 좋다. (일반적으로 매개변수가 점점 많아지므로 처음부터 빌더 패턴 고려할 것)