정적 팩토리 vs 싱글 톤 팩토리

내 코드 중 일부에는 다음과 비슷한 정적 팩토리가 있습니다.

public class SomeFactory {

    // Static class
    private SomeFactory() {...}

    public static Foo createFoo() {...}

    public static Foo createFooerFoo() {...}
}

코드 검토 중에 싱글 톤이어야하고 주입되어야한다고 제안되었습니다. 따라서 다음과 같아야합니다.

public class SomeFactory {

    public SomeFactory() {}

    public Foo createFoo() {...}

    public Foo createFooerFoo() {...}
}

몇 가지 강조 할 사항 :

두 공장 모두 무국적자입니다.
메소드 간의 유일한 차이점은 해당 범위 (인스턴스 대 정적)입니다. 구현은 동일합니다.
Foo는 인터페이스가없는 빈입니다.

내가 정적으로가는 논쟁은 다음과 같습니다.

클래스는 상태가 없으므로 인스턴스화 할 필요가 없습니다.
팩토리를 인스턴스화하는 것보다 정적 메소드를 호출하는 것이 더 자연스러운 것 같습니다.

싱글 톤으로서의 팩토리에 대한 논쟁은

모든 것을 주입하는 것이 좋습니다
공장의 무국적 상태에도 불구하고 주입으로 테스트하기가 더 쉽습니다 (조롱하기 쉬움).
소비자를 테스트 할 때 조롱해야합니다.

싱글 톤 방식에는 심각한 문제가 있습니다. 왜냐하면 정적 인 방법이 없다는 것을 암시하는 것 같습니다. 또한 StringUtils랩핑 및 주입과 같은 유틸리티 는 어리석은 것처럼 보입니다. 마지막으로, 언젠가는 공장을 조롱해야한다는 것을 의미합니다. 언제 공장을 조롱해야하는지 생각할 수 없습니다.

커뮤니티는 어떻게 생각합니까? 나는 싱글 톤 접근법을 좋아하지 않지만 그것에 대해 굉장히 강력한 논쟁은하지 않는 것 같습니다.

— bstempi
소스

공장에서 무언가를 사용하고 있습니다 . 그 사실 을 테스트하려면 공장의 모형을 제공해야합니다. 공장을 조롱하지 않으면 버그로 인해 실패했을 때 단위 테스트에 실패 할 수 있습니다.

— Mike

그렇다면 일반적인 정적 유틸리티 또는 정적 팩토리를 반대하고 있습니까?

— bstempi

나는 그들을 일반적으로 반대하고 있습니다. 예를 들어 C #에서 DateTimeand File클래스는 정확히 같은 이유로 테스트하기가 어렵습니다. 예를 들어 생성자에서 Created날짜를 설정하는 클래스가있는 경우 DateTime.Now5 분 간격으로 생성 된이 두 개체로 단위 테스트를 작성하는 방법은 무엇입니까? 몇 년 떨어져 있습니까? 당신은 정말로 (많은 일없이) 그렇게 할 수 없습니다.

— Mike

싱글 톤 팩토리에 private생성자와 getInstance()메소드 가 없어야 합니까? 죄송합니다, 엄밀한 nit-picker!

— TMN

@Mike-Agreed-DateTime.Now를 간단하게 반환하는 DateTimeProvider 클래스를 자주 사용했습니다. 그런 다음 테스트에서 미리 결정된 시간을 반환하는 모형으로 바꿀 수 있습니다. 추가 작업은 모든 생성자에 전달된다 - 동료가 그것을 100 %를 구입 :) ... 게으름에서 DateTime.Now에 명시 적 참조를 미끄러하지 않을 때 가장 큰 두통이

— 줄리아 헤이워드

답변:

팩토리를 생성 한 객체 유형과 팩토리를 분리하는 이유는 무엇입니까?

public class Foo {

    // Private constructor
    private Foo(...) {...}

    public static Foo of(...) { return new Foo(...); }
}

이것이 Joshua Bloch가 자신의 저서 "Effective Java"의 5 페이지에있는 항목 1로 묘사 한 것입니다. 자바는 추가 클래스와 싱글 톤을 추가하지 않고도 충분히 장황합니다. 별도의 팩토리 클래스가 의미가있는 경우가 있지만 그 사이는 거의 없습니다.

