Item2: 생성자에 매개변수가 많다면 빌더를 고려하라

정적 팩터리와 생성자는 선택적 매개변수가 많을 경우 적절히 대응하기 어려운 제약을 가진다. 즉, 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기가 어렵다. 이러한 경우에 활용할 수 있는 자바빈즈 패턴(JavaBeans pattern)과 더 나아가 해당 패턴의 단점을 개선한 빌더 패턴(Builder pattern)에 대해 알아본다.
Tags:
핵심 정리

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

No Good : Telescoping constructor pattern

public class NutritionFacts {
    // 멤버 변수 정의 생략...

    public NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories) {
        this(servingSize, servings, calories, 0);
    }

    // 위와 같은 흐름으로 끊임없이 생성자 정의
}
  • 사용자에게 설정하길 원치 않는 매개 변수까지 강제로 값을 지정해야 함.
  • 매개 변수 조합에 따라 생성자 수가 많이 늘어 날 수 있음
  • 매개 변수가 늘어남에 따라 코드 작성 및 가독성이 저하 됨.
  • 타입만 맞으면 컴파일 에러가 발생하지 않기 때문에 같은 타입의 매개변수를 잘못된 순서로 지정할 경우 실수를 눈치 챌 수 없음.
    • 올바른 매개 변수를 입력하고 있는지 계속 체크해야 하는 불편함.

대안1 : JavaBean Pattern

매개 변수가 없는 생성자로 객체를 생성 후, setter 메서드를 호출해 원하는 매개변수의 값을 설정하는 방식!!

No Good : JavaBeans Pattern


public class NutritionFacts {
    // 멤버 변수 정의 생략

    public NutritionFats() {}

    public void setServingSize(int val) { // 생략 }
    public void setServings(int val) { // 생략 }
    public void setCalories(int val) { // 생략 }
    // 멤버 변수의 setter 함수 정의 계속...
}

JavaBeans Pattern 단점

  • 객체 하나를 만들려면 메서드를 여러 개 호출해야 함.
  • 객체 생성 후, 매개 변수 간 불 일치가 발생할 수 있음. → 객체 생성하기 전에 불일치를 감지해야 함.
  • 객체가 완전히 생성되기 전까지 일관성(consistency)이 무너진 상태에 놓이게 됨.
    • setter에서 내부 상태를 변경 할 수 있음. 또한 클래스를 불변(immutable)으로 만들 수 없음. → 스레드 안전성을 얻기 위해 추가 작업 필요.
    • 생성이 끝난 객체를 직접 ‘freezing’ 작업 후 사용하는 방법이 있으나 실무에서는 거의 쓰이지 않음. 또한, freezing 메서드 호출해줬는지 컴파일러가 보증 할 수 없음. → 런타임 오류에 취약

대안2: Builder Pattern

점층적 생성자 패턴의 안정성과 자바빈즈 패턴의 가독성을 겸비한 패턴으로 클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수만으로 생성자(혹은 정적 팩터리)를 호출해 빌더 객체를 얻어 빌더 객체가 제공하는 세터 메서드들로 원하는 선택 매개변수들을 설정하는 패턴

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;

        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

        public Builder calories(int val) { 
            this.calories = val; return this;
        }
        public Builder fat(int val) { 
            this.fat= val; return this;
        }
        public Builder sodium(int val) { 
            this.sodium= val; return this;
        }
        public Builder carbohydrate(int val) { 
            this.carbohydrate = val; return this;
        }
        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

    private NutritionFacts(Builder builder) {
        this.servingSize  = builder.servingSize;
        this.servings     = builder.servings;
        this.calories     = builder.calories;
        this.fat          = builder.fat;
        this.sodium       = builder.sodium;
        this.carbohydrate = builder.carbohydrate;
    } 
}

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

장점

  • 구현하기 쉬움
  • 읽기 쉬움
  • builder()로 객체 생성하기 전에 매개변수 간 불일치 감지 가능
  • 클래스가 계증 구조로 되어 있어도 적용 가능
  • API가 유연해짐. 예를 들어 하나의 builder 하나로 여러 객체를 순회하면서 만들수 있고, 빌더에 넘기는 매개 변수에 따라 다른 객체를 만들 수도 있음.

단점

  • 객체를 만들려면 빌더부터 만들어야 함. → 빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수 있음.
  • 점층적 생성자 패턴보다는 코드가 길기 때문에 매개변수가 4개 이상은 되어야 값어치를 한다.
  • but!! API는 시간이 지날수록 매개변수가 많아지는 경향이 있기 때문에 애초에 빌도로 시작하는 편이 나음.