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

정적 팩터리와 생성자의 제약

선택적 매개변수가 많을 때 적절히 대응하기 어렵다
- 매개변수가 5개인데 경우에 따라 0개 ~ 5개의 매개변수에 값을 넣어서 생성한다면 어떻게 대응해야 하는가?

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

public class NutritionFacts {
    private final int servingSize;	// (ml, 1회 제공량)		필수
    private final int servings;		// (회, 총 n회 제공량)		필수
    private final int calories;		// (1회 제공량당)		선택
    private final int fat;		// (g/1회 제공량)		선택
    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,  fat, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium) {
        this(servingSize, servings, calories,  fat,  sodium, 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;
    }
}

매개변수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다
코드를 읽을 때 각 값의 의미가 무엇인지 헷갈린다
매개변수가 몇 개인지도 주의해서 세어 보아야 한다
실수를 해도 컴파일러는 알아채지 못하고 런타임에 기대한 것과 다르게 동작하게 된다.

선택적 매개변수가 많을 때를 해결하기 위한 대안으로 사용할 수 있지만 단점이 너무 많다..!

자바빈즈 패턴(JavaBeans pattern)

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

// main
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setFat(0);
cocaCola.setSodium(35);
cocaCola.setCarbohydrate(27);

점층적 생성자 패턴의 단점을 해결함
코드가 길어지긴 했지만 인스턴스를 만들기 쉽고 읽기 쉬움

단점

객체 하나를 만들려면 메서드를 여러 개 호출해야 한다.
객체가 완전히 생성되기 전까지는 일관성(consisency)이 무너진 상태에 놓인다.
- 점층적 생성자 패턴에서는 매개변수들이 유효한지를 생성자에서만 확인하면 되지만 어디서 set을 호출할지 모르기 때문에 일관성이 깨진다
- 스레드 안전성을 얻기 위한 추가 작업이 필요
  - 생성이 끝난 객체를 수동으로 freeze 하고 freeze 하기 전에는 사용할 수 없도록 한다
  - 확실히 freeze를 했는지 컴파일러가 보증할 수 없어 런타임 오류에 취약

빌더 패턴

필요한 객체를 직접 만드는 대신, 필수 매개 변수만으로 생성자를 호출해 빌더 객체를 얻어 빌더 객체가 제공하는 일종의 세터 메서드들로 원하는 선택 매개변수들을 설정하는 방식
점층적 생성자 패턴의 안정성과 자바빈즈 패턴의 가독성을 겸비

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;

    private NutritionFacts(Builder builder) {
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.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;

        // 필수 매개변수만을 담은 Builder 생성자
        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

        // 선택 매개변수의 setter, Builder 자신을 반환해 연쇄적으로 호출 가능
        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;
        }
        
        // build() 호출로 최종 불변 객체를 얻는다.
        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }
}

NutritionFacts 클래스는 불변이다
- 매개변수가 모두 final
빌더의 세터 메서드들은 빌더 자신을 반환하기 때문에 연쇄적으로 호출 가능
- method chaining을 통해 쓰기 쉬운 코드와 읽기 쉬운 코드를 작성

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

여기서 보면 유효성을 검사하는 코드가 생략되었다.

잘못된 매개변수를 최대한 일찍 발견하려면 빌더의 생성자와 메서드에서 입력 매개변수를 검사해야 한다
build 메서드가 호출하는 생성자에서 여러 매개변수에 걸친 불변식을 검사
불변식을 보장하려면 빌더로부터 매개변수를 복사한 후 해당 객체 필드들도 검사해봐야 한다

불변과 불변식의 차이?

불변(immutable 혹은 immutability)은 어떠한 변경도 허용하지 않는다는 뜻으로, 주로 변경을 허용하는 가변(mutable) 객체와 구분하는 용도로 쓰인다. 대표적으로 String 객체는 한번 만들어지면 절대 값을 바꿀 수 없는 불변 객체다.
한편, 불변식(invariant)은 ㅍ ㅡ로그램이 실행되는 동안, 혹은 정해진 기간 동안 반드시 만족해야 하는 조건을 말한다. 다시 말해 변경을 허용할 수는 있으나 주어진 조건 내에서만 허용한다는 뜻
예컨대 리스트의 크기는 반드시 0 이상이어야 하니, 만약 한순간이라도 음수 값을 가진다면 불변식이 깨진 것,
기간을 표현하는 Period 클래스에 start와 end 필드 값이 역전되면 불변식이 깨진 것이다.
따라서 가변 객체에도 불변식은 존재할 수 있으며, 넓게 보면 불변은 불변식의 근단적인 예라 할 수 있다.

계층적으로 설계된 클래스와 Builder

public abstract class Pizza{
   public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
   final Set<Topping> toppings;

   // 추상 클래스는 추상 Builder를 가진다. 서브 클래스에서 구체적인 Builder를 구현한다.
   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();

      // 하위 클래스는 이 메서드를 overriding하여
      // 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;
   }
}

Pizza.Builder 클래스는 재귀적 타입 한정을 이용하는 제네릭 타입이다.
추상 메서드인 self를 더해 하위 클래스에서는 형 변환하지 않고도 메서드 연쇄를 지원
self 타입이 없는 자바를 위한 우회 방법을 시뮬레이트 한 셀프 타입 관용구라 한다

'계층적 빌더'를 사용하는 코드도 영양정보 빌더를 사용하는 코드와 다르지 않다.

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

생성자로 누릴 수 없는 사소한 이점으로, 빌더를 이용하면 가변 인수 매개변수를 여러 개 사용할 수 있다.

빌더 패턴의 단점

객체를 만들려면, 그에 앞서 빌더부터 만들어야 하기 때문에 성능에 민감한 상황에서 문제가 될 수 있음
- 빌더 생성 비용이 크진 않다!
점층적 생성자 패턴보다는 코드가 장황해서 매개변수가 4개 이상은 되어야 값어치를 한다
- API를 설계하는 사람은 시간이 지날수록 API 스펙이 변할 수 있고 보통 매개변수가 증가한다!

단점이라고 하지만 다시 보면 빌더를 써야 하는 이유가 보인다..

정리

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

프로젝트에 참여했을 때 Entity들에 빌더 패턴을 적용한 모습을 볼 수 있었다. 처음엔 빌더라는 객체를 보고 뭐지 이건.. 하면서 그냥 사용법만 배워서 썼던 기억이 있다. 가끔 객체를 생성한 후 필드 값을 변경하고 싶어 세터를 사용하고 싶었던 적도 있었는데, 이런 부분이 일관성을 깨는 부분이 된다는 것을 깨달을 수 있었다. 빌더 패턴을 적용하는 코드가 장황하지만 만들어두면 너무 편리하고 꽤나 안전하다는 것을 배웠으니 이제 사용 이유를 이해하고 잘 사용하도록 해야겠다.

'Java' 카테고리의 다른 글

Item6 불필요한 객체 생성을 피하라 (0)	2022.12.09
Item5 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 (0)	2022.12.07
Item4 인스턴스화를 막으려거든 private 생성자를 사용하라 (0)	2022.12.06
Item3 private 생성자나 열거 타입으로 싱글턴임을 보증하라 (0)	2022.12.02
Item 1 생성자 대신 정적 팩터리 메서드를 고려하라 (0)	2022.11.07

공부하고 기록하는 블로그

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

'Java' 카테고리의 다른 글

티스토리툴바

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

'Java' 카테고리의 다른 글

관련글

티스토리툴바