클래스에 많은 매개 변수가있는 생성자 (예 : 4 개 이상)가 있으면 코드 냄새 일 가능성이 높습니다 . 클래스가 SRP를 충족하는 경우 다시 고려해야 합니다.
그러나 10 개 이상의 매개 변수에 의존하고 결국 빌더 패턴을 통해 모든 매개 변수를 설정하는 것으로 끝나는 경우 어떻게해야합니까? Person개인 정보, 작업 정보, 친구 정보, 관심사 정보, 교육 정보 등 을 사용하여 유형 객체를 작성 한다고 상상해보십시오 . 이것은 이미 훌륭하지만 어떻게 든 4 개 이상의 매개 변수를 설정했습니다. 이 두 경우가 같은 것으로 간주되지 않는 이유는 무엇입니까?
답변:
빌더 패턴은 많은 인수의 "문제"를 해결하지 않습니다. 그러나 왜 많은 논쟁이 문제가 되는가?
true어떤 이유로 든 경우에는 알 수 없습니다.빌더 패턴 주소 이러한 문제 많은 인수 함수 호출 즉 유지 보수 문제의 한 * . 그래서 같은 함수 호출
MyClass o = new MyClass(a, b, c, d, e, f, g);
될 수 있습니다
MyClass o = MyClass.builder()
.a(a).b(b).c(c).d(d).e(e).f(f).g(g)
.build();
* 빌더 패턴은 원래 복합 객체를 조립하기위한 표현에 무관 한 접근 방식으로 의도되었는데, 이는 매개 변수에 대한 명명 된 인수보다 훨씬 큰 열망입니다. 특히 빌더 패턴에는 유연한 인터페이스가 필요하지 않습니다.
존재하지 않는 빌더 메소드를 호출하면 폭발 할 것이기 때문에 약간의 추가 안전을 제공하지만 그렇지 않으면 생성자 호출의 주석에없는 것이 없습니다. 또한 빌더를 수동으로 작성하려면 코드가 필요하며 더 많은 코드에는 항상 더 많은 버그가 포함될 수 있습니다.
새로운 값 유형을 쉽게 정의 할 수있는 언어에서는 마이크로 타이핑 / 작은 유형 을 사용하여 명명 된 인수를 시뮬레이션 하는 것이 더 낫다는 것을 알았습니다 . 유형이 실제로 작기 때문에 이름이 지정되지만 더 많이 입력하면 ;-)
MyClass o = new MyClass(
new MyClass.A(a), new MyClass.B(b), new MyClass.C(c),
new MyClass.D(d), new MyClass.E(e), new MyClass.F(f),
new MyClass.G(g));
물론, 유형 이름 A, B, C당신이 매개 변수를 줘야 할 것 같은 ...하여 매개 변수, 종종 동일한 이름의 의미를 설명 자기 문서화 이름이어야합니다. 명명 된 인수 관용구와 비교할 때 필요한 구현이 훨씬 단순하므로 버그가 적을 가능성이 적습니다. 예를 들어 (Java-ish 구문 사용) :
class MyClass {
...
public static class A {
public final int value;
public A(int a) { value = a; }
}
...
}
컴파일러는 모든 인수가 제공되었음을 보장합니다. 빌더를 사용하면 누락 된 인수를 수동으로 확인하거나 상태 시스템을 호스트 언어 유형 시스템으로 인코딩해야합니다. 둘 다 버그를 포함 할 수 있습니다.
명명 된 인수를 시뮬레이션하는 또 다른 일반적인 방법이 있습니다. 인라인 클래스 구문을 사용하여 모든 필드를 초기화 하는 단일 추상 매개 변수 객체 입니다. 자바에서 :
MyClass o = new MyClass(new MyClass.Arguments(){{ argA = a; argB = b; argC = c; ... }});
class MyClass {
...
public static abstract class Arguments {
public int argA;
public String ArgB;
...
}
}
그러나 필드를 잊어 버릴 수 있으며 이것은 언어별로 솔루션입니다 (JavaScript, C # 및 C에서 사용되는 것을 보았습니다).
다행히도 생성자는 여전히 모든 인수의 유효성을 검사 할 수 있습니다. 개체가 부분적으로 구성된 상태로 생성 된 경우에는 그렇지 않으며 사용자가 setter 또는 init()메서드 를 통해 추가 인수를 제공 해야합니다. 코딩 노력이 가장 적게 들지만 올바른 프로그램 을 작성하기가 더 어렵습니다 .
따라서“ 명명되지 않은 많은 매개 변수로 인해 코드를 유지하기가 어려워집니다 ”를 해결하는 방법이 많이 있지만 다른 문제는 남아 있습니다.
예를 들어, 테스트 가능성 문제 단위 테스트를 작성할 때 테스트 데이터를 주입하고 외부 부작용이있는 종속성 및 작업을 조롱하기 위해 테스트 구현을 제공 할 수 있어야합니다. 생성자 내에서 클래스를 인스턴스화 할 때 그렇게 할 수 없습니다. 클래스의 책임이 다른 객체를 만드는 것이 아니라면 사소한 클래스를 인스턴스화해서는 안됩니다. 이것은 단일 책임 문제와 함께 진행됩니다. 수업의 책임에 초점을 맞출수록 테스트하기가 더 쉬워지고 사용하기가 더 쉽습니다.
가장 쉽고 가장 좋은 방법은 생성자가 완전하게 구성된 종속성을 매개 변수 로 취하는 것입니다. 그러나이 방법은 호출자가 종속성을 관리해야 할 책임이 있습니다. 도메인 모델에서 종속성이 독립 엔터티가 아닌 한 이상적이지는 않습니다.
때로는 (추상적 인) 팩토리 또는 완전 의존성 주입 프레임 워크 가 대신 사용되지만, 대부분의 경우에 과도하게 사용될 수 있습니다. 특히, 이러한 인수 중 다수가 유사 전역 객체이거나 객체 인스턴스화간에 변경되지 않는 구성 값인 경우에는 인수 개수 만 줄입니다. 예 매개 변수 경우 a와 d글로벌 틱을했다, 우리가 얻을 것
Dependencies deps = new Dependencies(a, d);
...
MyClass o = deps.newMyClass(b, c, e, f, g);
class MyClass {
MyClass(Dependencies deps, B b, C c, E e, F f, G g) {
this.depA = deps.newDepA(b, c);
this.depB = deps.newDepB(e, f);
this.g = g;
}
...
}
class Dependencies {
private A a;
private D d;
public Dependencies(A a, D d) { this.a = a; this.d = d; }
public DepA newDepA(B b, C c) { return new DepA(a, b, c); }
public DepB newDepB(E e, F f) { return new DepB(d, e, f); }
public MyClass newMyClass(B b, C c, E e, F f, G g) {
return new MyClass(deps, b, c, e, f, g);
}
}
응용 프로그램에 따라, 이것은 의존성 관리자가 모든 것을 제공 할 수 있기 때문에 팩토리 메소드가 거의 인수를 갖지 않는 게임 체인저 일 수도 있고, 명백한 이점없이 인스턴스화를 복잡하게하는 대량의 코드 일 수도 있습니다. 이러한 팩토리는 매개 변수 관리보다 콘크리트 유형에 인터페이스를 맵핑하는 데 더 유용합니다. 그러나이 방법은 매우 유창한 인터페이스로 숨기지 않고 너무 많은 매개 변수의 근본 문제를 해결하려고합니다.
개인 정보, 작업 정보 (각 고용 "명성"), 각 친구 등의 각 부분은 고유 한 개체로 변환되어야합니다.
업데이트 기능을 구현하는 방법을 고려하십시오. 사용자는 새로운 작업 기록 을 추가 하려고합니다 . 사용자는 정보의 다른 부분이나 이전 작업 기록을 변경하고 싶지 않습니다. 그대로 유지하십시오.
많은 정보가있을 때 한 번에 한 조각 씩 정보를 작성하는 것은 불가피합니다. 인간의 직관 (프로그래머가 사용하기 쉽도록) 또는 사용 패턴 (일반적으로 동시에 업데이트되는 정보)에 따라 논리적으로 그룹화 할 수 있습니다.
빌더 패턴은 유형이 지정된 인수 목록 (순서화 또는 비 순서화)을 캡처하는 방법 일 뿐이며 실제 생성자에 전달되거나 생성자가 빌더의 캡처 된 인수를 읽을 수 있습니다.
4의 지침은 단지 규칙입니다. 4 개 이상의 인수가 필요한 상황이 있으며이를 그룹화 할 수있는 건전하거나 논리적 인 방법이 없습니다. 이러한 경우 struct직접 또는 속성 설정기로 채울 수있는 파일 을 만드는 것이 좋습니다. 주목하십시오struct 이 경우 빌더는 매우 유사한 목적을 제공합니다.
그러나 귀하의 예에서는 그룹화하는 논리적 방법이 무엇인지 이미 설명했습니다. 이것이 사실이 아닌 상황에 처한 경우 다른 예를 들어 설명 할 수 있습니다.