빌더가 안티패턴인 경우

얼마 전에 저는 "모범 사례"로 가득 찬 프로젝트에서 작업했으며 모든 곳에 철저히 적용되었습니다. 이러한 "모범 사례"중 하나는 POJO를 생성하기 위해 Builder를 의무적으로 사용하는 것이었습니다. POJO의 상용구 코드의 대부분은 IDE 플러그인에 의해 생성되었지만 코드의 아주 작은 부분에 불과했습니다. 실제 문제는 이러한 POJO를 사용하는 것이었습니다. 코드는 다음과 같은 조각들로 넘쳐났습니다.

    final MyPojo pojo = MyPojo.newBuilder()
                              .setThis(...)
                              .setThat(...)
                              .setSomethingElse(...)
                              ...
                              .build();

이러한 빌더의 남용은 몇 가지 부정적인 영향을 미칩니다.

코드가 불필요하게 장황합니다.

코드에서 오류가 발생하기 쉽습니다.

첫 번째 문제는 취향의 문제이지만 두 번째 문제는 그렇지 않습니다.
필요한 모든 필드가 설정되었는지 여부를 컴파일 타임에 알 수 있는 방법이 없습니다.

이 경우 일반 모든 인수 생성자 또는 팩토리 메서드가 더 잘 작동합니다. 컴파일러는 POJO를 생성하는 데 필요한 모든 매개변수를 전달하도록 합니다. 이 매개변수가 얼마나 정확한지는 다른 이야기지만 모든 것이 분명히 있을 것입니다. 빌더를 사용하면 한두 개를 쉽게 생략할 수 있습니다. 나중에 NPE를 얻을 때 런타임에 문제가 나타납니다.

위에서 언급한 프로젝트에서 그 관행을 도입한 밝은 마음은 문제를 해결하는 가장 좋은 방법은 build() 메서드에 유효성 검사를 추가하는 것이라고 결정했습니다. 결과적으로 NPE를 임의의 위치에서 가져오는 대신 build() 메서드 내부에서 가져오기 시작했습니다. 좋은 개선이죠?

위에서 설명한 안티 패턴은 컴파일 시간에서 런타임으로 오류를 이동하는 심각한 설계 실수의 더 넓은 클래스의 예입니다. 이러한 변화는 더 길고 고통스러운 개발에서부터 애플리케이션을 사용하는 사람들의 막대한 손실에 이르기까지 모든 규모의 문제를 요구합니다.

그렇다면 Builder의 올바른 사용법은 무엇입니까?

빌더 패턴을 올바르게 사용하는 기준은 매우 간단합니다.build() 메서드는 완전한 인스턴스를 생성해야 합니다. 사용자가 값을 제공하지 않은 경우 모든 필수 필드를 합리적인 기본값으로 설정해야 합니다.

POJO는 이런 식으로 빌드할 수 있는 클래스 범주에 거의 속하지 않습니다. 일반적으로 POJO에는 합리적인 기본값이 없는 정보를 나타내는 데 필요한 대부분 또는 모든 필드가 있습니다.

Builder가 자주 사용되는 또 다른 위치는 서버 또는 클라이언트 구성과 같은 것이며 일반적으로 Builder는 이러한 종류의 응용 프로그램에 완벽하게 적합합니다.