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

정적 팩토리와 생성자는 선택적 매개변수가 많을 때 대응하기 어렵다는 공통적인 제약이 있다.

꼭 내용이 들어가지 않아도 되는 선택적 매개변수가 많을 때 우리는 다음과 같은 선택지가 있다.

1. 점층적 생성자 패턴, telescoping constructor pattern

→ 필수 매개변수만 받는 생성자에서 선택 매개변수를 하나씩 추가해가면서 다수의 생성자를 만들어 사용하는 방식

public class NutritionsFacts_tcp {
    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 NutritionsFacts_tcp(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

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

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

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

    public NutritionsFacts_tcp(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;
    }
}

점층적 생성자 패턴에서는 원하는 매개변수가 모두 들어간 생성자 중 가장 짧은 것을 골라 사용하게 된다.

단점

사용자가 값을 설정하고 싶지 않은 매개변수임에도 어쩔 수 없이 값을 지정해줘야하는 경우가 발생한다.
매개변수 개수가 많아지면
- 지옥의 생성자 자가증식….
- 클라이언트 코드를 작성하거나 읽기 어려움
- 생성자의 매개변수를 잘못 매칭함으로서 생길 수 있는 휴먼 에러들…

2. 자바빈즈 패턴, JavaBeans pattern

매개변수가 없는 생성자로 객체를 만들고 setter로 원하는 매개변수의 값을 설정한다.

public class Nutritions_javabeans {
    private int servingSize; // (mL, 1회 제공량) 필수
    private int servings; // (회, 총 n회 제공량) 필수
    private int calories; // (1회 제공량당) 선택
    private int fat; // (g/1회 제공량) 선택
    private int sodium; // (mg/1회 제공량) 선택
    private int carbohydrate; // (g/1회 제공량) 선택

    public Nutritions_javabeans() {}

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

점층적 생성자 패턴에서 보이던 비슷비슷해보이는 생성자 더미들은 없지만 자바빈즈 패턴에는 심각한 단점이 있다.

단점

객체가 완전히 생성되기 전까지 일관성이 무너진 상태이다.
- 클래스를 불변으로 만들 수 없다.
객체 하나를 만들기 위해서 여러 메서드를 호출해야한다.

물론 이런 단점을 극복하고자 freezing이란 기법이 존재하지만 다루기 어렵다. 또한 freeze()가 쓰이고 있는지 컴파일러가 보증해줄 수 없기 때문에 런타임 오류에 취약하다.

3. 빌더 패턴, Builder pattern

(클라이언트는) 필수 매개변수만으로 생성자나 정적 팩토리를 호출하여 빌더 객체를 얻고, 이 빌더 객체가 제공하는 setter()로 원하는 선택 매개변수의 값을 빌더 객체에 지정한다. 마지막으로 Builder 객체로 타겟 객체를 생성하는 로직을 가진 build()로 원하던 객체를 얻는다.

public class Nutritions_builder {
    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; // (mL, 1회 제공량) 필수
        private final int servings; // (회, 총 n회 제공량) 필수

        private int calories = 0; // (1회 제공량당) 선택
        private int fat = 0; // (g/1회 제공량) 선택
        private int sodium = 0; // (mg/1회 제공량) 선택
        private int carbohydrate = 0; // (g/1회 제공량) 선택

        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 Nutritions_builder build() {
            return new Nutritions_builder(this);
        }
    }

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

// 클라이언트는 이렇게 가져다 쓸 수 있어요
Nutritions_builder newInstance = new Nutritions_builder.Builder(240, 8)
																					.calories(100)
																					.sodium(35)
																					.carbohydrate(27)
																					.build();

단점

객체를 만드려면 우선 빌더객체부터 만들어져야 한다.
→ 빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수도 있다.
코드가 장황해진다.

장점

fluent
→ 메서드 호출이 흐르듯 연결된다~, method chaining을 의미
가독성이 좋다.
자바빈즈보다 안전하다.
빌더의 메서드를 여러번 사용함으로써 가변인수 매개변수를 여러 개 사용할 수 있다.
계층적으로 설계된 클래스와 함께 사용하기 좋다.

불변, immutable → 어떠한 변경도 허용하지 않는다.

불변식, invariant → 프로그램이 실행되는 동안, 혹은 정해진 기간 동안 반드시 만족해야하는 조건

→ 근데.. 계층적으로 설계된 클래스와 함께 사용하기 좋다. ......? 에? 뭔 말?

계층적으로 설계된 클래스란?

아하 계층적으로 설계되었다고 해서 뭔가 낯설게 느껴졌는데 사실 우리가 잘 아는 것이다. 상속을 이용하여 설계된 클래스 구조!

// 상위 클래스
public class Animal {
    private String name;

    public Animal(String name) {
        this.name = name;
    }

    public void eat() {
        System.out.println(name + " is eating.");
    }

    public String getName() {
        return name;
    }
}

// 하위 클래스
public class Dog extends Animal {
    public Dog(String name) {
        super(name);
    }

    public void bark() {
        System.out.println(getName() + " is barking.");
    }
}

// 또 다른 하위 클래스
public class Cat extends Animal {
    public Cat(String name) {
        super(name);
    }

