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

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

선택 매개변수가 많을 때 취할 수 있는 대안을 알아보자.

 

선택 매개변수가 많을 때 활용할 수 있는 대안

1. 점층적 생성자 패턴(Telescoping Constructor Pattern)

먼저 점층적 생성자 패턴이 있다.

이 패턴은 필수 매개변수만 생성자부터, 필수 매개변수와 선택 매개변수 1개를 받는 생성자, 선택 매개변수 2개까지 받는 생성자, ... 형태로 선택 매개변수를 전부 받는 생성자까지 늘려가는 방식이다.

점층적 생성자 패턴은 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기가 어렵다는 문제가 있다.
코드를 읽을 때, 각 값의 의미가 헷갈리고, 매개변수가 몇 개인지도 주의해서 세어 보아야 한다.
또한, 타입이 같은 매개변수가 연달아 있는 경우, 매개변수의 순서를 바꿔도 컴파일러가 알 수 없다!

 

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

두 번째 대안은 자바빈즈 패턴이다.

이 패턴은 매개변수가 없는 생성자로 객체를 만든 후, setter 메서드들을 호출해 원하는 매개변수의 값을 설정하는 방식이다.

자바빈즈 패턴은 코드가 길어지기는 하지만 인스턴스를 만들기 쉽고, 읽기 쉬운 코드를 작성할 수 있다.

그러나 객체 하나를 만들기 위해 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성이 무너진 상태에 놓이게 되는 치명적인 단점이 있다.
일관성이 무너지는 문제 때문에 클래스를 불변으로 만들 수 없으며 스레드 안정성을 얻으려면 프로그래머가 추가 작업을 해줘야만 한다.

 

3. 빌더 패턴(Builder Pattern)

빌더 패턴은 위의 문제점들을 모두 해결할 수 있다.
점층적 생성자 패턴의 안정성과 자바빈즈 패턴의 가독성을 모두 가지고 있다.

빌더 패턴을 설명하기 위해 여기까지 왔다. 이제 빌더 패턴에 대하여 알아보자.

 

빌더 패턴

빌더 패턴 방식은 다음의 절차를 따른다.

1. 필수 매개변수만으로 생성자 혹은 정적 팩터리 메서드를 호출해 빌더 객체를 얻는다.
2. 빌더 객체가 제공하는 일종의 setter 메서드들로 원하는 선택 매개변수들을 설정한다.
3. 매개변수가 없는 build 메서드를 호출해 우리에게 필요한 객체를 얻는다.

 

예제를 통해 빌더 패턴 구현 방법을 알아보자.
식품 포장의 영양정보를 표현하는 클래스에 대한 예제이다.

public class NutritionFacts {
	
    private int servingSize;
    private int servings;
    private int calories;
    private int fat;
    private int sodium;
    private 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)라고 한다.

이렇게 정의한 클래스는 클라이언트에서 다음과 같이 사용할 수 있다.

NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
				.calories(100)
                		.sodium(35)
                		.carbohydrate(27)
                		.build();

이 클라이언트 코드는 쓰기 쉽고, 읽기 매우 쉽다.
빌더 패턴은 (파이썬과 스칼라에 있는) 명명된 선택적 매개변수(named optional parameters)를 흉내낸 것이다.

 

빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰기에 좋다.

다음 예제를 통해 계층적 빌더를 알아보자.

public abstract class Pizza {
	
    public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
    final Set<Topping> toppings;
    
    abstract static class Builder<T extends Builder<T>> {
        EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);
        public T addTopping(Topping topping) {
            toppings.add(Objects.requireNonNull(topping));
            return self();
        }
        
        abstract Pizza build();
        
        // 하위 클래스는 이 메서드를 재정의하여
        // "this"를 반환하도록 해야 한다.
        protected abstract T self();
    }
    
    Pizza(Builder<?> builder) {
        toppings = builder.toppings.clone();
    }
}

public class NyPizza extends Pizza {
    public enum Size { SMALL, MEDIUM, LARGE }
    private final Size size;
    
    public static class Builder extends Pizza.Builder<Builder> {
        private final Size size;
        
        public Builder(Size size) {
            this.size = Objects.requireNonNull(size);
        }
        
        @Override public NyPizza build() {
            return new NyPizza(this);
        }
        
        @Override protected Builder self() { return this; }
    }
    
    private NyPizza (Builder builder) {
        super(builder);
        size = builder.size;
    }
}

public class Calzone extends Pizza {
    private final boolean sauceInside;
    
    public static class Builder extends Pizza.Builder<Builder> {
    	private boolean sauceInside = false; // 기본값
        
        public Builder sauceInside() {
            sauceInside = true;
            return this;
        }
        
        @Override public Calzone build() {
            return new Calzone(this);
        }
        
        @Override protected Builder self() { return this; }
    }
    
    private Calzone (Builder builder) {
        super(builder);
        sauceInside = builder.sauceInside;
    }
}

각 하위 클래스의 빌더가 정의한 build 메서드는 해당하는 구체 하위 클래스를 반환하도록 선언한다.
이렇듯 하위 클래스의 메서드가 상위 클래스의 메서드가 정의한 반환 타입이 아닌, 그 하위 타입을 반환하는 기능을 공변 반환 타이핑(covariant return typing)이라고 한다. 이 기능을 이용하면 클라이언트가 형변환에 신경쓰지 않고도 빌더를 사용할 수 있다.

위의 계층적 빌더를 사용하는 클라이언트 코드 예시는 다음과 같다.

NyPizza pizza = new NyPizza.Builder(SMALL)
			.addTopping(SAUSAGE)
			.addTopping(ONION)
			.build();

Calzone calzone = new Calzone.Builder()
			.addTopping(HAM)
    			.sauceInside()
    			.build();

 

빌더 패턴은 상당히 유연하다는 장점이 있지만, 객체를 만들기 위해 먼저 빌더부터 만들어야 한다. 
빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수 있다.

또한 점층적 생성자 패턴보다는 코드가 장황해서 매개변수가 4개 이상은 되어야 값어치를 한다. (그렇지만 API는 시간이 지날수록 매개변수가 많아지는 경향이 있음을 명심하자..)

 

 

핵심 정리

생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는 게 더 낫다.
매개변수 중 다수가 필수가 아니거나 같은 타입이면 특히 더 그렇다.
빌더는 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈보다 훨씬 안전하다.