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

[배경]

• 정적 팩터리와 생성자에는 똑같은 제약이 하나 있다.
• 선택적 매개변수가 많을 때 적절히 대응하기 어렵다는 점이다.

 

[해결방법]

1. 점층적 생성자 패턴(telescoping constructor pattern)

• 필수 매개변수만 받는 생성자, 필수 매개변수와 선택 매개변수 1개를 받는 생성자, 선택 매개변수를 2개까지 받는 생성자, ... 형태로 선택 매개변수를 전부 다 받는 생성자까지 늘려가는 방식이다.
• 단점
  • 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다.
  • 클라이언트가 실수로 매개변수의 순서를 바꿔 건네줘도 컴파일러는 알아채지 못하고, 결국 런타임에 엉뚱한 동작을 하게 된다아이템51.

2. 자바빈즈 패턴(JavaBeans pattern)

• 매개변수가 없는 생성자로 객체를 만든 후, 세터(setter) 메서드들을 호출해 원하는 매개변수의 값을 설정하는 방식이다.
• 단점
  • 객체 하나를 만들려면 메서드를 여러 개 호출해야 한다.
  • 객체가 완전히 생성되기 전까지는 일관성(consistency)이 무너진 상태에 놓이게 된다.
    • 일관성이 깨진 객체가 만들어지면, 버그를 심은 코드와 그 버그 때문에 런타임에 문제를 겪는 코드가 물리적으로 멀리 떨어져 있을 것이므로 디버깅도 만만치 않다.
    • 이 문제 때문에 자바빈즈 패턴에서는 클래스를 불변아이템17으로 만들 수 없으며 스레드 안정성을 얻으려면 프로그래머가 추가 작업을 해줘야만 한다.
    • 이러한 단점을 완화하고자 생성이 끝난 객체를 수동으로 '얼리고(freezing)', 얼리기 전에는 사용할 수 없도록 하기도 한다. 하지만 이 방법은 다루기 어렵기도 하고, 컴파일러가 freeze 메서드 호출 여부를 보증할 방법이 없어서 런타임 오류에 취약하다.

3. 빌더 패턴(Builder pattern)

• 클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수만으로 생성자(혹은 정적 팩터리)를 호출해 빌더 객체를 얻는다.
• 그런 다음 빌더 객체가 제공하는 일종의 세터 메서드들로 원하는 선택 매개변수들을 설정한다.
• 마지막으로 매개변수가 없는 build 메서드를 호출해 드디어 우리에게 필요한(보통은 불변인) 객체를 얻는다.

public class NutritionFacts {
    private final int servingSize;
    private final int servings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;
    
    public static class Builder {
    	// 필수 매개변수
        private final int servingSize;
        private final int servings;
        
        // 선택 매개변수 - 기본값으로 초기화한다.
        private int calories		= 0;
        private int fat	         	= 0;
        private int sodium      	= 0;
        private int carbohydrate	= 0;
        
        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings    = servings;
        }
        
        public Builder calories(int val)
        	{ calories = val;       return this; }
        public Builder fat(int val)
        	{ fat = val;            return this; }
        public Builder sodium(int val)
        	{ sodium = val;	        return this; }
        public Builder carbohydrate(int val)
        	{ carbohydrate = val;	return this; }
            
        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }
    
    private NutritionFacts(Builder builder) {
    	servingSize     = builder.servingSize;
        servings        = builder.servings;
        calories        = builder.calories;
        fat             = builder.fat;
        sodium          = builder.sodium;
        carbohydrate    = builder.carbohydrate;
    }
}

• 빌더의 세터 메서드들은 빌더 자신을 반환하기 때문에 연쇄적으로 호출할 수 있다. 이런 방식을 호출이 흐르듯 연결된다는 뜻으로 플루언트 API(fluent API) 혹은 메서드 연쇄(method chaining)라 한다.
• 빌더 패턴은 (파이썬과 스칼라에 있는) 명명된 선택적 매개변수(named optional parameters)를 흉내 낸 것이다.
• 잘못된 매개변수를 최대한 일찍 발견하려면 빌더의 생성자와 메서드에서 입력 매개변수를 검사하고, build 메서드가 호출하는 생성자에서 여러 매개변수에 걸친 불변식(invariant)을 검사하자.
• 공격에 대비해 이런 불변식을 보장하려면 빌더로부터 매개변수를 복사한 후 해당 객체 필드들도 검사해야 한다아이템50.
• 검사해서 잘못된 점을 발견하면 어떤 매개변수가 잘못되었는지를 자세히 알려주는 메시지를 담아 IllegalArgumentException을 던지면 된다아이템75.
• 장점
  • 쓰기 쉽고, 읽기 쉽다. 
  • 계층적으로 설계된 클래스와 함께 쓰기에 좋다.
  • 가변인수(varags) 매개변수를 여러 개 사용할 수 있다. 각각을 적절한 메서드로 나눠 선언하면 된다.
  • 메서드를 여러 번 호출하도록 하고 각 호출 때 넘겨진 매개변수들을 하나의 필드로 모을 수도 있다.
  • 상당히 유연하다. 빌더 하나로 여러 객체를 순회하면서 만들 수 있고, 빌더에 넘기는 매개변수에 따라 다른 객체를 만들 수도 있다. 객체마다 부여되는 일련번호와 같은 특정 필드는 빌더가 알아서 채우도록 할 수도 있다.
• 단점
  • 객체를 만들려면, 그에 앞서 빌더부터 만들어야 한다.
  • 점층적 생성자 패턴보다는 코드가 장황해서 매개변수가 4개 이상은 되어야 값어치를 한다. 하지만 API는 시간이 지날수록 매개변수가 많아지는 경향이 있음을 명심하자.