Joshua Bloch의 항목 1을 바꾸어 말하면 생성자와 달리 정적 팩토리 메소드는 다음을 수행 할 수 있습니다.

특정 종류의 객체 생성을 설명 할 수있는 이름을가집니다 (Bloch는 probablePrime (int, int, Random)을 예로 사용합니다)
기존 객체 반환 (생각 : 플라이급)
원래 클래스의 하위 유형 또는 구현하는 인터페이스를 반환
상세도 감소 (유형 매개 변수 지정)-예를 들어 Bloch 참조

단점 :

public 또는 protected 생성자가없는 클래스는 서브 클래 싱 할 수 없습니다 (그러나 보호 된 생성자 및 / 또는 항목 16 : 상속보다 구성 선호)
정적 팩토리 메소드는 다른 정적 메소드와 차별화되지 않습니다 (of () 또는 valueOf ()와 같은 표준 이름 사용)

실제로 Bloch의 책을 코드 검토 자에게 가져 가서 두 사람이 Bloch의 스타일에 동의 할 수 있는지 확인해야합니다.

— 글렌 피터슨
소스

나도 이것에 대해 생각했고, 나는 그것을 좋아한다고 생각합니다. 왜 처음에 그것들을 분리했는지는 기억 나지 않습니다.

— bstempi

일반적으로 Bloch의 스타일에 동의합니다. 궁극적으로 팩토리 메소드를 인스턴스화하는 클래스로 옮길 것입니다. 우리 솔루션과 귀하의 유일한 차이점은 생성자가 공개적으로 유지되어 사람들이 클래스를 직접 인스턴스화 할 수 있다는 것입니다. 답변 주셔서 감사합니다!

— bstempi

그러나 ... 끔찍하다. IFoo를 구현하고 전달한 클래스를 원할 것입니다.이 패턴을 사용하면 더 이상 불가능합니다. 인스턴스를 얻으려면 Foo를 의미하도록 IFoo를 하드 코딩해야합니다. IFoo create ()가 포함 된 IFooFactory가있는 경우 클라이언트 코드는 IFoo로 선택된 콘크리트 Foo의 구현 세부 사항을 알 필요가 없습니다.

— Wilbert

@ 윌버 트 public static IFoo of(...) { return new Foo(...); } 문제가 무엇입니까? Bloch는이 디자인의 장점 중 하나 (위의 두 번째 글 머리 기호)로 사용자의 관심사를 만족시키는 목록을 표시합니다. 나는 당신의 의견을 이해해서는 안됩니다.

— GlenPeterson

인스턴스를 만들려면이 디자인에 Foo.of (...)가 필요합니다. 그러나 Foo의 존재는 절대 노출되어서는 안되며 IFoo 만 알고 있어야합니다 (Foo는 IFoo 의 구체적인 의미이므로). 구체적인 impl에 정적 팩토리 메소드를 사용하면이 문제가 발생하여 클라이언트 코드와 구체적인 구현이 연결됩니다.

— Wilbert

내 머리 꼭대기에서 자바의 정적 문제는 다음과 같습니다.

정적 메소드는 OOP "규칙"에 의해 작동하지 않습니다. 클래스가 특정 정적 메소드를 구현하도록 강요 할 수는 없습니다 (내가 아는 한). 따라서 동일한 서명으로 동일한 정적 메소드 세트를 구현하는 여러 클래스를 가질 수 없습니다. 그래서 당신 은 당신이하고있는 일 중 하나 에 붙어 있습니다. 정적 클래스도 서브 클래 싱 할 수 없습니다. 따라서 다형성 등은 없습니다.
방법은 객체되지 않기 때문에, (코딩 보일러의 톤을하지 않고) 정적 방법은 주위에 전달 될 수 없습니다 그들은 사용할 수 없습니다 제외하고 클라이언트 코드를 높게 만드는 - 그들에게 하드가 링크입니다 코드 결합. (공평하게, 이것은 단지 정적 오류의 문제는 아닙니다).
스태틱 필드는 글로벌과 매우 유사합니다

당신은 언급했다 :

