[Item02] Builder Pattern의 장단점은 무엇인가

인스턴스 생성할 때 받아야 하는 매개변수가 무지막지하다면 어떻게 해야 할까?
1. telescoping constructor pattern
2. java beans pattern
3. builder pattern

 

점층적 생성자 패턴은 받아야 하는 생성자 오버로딩을 통해 매개변수 수를 늘려가는 것이다
매개변수 개수에 따라 계속 늘어나야 하므로 유지보수까지 생각한다면 지옥이나 다름없다

boiler plate가 차지하는 코드가 도메인에서 필요한 필드, 메서드 보다 더 많아질 수 있다

Java Beans Pattern 은 기본 생성자를 하나 두고 setter로 필드 값을 지정해준다
하나의 instance 만들려면 setter 난무해야 하고 필수 값을 빠뜨리고 생성할 수도 있기 때문에 일관성이 보장되지 않는다

setter를 열어뒀기 때문에 불변 객체로 만들 수 없다는 단점도 있다

 

생성자를 이용하면 어떤 필드가 필수 매개변수인지 혼란스러워지는데 요럴 때 Builder Pattern이 유용하다
점층적 생성자 패턴도 사용 가능하지만 일일이 다 생성하기 너무 힘드니 변경에 유연하게 대응하기 위해서는 Builder 쓰자
lombok에서 제공해주니까 편하게 사용할 수 있다, 롬복이 대략 아래와 같은 놈을 만들어 준다

public class NutritionFacts {

    public static class Builder {
        private int fat;
        private int sodium;
        private int calories;    
        private int carbohydrate;
        private final int servings;
        private final int servingSize;    

        public Builder(int servingSize, int servings) {
          this.servingSize = servingSize;
          this.servings = servings;
        }
        // final 아닌 것들의 만들어지는 형태
        public Builder calories(int calories) {
          this.calories = calories;
          return this;
        }
    }
}

 

 

빌더를 쓰는 게 좋겠다는 것은 알겠고 빌더를 쓸 때의 위험성은 어떻게 될지도 생각해 볼 수 있다

아래 사이트를 참고해 Builder Pattern의 장점과 단점을 확인할 수 있다

Builder Design pattern in Java - Java Code Geeks - 2022

 

중요 내용만 옮겨왔다.

- Advantages:

1) more maintainable if number of fields required to create object is more than 4 or 5.
2) less error-prone as user will know what they are passing because of explicit method call. 
3) more robust as only fully constructed object will be available to client.

 

- Disadvantages: 

1) verbose and code duplication as Builder needs to copy all fields from Original or Item class.

When to use Builder Design pattern in Java Builder Design pattern is a creational pattern and should be used when number of parameter required in constructor is more than manageable usually 4 or at most 5. 

 

Builder Pattern의 단점은 명확하다, Builder를 위해 작성해야 하는 코드가 장황하다

따라서 생성자에서 받는 매개변수가 4-5개 이상일 때부터 효용이 Builder를 작성할 때의 수고보다 커진다

우리가 작성해야 하는 코드가 많은 것이 문제라면 Lombok을 쓰면 되지 않는가?

컴파일된 클래스 파일에서 자동으로 생성된 코드가 많아지는 것이 문제라면 점층적 생성자 패턴은 더 노답 아닌가?

Lombok 사용이 문제라면 그냥 점층적 생성자나 자바 빈즈 패턴을 사용하도록 하자

 

Naver D2, 우아한 형제들 기술 블로그를 참고해봐도 이들 역시 롬복을 사용한다는 것을 알 수 있다

네이버랑 배민이 쓰니까 너네도 써라 이런 것이 아니라 국내 탑티어 회사들이 도입할 정도라면

심각한 보안 구멍이나 프로젝트에 크리티컬한 영향을 끼치지 않는 것이 어느 정도는 보장된다고 생각한다

 

Lombok은 해킹이라 절대 사용해서는 안 된다는 의견도 존재한다

편의성을 위해 도입할지, 안정성을 위해 도입하지 않을지는 프로젝트를 진행하는 개인 / 팀의 합의만 맞으면 된다

annotation processor를 올바른 방식으로 사용하지 않았다고 해서 사용하지 않는 것은 극단주의적인 태도인 것 같다

그렇게 따지면 Enum으로 싱글턴을 구현하는 조슈아 블로치도 사파다

https://stackoverflow.com/questions/6107197/how-does-lombok-work#:~:text=So%20Lombok%20is%20a%20huge,such%20a%20non%2Dstandard%20hack.

 

 

한 가지 더 생각해 볼만한 점이 있다

'빌더를 Entity에서 주로 사용할 텐데 생성자 validation 은 어떻게 할 것인가'라는 점인데

예전에 작성했던 미니 프로젝트에 대한 코드 리뷰에서 받은 코멘트였다

짧은 식견으로는 API 엔드포인트에서 @Valid로 걸러버리니까 도메인에 잘못 들어갈 일이 없지 않을까 하는 생각이다

내가 했던 프로젝트를 기준으로 생각했던 내용이고, 프로덕션 코드를 보지 못해서 어떤 것이 맞는지 확정 지을 순 없겠다

설령 내 생각이 맞더라도 빌더 패턴에서 validation이 문제가 될 수도 있다는 것을 생각해보지 않았어서

생각을 넓힐 수 있는 의미 있는 코멘트였다 추후 다른 생각이 떠오르면 업데이트 해야겠다