인수 개수를 어떻게 낮게 유지하면서도 타사의 종속성을 개별적으로 유지합니까?

타사 라이브러리를 사용합니다. 그들은 우리의 의도와 목적을 위해 아마도 다음과 같이 구현 되는 POJO 를 전달 합니다.

public class OurData {
  private String foo;
  private String bar;
  private String baz;
  private String quux;
  // A lot more than this

  // IMPORTANT: NOTE THAT THIS IS A PACKAGE PRIVATE CONSTRUCTOR
  OurData(/* I don't know what they do */) {
    // some stuff
  }

  public String getFoo() {
    return foo;
  }

  // etc.
}

API 캡슐화 및 단위 테스트 촉진을 포함한 여러 가지 이유로 인해 데이터를 래핑하고 싶습니다. 그러나 핵심 클래스가 데이터에 의존하기를 원하지 않습니다 (다시 테스트 목적으로)! 그래서 지금 나는 이와 같은 것을 가지고 있습니다 :

public class DataTypeOne implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
  }
}

public class DataTypeTwo implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz, String quux) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
    this.quux = quux;
  }
}

그리고 이것은 :

public class ThirdPartyAdapter {
  public static makeMyData(OurData data) {
    if(data.getQuux() == null) {
      return new DataTypeOne(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
      );
    } else {
      return new DataTypeTwo(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
        data.getQuux();
      );
  }
}

이 어댑터 클래스는 타사 API에 대해 알아야하는 다른 몇 가지 클래스와 결합되어 내 시스템의 나머지 부분을 통해 퍼짐성을 제한합니다. 그러나 ...이 솔루션은 GROSS입니다! 클린 코드에서, 페이지 40 :

3 개 이상의 주장 (다항식)은 매우 특별한 타당성을 요구하므로 어쨌든 사용해서는 안됩니다.

내가 고려한 것들 :

• 정적 헬퍼 메소드가 아닌 팩토리 오브젝트 작성
  • bajillion 인수를 갖는 문제를 해결하지 못함
• 종속 생성자가있는 DataTypeOne 및 DataTypeTwo의 서브 클래스 작성
  • 여전히 polyadic protected 생성자가 있습니다
• 동일한 인터페이스를 따르는 완전히 별도의 구현을 만듭니다.
• 위의 여러 아이디어를 동시에

이 상황을 어떻게 처리해야합니까?

이것은 부패 방지 계층 상황 이 아닙니다 . API에는 아무런 문제가 없습니다. 문제는 다음과 같습니다.

• 내 데이터 구조를 원하지 않습니다 import com.third.party.library.SomeDataStructure;
• 테스트 사례에서 데이터 구조를 구성 할 수 없습니다
• 내 현재 솔루션은 매우 높은 인수 수를 초래합니다. 데이터 구조를 전달하지 않고 인수 수를 낮추고 싶습니다.
• 그 질문은 " 어떤 안티 손상 층인가?". 제 질문은 " 이 시나리오를 해결하기 위해 패턴, 패턴을 어떻게 사용할 수 있습니까?"입니다.

나는 코드를 요구하지 않고 (그렇지 않으면이 질문은 SO에있을 것입니다), 효과적으로 코드를 작성할 수 있도록 충분한 답변을 요구합니다 (그 질문은 제공하지 않습니다).

여러 초기화 매개 변수가있을 때 사용한 전략은 초기화 매개 변수 만 포함하는 형식을 만드는 것입니다.

public class DataTypeTwoParameters {
    public String foo;  // use getters/setters instead if it's appropriate
    public int bar;
    public double baz;
    public String quuz;
}

그런 다음 DataTypeTwo의 생성자는 DataTypeTwoParameters 객체를 가져오고 DataTypeTwo는 다음을 통해 구성됩니다.

DataTypeTwoParameters p = new DataTypeTwoParameters();
p.foo = "Hello";
p.bar = 4;
p.baz = 3;
p.quuz = "World";

DataTypeTwo dtt = new DataTypeTwo(p);

이를 통해 DataTypeTwo에 들어가는 모든 매개 변수와 그 의미를 명확하게 확인할 수 있습니다. 또한 DataTypeTwoParameters 생성자에서 적절한 기본값을 제공하여 설정해야하는 값만 API 소비자가 원하는 순서대로 수행 할 수 있습니다.

여기에는 API를 래핑하고 인수 수를 낮게 유지하는 두 가지 별도의 문제가 있습니다.

API를 래핑 할 때 요구 사항 외에는 아무것도 모르고 인터페이스를 처음부터 마치 디자인하는 것이 좋습니다. API에는 아무런 문제가 없다고 말한 다음 동일한 호흡 목록에 API에 대한 여러 가지 잘못된 점이 있습니다. 테스트 가능성, 구성 가능성, 한 객체에 너무 많은 매개 변수 등 원하는 API를 작성하십시오 . 하나가 아닌 여러 개체가 필요한 경우 그렇게하십시오. POJO 를 작성 하는 오브젝트에 한 레벨 높은 랩핑이 필요한 경우이를 수행하십시오.

그런 다음 원하는 API를 확보 한 후에는 매개 변수 수가 더 이상 문제가되지 않을 수 있습니다. 그렇다면, 고려해야 할 몇 가지 일반적인 패턴이 있습니다.

• Erik의 답변 과 같은 매개 변수 객체 .
• 빌더 패턴 별도의 빌더 객체를 생성 한 후 다음, 개별적으로 매개 변수를 설정 최종 객체를 생성하는 세터의 번호로 전화를 걸 수 있습니다.
• 필드가 이미 내부적으로 설정된 상태에서 원하는 객체의 서브 클래스를 복제 하는 프로토 타입 패턴
• 이미 익숙한 공장.
• 위의 일부 조합.

이러한 생성 패턴은 종종 polyadic 생성자를 호출하게되므로 캡슐화 할 때 괜찮은 것으로 간주해야합니다. polyadic 생성자의 문제는 한 번만 호출하는 것이 아니라 개체를 생성해야 할 때마다 호출해야하는 경우입니다.

일반적으로 OurData내부를 다시 구현하지 않고 객체에 대한 참조를 저장 하고 메서드 호출을 전달하여 기본 API로 전달하는 것이 훨씬 쉽고 유지 관리가 쉽습니다 . 예를 들면 다음과 같습니다.

public class DataTypeTwo implements DataInterface {
  private OurData data;