싱글 톤 방식에는 심각한 문제가 있습니다. 왜냐하면 메소드가 정적이어야한다고 제안하기 때문입니다. 또한 StringUtils와 같은 유틸리티를 래핑하고 주입해야한다고 제안하는 것 같습니다. 마지막으로, 언젠가는 공장을 조롱해야한다는 것을 의미합니다. 언제 공장을 조롱해야하는지 생각할 수 없습니다.

궁금한 점이 있습니다.

당신의 의견으로는 정적 메소드의 장점은 무엇입니까?
이것이 StringUtils올바르게 설계되고 구현 되었다고 생각 하십니까?
왜 공장을 조롱 할 필요가 없다고 생각하십니까?

답변 감사합니다! 요청한 순서대로 : (1) 정적 메소드의 장점은 구문 설탕과 불필요한 인스턴스가 없다는 것입니다. 정적 임포트가있는 코드를 읽고 Foo f = createFoo();명명 된 인스턴스를 갖는 것 보다는 비슷한 것을 말하는 것이 좋습니다. 인스턴스 자체는 유틸리티를 제공하지 않습니다. (2) 그렇게 생각합니다. 그것은 많은 방법들이 String클래스 내에 존재하지 않는다는 사실을 극복하도록 설계되었습니다 . String옵션이 아닌 기본으로 대체하는 것이 utils가가는 길입니다. (계속)

— bstempi

그것들은 사용하기 쉽고 인스턴스를 돌보지 않아도됩니다. 그들은 자연 스럽습니다. (3) 내 공장은 공장 방법과 매우 유사하기 때문 Integer입니다. 그것들은 매우 간단하고 논리가 거의 없으며 편의를 제공하기 위해서만 있습니다 (예를 들어 다른 OO 이유는 없습니다). 내 주장의 주요 부분은 상태에 의존하지 않는다는 것입니다. 테스트 중에 분리 할 이유가 없습니다. 사람들은 StringUtils테스트 할 때 조롱하지 않습니다. 왜이 간단한 편의 공장을 조롱해야합니까?

— bstempi

그것들은 StringUtils방법에 부작용이 없다는 합리적인 확신이 있기 때문에 조롱 하지 않습니다.

— Robert Harvey

@RobertHarvey 나는 내 공장에 대해 같은 주장을하고 있다고 가정합니다. 아무것도 수정하지 않습니다. StringUtils입력을 변경하지 않고 결과를 반환하는 것처럼 내 공장도 아무것도 수정하지 않습니다.

— bstempi

@bstempi 나는 거기에 약간의 Socratic 방법을 가고 있었다. 나는 그것을 빨아 것 같아요.

나는 당신이 만들고있는 응용 프로그램이 상당히 복잡하지 않아야하거나 그렇지 않으면 라이프 사이클의 초기 단계라고 생각합니다. 정적 문제가 아직 발생하지 않은 다른 시나리오는 팩토리에 대해 알고있는 코드의 다른 부분을 한두 곳으로 제한하는 것입니다.

응용 프로그램이 진화하고 어떤 경우에는 FooBar(Foo의 하위 클래스) 를 생성해야한다고 상상해보십시오 . 지금 당신은 당신에 대해 알고 코드에서 모든 장소를 이동해야 SomeFactory논리가에서 보이는 어떤 종류의 쓰기 someCondition및 전화 SomeFactory또는 SomeOtherFactory. 실제로 예제 코드를 보면 그보다 나쁩니다. 다른 Foos를 생성하기 위해 메소드 뒤에 메소드를 추가 할 계획이며 모든 클라이언트 코드는 어떤 Foo를 만들어야하는지 파악하기 전에 조건을 확인해야합니다. 즉, 모든 고객은 공장이 어떻게 작동하는지에 대한 친밀한 지식이 필요하며 새로운 Foo가 필요하거나 제거 될 때마다 변경해야합니다.

당신이 방금 만든 경우 이제 상상 IFooFactory를 만드는을 IFoo. 이제, 다른 서브 클래스를 만들거나 완전히 다른 구현을하는 것은 어린이의 놀이입니다. 당신은 체인에 더 높은 IFooFactory를 공급 한 다음 클라이언트가 그것을 받으면 gimmeAFoo()올바른 팩토리를 얻었으므로 올바른 foo를 얻습니다. .

