[Effective Java] Item 2. 생성자에 매개변수가 많다면 Builder를 고려하자.

정적 팩토리 메소드, 줄여서 정팩메와 생성자은 모두 한 가지 제약이 있습니다.

> 바로 선택적 매개변수가 많을때 적절히 대응하기 어렵다는 점인데요.

 

이 제약에 대한 대안들이 어떤 것들이 있는지 먼저 하나씩 알아보겠습니다.

---

점층적 생성자 패턴(Telescoping Constructor 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 NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

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


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

    public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium, int carbohydrate) {
        this.servingSize = servingSize;
        this.servings = servings;
        this.calories = calories;
        this.fat = fat;
        this.sodium = sodium;
        this.carbohydrate = carbohydrate;
    }
}

 

• 영양정보를 담는 클래스 NutritionFacts입니다.
• 이 클래스는 프로퍼티로 servingSize, servings, ... carbohydrate를 가집니다.

하지만 여기서 servingSize와 servings 프로퍼티는 필수로 값을 가져야 하고, 나머지 프로퍼티는 값을 꼭 가져야 하는 것이 아닌 선택적 프로퍼티라고 가정해보겠습니다.

 

이런 경우, 초기 개발자들은 위 코드와 같이 생성자를 구성하여 매개변수 2개를 받는 생성자에서 3개를 받는 생성자를 호출하고 3개를 받는 생성자는 4개를 받는 생성자를 호출하고 4개는 5개를 받는 생성자를 호출하여 결국 n-1개를 받는 생성자가 n개의 매개변수를 받는 생성자를 호출하는 점층적 생성자 패턴을 사용하곤 했다고 합니다. 생성자 코드만 작성했을 뿐인데 벌써 무거워진 느낌이네요.

NutritionFacts nutritionFacts = new NutritionFacts(10, 100, 0);

이 클래스의 인스턴스를 만들기 위해 원하는 이렇게 매개변수를 포함한 생성자 중 가장 짧은 것을 고르면 되는데요. 

 

보통 이런 생성자는 사용자가 설정하길 원하지 않는 매개변수까지 포함하기 쉬운데, 그런 매개변수에도 값을 지정해야 한다는 단점이 있습니다. 위 코드로 말하자면 fat 매개변수에 굳이 0의 값을 설정해준 것처럼 말이죠.

정리하자면 이런 점층적 생성자 패턴도 사용할 수는 있겠지만, 매개변수가 많아지면 클라이언트 코드를 작성하기도 읽기도 어렵다는 단점이 있습니다.

코드를 읽을 때 각 값의 의미를 파악해야 하고, 매개변수가 몇 개인지도 주의해서 세어보아야하는 번거로움도 있고, 타입이 같은 매개변수가 연달아 있으면 찾기 어려운 버그가 생겨날 수도 있겠구요.

 

이번에는 다른 대안인 자바빈즈 패턴을 알아보겠습니다.

 

---

자바빈즈 패턴(JavaBeans Pattern)

자바빈즈 패턴을 적용한 코드 먼저 보겠습니다.

package dw.chapter1.item2;

// 영양 정보 클래스
public class NutritionFacts {

    private  int servingSize = -1; //  필수
    private int servings = -1; // 필수
    private int calories = 0; // 선택
    private int fat = 0;// 선택
    private int sodium = 0;// 선택
    private int carbohydrate = 0; // 선택

    public NutritionFacts() {}

    public void setServingSize(int servingSize) {
        this.servingSize = servingSize;
    }

    public void setServings(int servings) {
        this.servings = servings;
    }

    public void setCalories(int calories) {
        this.calories = calories;
    }

    public void setFat(int fat) {
        this.fat = fat;
    }

    public void setSodium(int sodium) {
        this.sodium = sodium;
    }

    public void setCarbohydrate(int carbohydrate) {
        this.carbohydrate = carbohydrate;
    }
}

• 각 프로퍼티에 final 키워드를 붙이지 않고, 초기 값을 세팅하고 setter를 작성한 패턴
• 가독성이 점층적 생성자 패턴에 대비해서는 읽기에는 너무 쉽다는 점이 장점이 되겠습니다.
• 점층적 생성자 패턴의 단점(너무 많은 생성자, 생성자 arugment에 불필요한 값 세팅, 낮은 가독성)은 사라졌다고 볼 수 있지만, 프로퍼티 세팅을 setter로 하나하나 작성해주어야 한다는 점과 아무래도 setter를 열어두어 일관성이 무너졌다는 점으로 보아 좋은 패턴으로 볼 수는 없을 것 같습니다.

