최근 에 Code Review 에서 내 자바 답변을 삭제했습니다 .
private Person(PersonBuilder builder) {중지. 빨간 깃발. PersonBuilder는 Person을 빌드합니다. 그것은 사람에 대해 알고 있습니다. Person 클래스는 PersonBuilder에 대해 아무 것도 알 수 없습니다. 불변 유형입니다. 여기에 원형 커플 링을 만들었습니다. 여기서 A는 A에 의존하고 B는 A에 의존합니다.
사람은 그 매개 변수를 섭취해야합니다. 사람을 만들지 않고 기꺼이 만들려는 고객은 그렇게 할 수 있어야합니다.
나는 공감대를 때렸고 레드 플래그를 말한 이유는 무엇입니까? 이 구현은 Joshua Bloch의 "Effective Java"책 (항목 # 2)에서 설명한 것과 동일한 모양을 갖습니다.
따라서 Java에서 빌더 패턴 을 구현하는 올바른 방법은 빌더를 중첩 유형 (이 질문은 아니지만)으로 만든 다음 제품 (작성중인 객체의 클래스) 을 만드는 것입니다 ) 다음과 같이 빌더에 대한 종속성을 가져옵니다 .
private StreetMap(Builder builder) { // Required parameters origin = builder.origin; destination = builder.destination; // Optional parameters waterColor = builder.waterColor; landColor = builder.landColor; highTrafficColor = builder.highTrafficColor; mediumTrafficColor = builder.mediumTrafficColor; lowTrafficColor = builder.lowTrafficColor; }
동일한 빌더 패턴에 대한 동일한 Wikipedia 페이지에는 C #에 대해 매우 다른 (그리고 훨씬 더 유연한) 구현이 있습니다.
//Represents a product created by the builder public class Car { public Car() { } public int Wheels { get; set; } public string Colour { get; set; } }
보시다시피, 여기에 있는 제품 은 Builder클래스 에 대해 아무것도 알지 못하며 직접 생성자 호출, 추상 팩토리 또는 ... 또는 빌더로 인스턴스화 할 수 있습니다. 내가 이해하는 한 창조 패턴의 산물 은 그것을 창조하는 것에 대해 아무것도 알 필요가 없습니다 .
필자는 Bloch의 책에서 명백하게 방어 된 반론을 받았고 빌더 패턴을 사용하여 생성자가 수십 개의 선택적 인수로 부풀린 유형을 재 작업하는 데 사용할 수 있다고했습니다. 그래서 그 대신 내가 무엇을 엄선 생각 나는이 사이트에 약간의 연구 알고, 내가 의심으로, 발견 이 인수하지 않는 물을 개최 .
그래서 거래는 무엇입니까? 처음에는 존재하지 않아야하는 문제에 대해 과도하게 엔지니어링 된 솔루션 을 제안하는 이유는 무엇 입니까? Joshua Bloch를 1 분 동안 받침대에서 떼어 내면 두 가지 콘크리트 유형을 결합하고 모범 사례라고 부르는 한 가지 좋은 정당한 이유를 생각 해낼 수 있습니까?
이것은 나에게 화물 컬트 프로그래밍 의 모든 악취 .