프로덕션 코드에서 이것이 어떻게 작동하는지 궁금 할 것입니다. 1 년이 넘는 기간 동안 프로젝트를 완료 한 후 레벨 업을 시작하는 코드베이스에서 하나의 예를 제공하기 위해 질문 데이터 개체를 만드는 데 사용되는 팩토리가 많이 있습니다 ( 프레젠테이션 모델 과 같은 것). ). 나는 QuestionFactoryMap기본적으로 언제 사용할 질문 팩토리를 찾는 해시입니다. 다른 질문을하는 응용 프로그램을 만들기 위해지도에 다른 팩토리를 넣었습니다.

질문은 지침 또는 연습 (모두 구현 IContentBlock)에 표시 될 수 있으므로 각각 InstructionsFactory또는 ExerciseFactoryQuestionFactoryMap의 사본을 얻습니다. 그런 다음 다양한 지침 및 연습 팩토리 ContentBlockBuilder를 사용하여 언제 사용할 해시를 다시 유지합니다. 그런 다음 XML 이로 드되면 ContentBlockBuilder가 해시에서 Exercise 또는 Instructions Factory를 호출하여에 요청 createContent()한 다음 Factory는 질문을 기반으로 내부 QuestionFactoryMap에서 꺼내는 모든 것에 위임합니다. 각 XML 노드와 해시에 있습니다. 불행히도 , 그 것은BaseQuestion 대신의IQuestion하지만 디자인에주의를 기울이더라도 실수를 저지르는 실수를 저지를 수 있음을 보여줍니다.

당신의 직감은 이러한 정체가 당신을 해칠 것이라고 말하고 있으며, 당신의 직감을 뒷받침하는 문헌 이 확실히 많이 있습니다. 단위 테스트에만 사용하는 의존성 주입을 사용하면 결코 잃지 않을 것입니다 (좋은 코드를 작성하면 더 이상 사용하지 않을 것이라고 생각하지는 않습니다). 코드를 빠르고 쉽게 수정할 수 있습니다. 왜 거기에 가나 요?

— 에이미 담요
소스

Integer클래스 에서 팩토리 메소드의 순간을 생각해보십시오 . 문자열에서 변환하는 것과 같은 간단한 것입니다. 그게 뭐야 Foo. My Foo는 확장되어서는 안됩니다 (이 내용을 명시하지 않은 내 잘못). 나는 당신의 다형성 문제가 없습니다. 나는 다형성 공장을 갖는 것의 가치를 이해하고 과거에 그것들을 사용했습니다 ... 나는 그들이 여기에 적합하다고 생각하지 않습니다. Integer현재 정적 팩토리를 통해 시작된 간단한 작업을 수행하기 위해 팩토리를 인스턴스화해야한다고 상상할 수 있습니까?

— bstempi

또한 응용 프로그램에 대한 가정은 꽤 벗어났습니다. 응용 프로그램이 상당히 관련되어 있습니다. Foo그러나 이것은 많은 클래스보다 훨씬 간단합니다. 단순한 POJO 일뿐입니다.

— bstempi

Foo를 확장하려는 경우 Factory가 인스턴스가되는 이유가 있습니다 if (this) then {makeThisFoo()} else {makeThatFoo()}. 코드를 통해 모두 호출하는 대신 올바른 서브 클래스를 제공하기 위해 올바른 팩토리 인스턴스를 제공 하십시오. 만성적으로 나쁜 구조를 가진 사람들에 대해 내가 알아 차린 한 가지는 만성 통증이있는 사람들과 같다는 것입니다. 그들은 실제로 고통받지 않는 느낌을 알지 못하기 때문에 그들이 겪는 고통이 그렇게 나쁘지 않은 것처럼 보입니다.

— Amy Blankenship

또한 정적 방법 (수학 방법조차도!)의 문제에 대한 이 링크 를 확인하고 싶을 수도 있습니다.

— Amy Blankenship

질문을 업데이트했습니다. 당신과 다른 사람이 확장을 언급했습니다 Foo. 당연히-나는 그것을 최종 선언하지 않았다. Foo확장되지 않는 콩입니다.

— bstempi