[아이템 2] 생성자에 매개변수가 많다면 빌더를 고려하라
아이템 1에서 정적 팩터리 메서드와 그리고 그냥 생성자에 대해서 다루어 보았음
그리고 정적 팩터리 메서드를 사용하는 것이 생성자를 쓰는 것보다 낫다고 하였는데 여기서 둘 다 똑같은 제약이 존재함, 선택적 매개변수가 많을 때 적절히 대응하기가 어려움
즉, 선택 항목의 대다수 값이 0이면 굳이 그렇게 쓸 이유가 없는 것임
점층적 생성자 패턴
-
필수 매개변수만 받는 생성자, 필수 매개변수와 선택 매개변수 1개를 받는 생성자, 선택 매개변수를 2개까지 받는 생성자,... 형태로 선택 매개변수를 전부 받는 생성자까지 늘려가는 방식임
-
예를 들면 아래와 같음
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; // (mg/1회 제공량) 선택
private final int carbohydrate; //(g/1회 제공량) 선택
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;
}
}
-
이 클래스의 인스턴스를 만들려면 원하는 매개변수를 모두 포함한 생성자 중 가장 짧은 것을 골라 호출하면 됨
NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 0, 35, 27);
-
보통 이런 생성자는 사용자가 설정하길 원치 않는 매개변수까지 포함하기 쉬운데, 어쩔 수 없이 그런 매개변수에도 값을 지정해줘야함
-
예시코드만 봤을 때 매개변수가 6개 뿐이라서, 쓸 만 하다고 생각될 수 있지만 수가 더 늘어나면 걷잡을 수 없게됨
-
위와 같이 점층적 생성자 패턴도 쓸 수 있지만, 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어려움
-
어떤 측면에서 어렵냐면 코드를 읽을 때 각 값의 의미가 무엇인지 헷갈리고 매개변수가 몇 개 인지도 주의해서 세어 보아야하고 타입이 같은 매개변수가 연달아 늘어서 있으면 찾기 어려운 버그로 이어질 수 있음
-
그리고 클라이언트 실수로 매개변수의 순서를 바꿔 건네줘도 컴파일러는 알아채지 못하고 엉뚱하게 동작을 함
자바 빈즈 패턴
-
매개변수가 없는 생성자로 객체를 만든 후, Setter 메서드들을 호출해 원하는 매개변수 값을 설정하는 방식
-
인스턴스를 만들기 쉽고 그 결과 더 읽기 쉬운 코드가 됨
-
예를 들면 아래와 같음
public class NutritionFacts {
// 매개변수들은(기본값이 있다면) 기본값으로 초기화된다.
private final int servingSize = -1; // 필수; 기본값 없음
private final int servings = -1; // 필수; 기본값 없음
private final int calories = 0;
private final int fat = 0;
private final int sodium = 0;
private final int carbohydrate = 0;
public NutritionFacts() { }
// 세터 메서드들
public void setServingSize(int val) {servingSize = val;}
public void setServings(int val) {servings = val;}
public void setCalories(int val) { calories = val;}
public void setFat(int val) { fat = val;}
public void setSodium(int val) {sodium = val;}
public void setCarbohydrate(int val) { carbohydrate =val;}
}
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setSodium(35);
cocaCola.setCarbohydrate(27);
-
하지만 이 자바 빈즈 패턴에도 큰 단점이 있음, 객체 하나를 만들려면 메서드를 여러 개 호출해야 하고 객체가 완전히 생성되기 전까지는 일관성이 무너진 상태에 놓이게 됨
-
일관성이 무너지기 때문에 자바 빈즈 패턴에서는 클래스를 불변으로 만들 수 없으며 스레드 안전성을 얻으려면 프로그래머가 추가 작업을 해줘야만 함
-
이러한 단점을 보완하고자 생성이 끝난 객체를 수동으로 얼리고 얼리기 전에는 사용할 수 없도록 하기도 함, 이 방법을 쓴다고 해도 freeze 메서드를 확실히 호출 했는지 보증이 없어서 런타임 오류에 취약함
freeze 메서드 사용을 통한 불변성 유지? 보증을 못 함?
freeze 메서드 활용
이 자바 빈즈 패턴에서 freeze 메서드를 사용하는 것을 간단히 알아보면 아래와 같이 setter메서드에서 freeze를 주는 것임
public class A {
private String a;
private int b;
private boolean freeze = false;
public A() {}
public void setA(String a) {
if (isFreeze()) {
throw new AssertionError("완성된 객체는 불변성을 유지해야 합니다.");
}
this.a = a;
}
public String getA() {
return a;
}
public void setB(int b) {
if (isFreeze()) {
throw new AssertionError("완성된 객체는 불변성을 유지해야 합니다.");
}
this.b = b;
}
public int getB() {
return b;
}
public boolean isFreeze() {
return freeze;
}
public void freeze() {
this.freeze = true;
}
}
A a = new A();
a.setA("A");
a.setB(2);
a.freeze();
하지만 위와 같이 처리를 했어도 멀티 스레딩 환경의 경우 이 메서드를 확실히 호출했다고 컴파일러가 보증할 방법이 없음
빌더 패턴
-
점층적 생성자 패턴의 안전성과 자바 빈즈 패턴의 가독성을 겸비한 빌더 패턴이 있음
-
클라이언트는 필요한 객체를 직접 만드는 대신 필수 매개변수만으로 생성자(혹은 정적 팩터리)를 호출해 빌더 객체를 얻음
-
그런 다음 빌더 객체가 제공하는 일종의 setter 메서드들로 원하는 선택 매개변수를 설정함
-
마지막으로 매개변수가 없는 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 final int calories = 0;
private final int fat = 0;
private final int sodium = 0;
private final 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 클래스는 불변이고 모든 매개변수의 기본값들을 한 곳에 모아둠
-
빌더의 setter 메서드들은 빌더 자신을 반환하기 때문에 연쇄적으로 호출 할 수 있음, 이런 방식을 메서드 호출이 흐르듯 연결된다는 뜻으로 플루언트 API 혹은 메서드 연쇄라고 함
여기서 책에서 유효성 검사를 생략했다는데 이를 추가하면 어떻게 될까?
빌더 패턴에서의 유효성 검사
빌더 패턴은 개발하는데 있어서 자바 기반의 프레임워크에 개발을 할 때 종종 사용됨이 내포되어 있음
유효성 검사를 추가한다면 빌더의 생성자나 메서드에서 검사하고 build()가 호출하는 생성자에서 불변식 검사등 추가할 수 있음
TargetObject build() {
TargetObject res = new TargetObject();
res.setProperty1();
res.setProperty2();
validate(res); // This call may throw an exception
return res;
}
void validate(TargetObject obj) {
if (...) {
throw new IllegalStateException();
}
}
TargetObject build() {
TargetObject res = new TargetObject();
res.setProperty1();
res.setProperty2();
if (...) {
throw new IllegalStateException();
}
return res;
}
위와 같이 빌더 패턴 사용시 유효성 검사를 추가적으로 진행해 줄 수 있음
- 클라이언트에서는 아래와 같이 사용 가능함
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
.calories(100).sodium(35).carbohydrate(27).build();
-
이 클라이언트 코드는 쓰기 쉽고, 읽기 쉬움, 빌더 패턴은 명명된 선택적 매개변수를 흉내 낸 것
-
여기서 잘못된 매개변수를 최대한 일찍 발견하려면 위와 같이 빌더의 생성자와 메서드에서 입력 매개변수를 검사하고 이런식으로 불변식 검사를 할 수 있음
-
여기서 검사해서 잘못된 점을 발견하면 어떤 매개변수가 잘못되었는지를 자세히 알려주는 메시지를 담아
IllegalArgumentException
을 던질 수 있음(이 부분에 대해서는 아이템 50, 75에서 상세히 다룰 것임)
불변과 불변식?
불변
불변은 어떠한 변경도 허용하지 않는다는 뜻으로, 주로 변경을 허용하는 가변 객체와 구분하는 용도로 쓰임(대표적으로 String객체는 한 번 만들어지면 절대 값을 바꿀 수 없는 불변 객체임)
불변식
불변식은 프로그램이 실행되는 동안, 혹은 정해진 기간 동안 반드시 만족해야 하는 조건을 말함, 변경을 허용할 수 있으나 주어진 조건 내에서만 허용한다는 뜻임
-
빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰기에 좋음
-
각 계층의 클래스에 관련 빌더를 멤버로 정의함, 추상 클래스는 추상 빌더를 구체 클래스는 구체 빌더를 갖게함
-
예를 들어 피자의 다양한 종류를 표현하는 계층구조의 루트에 놓인 추상 클래스를 아래와 같이 쓸 수 있음
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.requiredNonNull(topping));
return self();
}
abstract Pizza build();
// 하위 클래스는 이 메서드를 재정의(overriding)하여
// "this"를 반환하도록 해야 한다.
protected abstract T self();
}
Pizza(Builder<?> builder) {
toppings = builder.toppings.clone();
}
}
-
Pizza.Builder
클래스는 재귀적 타입 한정을 이용하는 제네릭 타입임 -
여기에 추상 메서드인
self
를 더해 하위 클래스에서는 형변환하지 않고도 메서드 연쇄를 지원할 수 있음,self
타입이 없는 자바를 위한 이 우회 방법을 시뮬레이트한 셀프 타입 관용구라고 함
재귀적 타입 한정과 시뮬레이트한 셀프 타입 관용구?
재귀적 타입 한정
재귀적 타입 한정은 자기 자신이 들어간 표현식을 사용하여 타입 매개변수의 허용 범위를 한정하는 케이스임
이를 이해하기 쉽게 Comparable
과 비교를 해본다면 static <T extends Comparable<T>>
가 있는데 이는 자신과 비교될 수 있는 모든 타입 T 즉, 모든 타입 T는 자신과 비교할 수 있다는 것임
여기서 Comparable
의 예시를 생각하면 Wrapper
타입의 경우, 이를 비교 연산을 한다고 할 때 비교연산자를 사용할 수 없기 때문에 이를 재귀적 타입 한정을 활용해서 쓸 수 있음
public static <T extends Comparable<T>> int countGreaterThan(T[] anArray, T elem) {
int count = 0;
for (T e : anArray)
if (e.compareTo(elem) > 0)
++count;
return count;
위의 비교 연산의 경우 그러면 Comparable
이 연산하고자 하는 Wrapper Class
로 한정이 되는 것임
- 이를 본문의 NyPizza와 Calzone의 경우 Builder 상속시 재귀적 타입 한정으로 상속 받아서 사용되는 것임, 그러면 Builder가 T가 자신을 포함하는 수식 Builder에 한정이 됨
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.requiredNonNull(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;
}
}
제네릭
여기서 하나 더 짚고 넘어간다면 제네릭임, 제네릭의 정의는 데이터 형식에 의존하지 않고 하나의 값이 여러 다른 데이터 타입들을 가질 수 있도록 하는 방법임
이러면 제네릭은 클래스 내부에서 지정하는 것이 아닌 외부에서 사용자에 의해 지정되는 것임
그러면 위에서 Comparable
이나 Builder
나 지정은 외부에서 해주는 것이어서 Comparable
에서 Wrapper Class
에서는 비교 연산이 안되기 때문에 비교 연산을 하고자 하는 Wrapper Class
가 정해지는 것이고 Builder
의 경우도 Builder
를 구체적으로 구현하는 방향에 있어서 책에서 NyPizza
, Calzone
의 조건이 다르기 때문에 제네릭을 통해서 각각 맞춰서 Builder가 될 수 있도록 해줄 수 있었던 것임
시뮬레이트한 셀프 타입
여기서 시뮬레이트한 셀프 타입이 재귀적 타입 한정의 경우와 같이 쓰는 것인데 하위 클래스에서 형변화하지 않고 메서드 연쇄를 지원할 수 있는 것임
이 말은 위에서 Pizza
의 Builder
의 추상 클래스를 가지고 self
를 오버라이딩을 하는데 있어서 자기 자신 this를 return함으로 형변환을 하지 않고 메서드 연쇄를 지원한다는 것임, 이를 코드로 자세히 본다면
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);
}
// self를 오버라이딩해서 NyPizza 자신을 return함, 형변환 하지 않아도 됨
@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);
}
// self를 오버라이딩해서 Calzone 자신을 return함, 형변환 하지 않아도 됨
@Override protected Builder self() { return this; }
}
private Calzone(Builder builder) {
super(builder);
sauceInside = builder.sauceInside;
}
}
형변환을 하지 않는다는 것은 아래처럼 형변환을 생각하지 않고 빌더를 사용한다는 것을 의미함(열거 타입 상수는 임포트 했다는 가정)
public class Main {
public static void main(String[] args) {
NYPizza pizza = new NYPizza.Builder(SMALL)
.addTopping(SAUSAGE)
.addTopping(ONION)
.build();
Calzone calzone = new Calzone.Builder()
.addTopping(HAM)
.sauceInside()
.build();
}
}
공변 변환 타입
여기서 위와 같이 Pizza
에서 self
구현시 Builder
로 Calzone, NyPizza를 return this;
를 하기 때문에 반환형을 자기 자신으로 오버라이딩하는 경우인 것
하위 타입을 반환을 해도 문제가 없는 것이고 더 좁은 타입 즉, 하위 타입으로 교체될 수 있는 경우를 말하는 것임(Calzone, NyPizza라는 더 하위 타입으로 반환을 해서 교체가 된 것인데 문제가 없으므로)
일반적인 정의로 말하면 메서드가 오버라이딩될 때 더 좁은 타입으로 교체할 수 있다는 것임
-
빌더를 이용하면 가변인수 매개변수를 여러 개 사용할 수 있음, 각각을 적절한 메서드로 나눠 선언하면 됨
-
아니면 메서드를 여러 번 호출하도록 하고 각 호출 때 넘겨진 매개변수들을 하나의 필드로 모을 수 있음
-
빌더 패턴은 상당히 유연함, 빌더 하나로 여러 객체를 순회하면서 만들 수 있고 빌더에 넘기는 매개변수에 따라 다른 객체를 만들 수 있음, 객체마다 부여되는 일련번호와 같은 특정 필드는 빌더가 알아서 채우는 것
-
단, 성능에 민감한 경우 문제가 될 수 있음, 매개변수가 4개 이상은 되야 값어치를 함
-
하지만 API는 시간이 지날수록 매개변수가 많아지는 경향이 있음, 애초에 빌더로 시작하는게 나을 수 있음
-
생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는게 나음
Author And Source
이 문제에 관하여([아이템 2] 생성자에 매개변수가 많다면 빌더를 고려하라), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@gang_shik/아이템-2-생성자에-매개변수가-많다면-빌더를-고려하라저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)