하지만 생성이 끝난 객체를 수동으로 얼리고 얼리기 전에는 사용할 수 없도록 설정하여 이런 단점들을 완화할 수 있다고 합니다.

 

하지만 근본적으로 이 방법은 다루기 어려워 실무에서는 거의 사용되지는 않고, 객체를 얼리기 위해 사용한 freeze 메소드에 대해 컴파일러가 보증할 방법이 없어 런타임 오류에 취약하는 단점으로 그저 생성자를 이런 방법도 있구나 정도만 알아두어도 좋을 것 같습니다.

 

마지막 대안으로 가보겠습니다.

 

---

Builder 패턴 

이 Theme에서 말하고자 하는 빌더 패턴이 마지막 대안이 되겠습니다. 

 

빌더 패턴은 점층적 생성자 패턴과 자바빈즈 패턴의 장점(점층적 생성자 패턴의 안전성, 자바빈즈 패턴의 가독성)을 모두 겸비했다고 하는데요. 먼저 코드를 보겠습니다.

package dw.chapter1.item2;

// 영양 정보 클래스
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;

        // 선택 매개변수 - default 값으로 초기화
        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;
    }
}

 

• NutritionFacts는 프로퍼티에 모두 final 키워드를 붙여 불변 클래스임을 보증해주면서, 모든 매개변수의 기본값들을 한 곳에 모아 두었습니다.

Builder의 세터 메소드들도 결국 자신을 리턴하기 때문에 이 메소드들은 연쇄적으로 호출할 수 있습니다! 

 

그래서 결국 빌더를 적용하면 이렇게 인스턴스를 만들 수 있겠습니다.

NutritionFacts nutritionFacts = new NutritionFacts.Builder(10, 100) // 3. 빌더 패턴
        .calories(10)
        .fat(100)
        .sodium(30)
        .carbohydrate(20)
        .build();

• 개인적으로 Lombok의 사기성을 알 수 있는 부분이었습니다.
• 그냥 @Builder 어노테이션만 붙이면 이런 패턴을 자동으로 적용할 수 있었는데, 어노테이션 내부에서 이런식으로 코드를 구성하고 있었네요. 이 또한 처음 알았습니다. 

이렇게 각 세터가 자신의 인스턴스를 리턴하는 덕분에 메소드를 연쇄적으로 호출할 수 있었는데 이런 방식을 메소드 체이닝, 플루언트 API라고 한다고 합니다!

 

무엇보다 이 코드는 클라이언트도 읽고 쓰기 쉽다는 큰 장점이 있습니다만,

 

각 프로퍼티의 유효성을 검증할 수 없다는 단점이 있는데 이 단점은 그냥 build() 메소드에서 각 프로퍼티의 유효성을 검증하고 통과하지 못한다면 메시지를 담아 Un-Checked 예외를 던져줌으로써 클라이언트에게 예외를 알려주어 충분히 보완할 수 있겠습니다.

 

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

---

빌더 패턴을 계층적으로 설계된 클래스에 적용해보기

지금부터는 조금 어려운 내용일 수 있는데, 최대한 쉽게 풀어가보겠습니다.

 

추상 클래스는 추상 빌더를, 구체 클래스는 구체 빌더를 갖게 클래스를 설계한 코드를 먼저 보겠습니다.

 

추상 클래스에는 추상 빌더를

package dw.chapter1.item2;

import java.util.EnumSet;
import java.util.Objects;
import java.util.Set;

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();
        }

        // 하위 클래스에서 이 메소드를 오버라이딩하여 this를 리턴하도록 해야함.
        protected abstract T self();

        abstract Pizza build();
    }

    Pizza(Builder<?> builder) {
        toppings = builder.toppings.clone();
    }
}

• Pizza 는 피자를 나타내는 추상 클래스로 피자 토핑을 열거하는 열거형(enum) 타입 Topping이 있고 클래스에는 최종적인 토핑 집합인 EnumSet<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();
    }

    // 하위 클래스에서 이 메소드를 오버라이딩하여 this를 리턴하도록 해야함.
    protected abstract T self();
    
    abstract Pizza build();
}

• 타입 매개변수 T
  • Builder 클래스는 제네릭 타입 T를 사용합니다. 이는 빌더 클래스를 상속하는 하위 클래스의 유연성을 제공합니다.

EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);

• toppings 필드
  • EnumSet을 사용하여 Topping 열거형의 토핑을 저장하는 필드입니다.
  • EnumSet.noneOf(Topping.class)을 통해 초기화되어 빈 상태로 시작합니다.

public T addTopping(Topping topping) {
    toppings.add(Objects.requireNonNull(topping));
    return self();
}

