정적 작성 방법-생성자와 비교 한 장단점

생성자에 대한 정적 객체 생성 방법의 장단점은 무엇입니까?

class Foo {
  private Foo(object arg) { }

  public static Foo Create(object arg) {
    if (!ValidateParam(arg)) { return null; }
    return new Foo(arg);
  }
}

내가 생각할 수있는 사람은 거의 없다.

장점 :

예외를 던지는 대신 null을 반환하십시오 (name TryCreate). 이렇게하면 클라이언트 쪽에서 코드를 더 간결하고 깨끗하게 만들 수 있습니다. 클라이언트는 생성자가 실패 할 것으로 거의 예상하지 않습니다.
명확한 의미, 예와 다른 종류의 객체 생성 CreatFromName(String name)및CreateFromCsvLine(String csvLine)
필요한 경우 캐시 된 객체 또는 파생 된 구현을 반환 할 수 있습니다.

단점 :

덜 알아볼 수 있고 코드를 탈지하기가 더 어렵습니다.
직렬화 또는 반사와 같은 일부 패턴 (예 : 더 어렵습니다 Activator<Foo>.CreateInstance())

design-patterns

— dbkk
소스

더 느립니다. 어쨌든 null 참조를 처리해야합니다.

— Amir Rezaei

@Amir 처리 null은 ( Foo x = Foo.TryCreate(); if (x == null) { ... })입니다. ctor 예외 처리는 ( Foo x; try { x = new Foo(); } catch (SomeException e) { ... })입니다. 일반적인 메소드를 호출 할 때 오류 코드보다 예외를 선호하지만 객체 생성시 TryCreate더 깨끗해 보입니다.

— dbkk

유효성 검사에서 유형 검사를 수행 하시겠습니까?

— Amir Rezaei

두 번째 프로에 관해서, "명확한 의미와 다른 종류의 객체를 생성, 예를 들어 CreatFromName (문자열 이름)과 CreateFromCsvLine (문자열 csvLine)는"당신이 만들 더 좋을 수 Name및 CsvLine유형보다는 명시 적 요구 사항 메소드 이름을 통해. 이렇게하면 Create를 오버로드 할 수 있습니다. 두 가지 모두에 문자열을 사용하는 것은 "원시적 인 집착"으로 간주 될 수 있습니다 (알려진 성능상의 이유로이 선택을하지 않았다고 가정). 재미있는 방법으로 Object Calisthenics 를 확인하십시오 .

— bentayloruk

답변:

정적 ' 제작자 ' 의 가장 큰 단점 은 아마도 상속을 제한하는 것입니다. 당신이나 당신의 라이브러리의 사용자가에서 클래스를 파생하는 경우 Foo, 다음 Foo::Create()거의 쓸모가된다. 거기에 정의 된 모든 논리는 상속 된 상태에서 다시 작성해야합니다 Create().

나는 타협을 제안한다 : 결코 실패 / 던지지 않는 사소한 객체 초기화 로직으로 생성자를 정의 한 다음 캐싱, 대체 구성 등으로 생성자를 정의하십시오. .

— 모주 바
소스

실제로 대부분의 클래스는 상속되지 않도록 설계되어 봉인 / 최종화되어야하기 때문에 실제로는 문제가되지 않습니다. 나중에 클래스를 상속까지 열어보고 싶다면 초기화 로직을 보호 생성자로 이동할 수 있습니다.

— Doval

작성은 팩토리 메소드입니다. 필자가 필요하다고 느끼면 팩토리 패턴을 구현하고, 객체 생성 계약뿐만 아니라 구현 클래스를 나타내는 인터페이스를 정의하여 필요한 곳에 주입합니다. 이것은 생성 책임을 클래스 밖으로 이동시키는 이점을 유지하지만 클래스 생성자 외부에서 오브젝트 생성을 수행하는 한계를 피합니다.

— 퀀틴-스타 인
소스