두 개의 빌더 패턴이 있습니까?

Question

디자인 패턴을 연구 중이며 매우 혼란스러운 것을 발견했습니다. 빌더 패턴은 정확히 무엇입니까? 내가 찾은 두 가지 절대적으로 다른 목적이 있습니다.

첫 번째는 Erich Gamma가 자신의 저서 "디자인 패턴 - 재사용 가능한 객체 지향 소프트웨어의 요소 (내 개인 성서)"에서 설명하는 것입니다. Director가 빌드 된 객체의 구조를 알고 복잡한 하위 객체를 작성하는 방법을 알고있는 빌더를 사용하는 복잡한 객체를 작성하는 방법입니다. 콘크리트 빌딩 블록 구현과 구조를 분리하는 좋은 방법.

Joshua Bloch의 Effective Java를 읽기 시작할 때까지이 설명에 만족했습니다. 그는 빌더를 다양한 선택적 매개 변수에 대처할 수있는 패턴으로 설명하고 예를 들어 텔레스코픽 생성자의 문제를 매우 효과적으로 해결합니다.

위키 피 디아는 망원경 생성자를 처리하는 방법으로 조슈아 블로흐 (Joshua Bloch)와 같은 빌더 패턴을 이해합니다. http://en.wikipedia.org/wiki/Builder_pattern. 이것은 에릭의 설명과 절대적으로 아무런 관련이 없습니다.

무엇이 잘못 되었습니까?

Answer 1

3 가지 출처에서 제공하는 것과 양립 할 수있는 것은 없습니다. 빌더는 일종의 팩토리입니다. 최종 객체를 직접 인스턴스화하지는 않습니다.

빌더는 복잡한 인스턴스 작성 프로세스를 통해 사용자를 안내 할 수있는 팩토리로서, 한번 설정 한 특정 특성을 고정 할 수 있습니다.

그래서 많은 다형성 객체 중 1 개를 반환 할 수있는 팩토리입니다. 그 중 누구라도 누가 건설 과정의 어떤 종류인지 알 수있었습니다.

Gson gson = new GsonBuilder().setPrettyPrinting().create(); 

위의 예입니다. 'Gson'의 구체적인 사례는 무엇입니까? 누가 알아? 누가 신경 써?!

필자는 최근 매개 변수 조합을 기반으로 파일 합병 인스턴스를 작성한 빌더를 구현했습니다.

XEMErger merger = new XEMergerBuilder().build() //return a default auto-detecting merger 

XEMErger merger = new XEMergerBuilder.multi().strict(); // return multi-type merger with strict checking 

이 빌더 뒤에 논리를 구현 올바른 인스턴스가 매우 까다이었다 선택 및 오용위한 조리법했을 것이다 외부 사용자에게까지 떠나는 사람 중 하나로서.

공장에서 특정 하위 클래스를 선택하는 논리가 미쳐서 여러 입력 (이전 호출과 관련된 경우도 있음)에 의존하는 경우 빌더가 필요합니다. 이것은 거의 사용되지 않는 패턴이므로 오해하기 쉽습니다.