• addTopping 메소드
  • 토핑을 추가하는 메소드입니다.
  • Objects.requireNonNull을 사용하여 null 값이 전달되지 않도록 확인합니다.
  • 메소드는 빌더 객체 자체를 반환하므로 메소드 체이닝을 통해 여러 토핑을 추가할 수 있습니다.

protected abstract T self();

• 여기에 추상 메소드인 self를 더해 하위 클래스에서는 형변환을 하지 않고도 메소드 연쇄를 지원할 수 있음
  • 파이썬과 달리 self 타입이 없는 자바를 위한 우회방법을 시뮬레이트한 셀프 타입이라고 한다고 합니다;
  • 메소드 연쇄를 위해 하위 클래스에서는 이 메소드를 오버라이딩하여 this를 리턴하도록 구현하면 되겠습니다.

abstract Pizza build();

• 실제로 Pizza 객체를 생성하고 반환하는 메소드로 추상 메소드로, 하위 클래스에서는 반드시 하위 클래스의 인스턴스를 반환하도록 구현이 되어야겠습니다.

 구체 클래스를 보면 좀 더 이해가 쉬울수도 있겠습니다. 이 추상클래스 Pizza를 상속받은 구체 클래스를 봅시다.

 

구체 클래스에서는 추상 빌더를 상속받아 구체 빌더 구현

package dw.chapter1.item2;

import java.util.Objects;

public class NewYorkPizza 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
        protected Builder self() {
            return this;
        }

        @Override
        public NewYorkPizza build() {
            return new NewYorkPizza(this);
        }
    }

    private NewYorkPizza(Builder builder) {
        super(builder);
        size = builder.size;
    }
}

• 각 하위 클래스의 빌더가 정의한 build 메소드는 반드시 구체 하위 클래스를 반환하도록 선언하기
  • > NewYorkPizza.Builder는 NewYork 피자를 반환
  • > XXXPizza.Builder는 XXXPizza를 반환 
• self() 메소드는 자기 자신을 리턴하도록 하기 
• 하위 클래스의 메소드가 상위 클래스의 메소드가 정의한 반환 타입이 아닌(위의 예시로는 Pizza를 리턴하는 것이 아닌), 그 하위 타입을 반환하는 기능을 공변 반환 타이핑이라고 한다고 합니다. 이 기능을 이용하면 클라이언트는 형변환을 신경쓰지 않고 빌더를 편하게 사용할 수 있겠습니다.

+ NewYorkPizza와 같은 맥락의 구체 클래스를 만든 예시(SeoulPizza)입니다.

public class SeoulPizza 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
        protected Builder self() {
            return this;
        }

        @Override
        public SeoulPizza build() {
            return new SeoulPizza(this);
        }
    }

    private SeoulPizza(Builder builder) {
        super(builder);
        sauceInside = builder.sauceInside;
    }
}

• 이제는 구체 클래스에 추상 빌더와 구체 빌더를 적용할 수 있겠습니다. 코드를 보겠습니다!

NewYorkPizza newYorkPizza = new NewYorkPizza
        .Builder(SMALL)
        .addTopping(SAUSAGE)
        .addTopping(ONION)
        .build();
        
SeoulPizza seoulPizza = new SeoulPizza
        .Builder()
        .addTopping(ONION)
        .sauceInside()
        .build();

• 이렇게 빌더 패턴을 적용하면 계층형 클래스에서도 유연하게 프로퍼티를 설정할 수 있는 것을 볼 수 있습니다. 

---

빌더 패턴 단점

물론 빌더 패턴에도 장점만 있는 것은 아닙니다.

1. 빌더 패턴을 적용해서 객체를 만들려면 빌더부터 만들어야 한다는 점
2. 코드가 장황한 만큼 최소 매개변수 4개이상의 되어야 값어치를 한다는 점
   1. 물론 API는 시간이 지날수록 매개변수가 많아진다는 점을 고려하면 빌더 패턴을 먼저 고려하는 것이 좋을 수 있겠다.
   2. Item1에서는 대놓고 정팩메를 고려하라고 했었지만, 점점 프로퍼티가 증가함에 따라 생성 방법 또한 늘어나 매개변수가 많아질 우려가 있다면 애초에 빌더로 설계하는 것이 나중에 고생을 덜 하지 않을까 .. 책 저자의 생각입니다.
   3. 필자는 Spring에서는 별도의 사전작업 없이 롬복 라이브러리만 추가한다면 @Builder만 붙여주면 되니 그냥 빌더를 고려하는 것이 좋다고 생각됩니다.

---

한 줄 요약

생성자, 정팩메가 처리할 매개변수가 많다면 빌더를 선택하는 것이 낫다.