  public DataTypeOne(OurData data) {
    this.data = data;
  }

   public String getFoo() {
    return data.getFoo();
  }

  public int getBar() {
    return Integer.parseInt(data.getBar());
  }
  ...
}

나는 당신이 밥 삼촌의 권고를 너무 엄격하게 해석하고 있다고 생각합니다. 논리와 메소드, 생성자 등을 포함한 일반 클래스의 경우 다항식 생성자는 실제로 코드 냄새와 매우 흡사합니다. 그러나 엄격하게 필드를 노출하는 데이터 컨테이너이며 본질적으로 팩토리 객체 인 것으로 생성 된 것이라면 너무 나쁘지 않다고 생각합니다.

당신은 할 수 코멘트에 제안입니다 래퍼 해당 지역의 데이터 유형이 무엇인지 당신을 위해이 생성자 매개 변수, 포장 수, 매개 변수 개체 패턴을 사용 이미 , 본질적으로 매개 변수 개체를. 모든 Parameter 객체는 매개 변수를 포장하고 (어떻게 만들까요? polyadic 생성자를 사용합니까?) 두 번째 나중에 거의 동일한 객체에 포장을 풉니 다.

필드에 대한 setter를 노출하고 호출하지 않으려면 잘 정의되고 캡슐화 된 팩토리 내의 polyadic 생성자를 고수하는 것이 좋습니다.