    public void meow() {
        System.out.println(getName() + " is meowing.");
    }
}

// 추상 클래스
public abstract class Bird extends Animal {
    public Bird(String name) {
        super(name);
    }

    public abstract void fly();
}

// 인터페이스
public interface Pet {
    void play();
}

// 인터페이스 구현
public class Parrot extends Bird implements Pet {
    public Parrot(String name) {
        super(name);
    }

    @Override
    public void fly() {
        System.out.println(getName() + " is flying.");
    }

    @Override
    public void play() {
        System.out.println(getName() + " is playing.");
    }
}

이런 구조들이 되겠다.

그렇다면 계층적으로 설계된, 그러니까 상속을 이용해서 설계된 클래스들은 왜 빌더 패턴을 사용하기 좋다고 하는 걸까.

이펙티브 자바에 나와있는 예시는 다음과 같다.

public abstract class Pizza {
    public enum Topping {
        CHEESE, PEPPERONI, CLAMS, VEGGIE
    }
    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();
        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;

    private NyPizza(Builder builder) {
        super(builder);
        size = builder.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;
        }
    }
}

public class Calzone extends Pizza {
    private final boolean sauceInside;

    private Calzone(Builder builder) {
        super(builder);
        sauceInside = builder.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;
        }
    }
}

이렇게 사용했을 때 장점은 다음과 같다.

추상 클래스로 선언한 Builder의 선언에 따라 하위 클래스의 빌더가 정의한 build 메서드는 구체 하위 클래스를 반환한다. : Pizza가 아니라 NyPizza, Calzone를 반환한다는 뜻. → 공변환 타이핑(covariant return typing) 이렇게 되면 클라이언트는 형변환에 신경쓰지 않고 빌더를 사용할 수 있다.
추상 메서드 self를 더해서 하위 클래스에서 형변환하지 않고 메서드 연쇄를 지원할 수 있다.
(내 생각) 상위 클래스, Pizza에서 피자에 모두 공통되게 들어가는 topping이라는 필드에 대해서 값을 셋팅해줄 수 있는 빌더 메서드를 지원함으로서 Pizza 구현 클래스들에게 공통적인 로직을 제공할 수 있다는 장점이 있을 것 같다.

개인적인 생각정리

나도 빌더를 많이 쓰지만, 무지성으로 롬복이 이끄는대로 사용했었는데..ㅎㅎㅋ 항상 빌더를 쓸까 정팩메로 쓸까 고민되는 지점이 휴먼 에러로 빌더에 특정 필드를 누락시켰을때, 값이 null로 지정되어도 개발할 당시에 내가 알 방법이 없어서 위험하다는 지점이었다. 그런데 이번에 빌더 클래스를 똑바로 읽고 나니까, 필수적으로 값이 지정되어야 하는 요소에 대해서 빌더 생성자의 파라미터에 값을 넣도록 할 수 있다는 것을 알게 되어서 이런식으로 쓰면 좀 더 편리하고 안전하게 빌더를 쓸 수 있을 것 같다. 그리고 값 셋팅해주는 메서드에 유효성 검증 로직을 넣을 수 있다는 점도…..

흠 그런데 마지막에 계층적 설계에서 빌더가 주는 장점을 아직은 공감을 못하겠다. 내 생각인 3번째는 내 생각이니까 그러려니하는데……아직 1,2번 장점은… 직접 겪게 되면 더 와닿을듯

만일 이런 예제가 생긴다면 여기에 다시 기록해두도록 하겠음….

[ 참고 ]

https://m.yes24.com/Goods/Detail/65551284

이펙티브 자바 Effective Java 3/E - 예스24

자바 플랫폼 모범 사례 완벽 가이드 - Java 7, 8, 9 대응자바 6 출시 직후 출간된 『이펙티브 자바 2판』 이후로 자바는 커다란 변화를 겪었다. 그래서 졸트상에 빛나는 이 책도 자바 언어와 라이브

m.yes24.com

그리고... thanks to 약 500장의 책을 함께 끝낸 스터디원느님들......

저작자표시 비영리 변경금지

'JAVA > effective-java' 카테고리의 다른 글

💣 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라. (0)	2024.08.06
01. 생성자 대신 정적 팩터리 메서드를 고려하라. (0)	2024.05.30

낭만 가득한 이성

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

1. 점층적 생성자 패턴, telescoping constructor pattern

단점

2. 자바빈즈 패턴, JavaBeans pattern

단점

3. 빌더 패턴, Builder pattern

단점

장점

계층적으로 설계된 클래스란?

개인적인 생각정리

[ 참고 ]

'JAVA > effective-java' 카테고리의 다른 글

댓글

티스토리툴바

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

1. 점층적 생성자 패턴, telescoping constructor pattern

단점

2. 자바빈즈 패턴, JavaBeans pattern

단점

3. 빌더 패턴, Builder pattern

단점

장점

계층적으로 설계된 클래스란?

개인적인 생각정리

[ 참고 ]

'JAVA > effective-java' 카테고리의 다른 글

관련글

댓글

티스토리툴바