직접 객체 생성 대신 팩토리 클래스를 사용해야하는 이유는 무엇입니까?

GitHub 및 CodePlex에서 여러 С # 및 Java 클래스 라이브러리 프로젝트의 역사를 보았으며 직접 객체 인스턴스화와는 반대로 팩토리 클래스로 전환하는 경향을 봅니다.

왜 팩토리 클래스를 광범위하게 사용해야합니까? 클래스의 공용 생성자를 호출하여 객체가 구식 방식으로 만들어지는 꽤 좋은 라이브러리가 있습니다. 마지막 커밋에서 저자는 수천 개의 클래스의 모든 공용 생성자를 내부로 신속하게 변경 CreateXXX했으며 클래스의 내부 생성자를 호출하여 새 객체를 반환하는 수천 개의 정적 메서드를 사용 하여 하나의 거대한 팩토리 클래스를 만들었습니다 . 외부 프로젝트 API가 제대로 작동하지 않습니다.

그러한 변화가 왜 유용한가? 이런 식으로 리팩토링의 요점은 무엇입니까? 퍼블릭 클래스 생성자에 대한 호출을 정적 팩토리 메소드 호출로 대체하면 어떤 이점이 있습니까?

언제 공개 생성자를 사용하고 언제 팩토리를 사용해야합니까?

팩토리 클래스는 종종 프로젝트가 SOLID 원칙을 더 밀접하게 따르도록하기 때문에 구현 됩니다. 특히, 인터페이스 분리 및 종속성 반전 원칙.

공장과 인터페이스는 훨씬 더 장기적인 유연성을 제공합니다. 이를 통해보다 분리 된 (따라서 더 테스트 가능한) 설계가 가능합니다. 이 경로를 따라갈 수있는 이유는 다음과 같습니다.

• IoC ( Inversion of Control ) 컨테이너를 쉽게 도입 할 수 있습니다.
• 인터페이스를 모의 할 수 있으므로 코드를보다 테스트 가능하게 만듭니다.
• 응용 프로그램을 변경해야 할 때 훨씬 더 많은 유연성을 제공합니다 (예 : 종속 코드를 변경하지 않고 새로운 구현을 만들 수 있음)

이 상황을 고려하십시오.

어셈블리 A (->는 다음에 따라 달라짐) :

Class A -> Class B
Class A -> Class C
Class B -> Class D

클래스 B를 어셈블리 A로 종속 된 어셈블리 B로 옮기고 싶습니다. 이러한 구체적인 종속성으로 전체 클래스 계층의 대부분을 가로 질러 이동해야합니다. 인터페이스를 사용하면 많은 고통을 피할 수 있습니다.

어셈블리 A :

Class A -> Interface IB
Class A -> Interface IC
Class B -> Interface IB
Class C -> Interface IC
Class B -> Interface ID
Class D -> Interface ID

이제 클래스 B를 고통없이 어셈블리 B로 옮길 수 있습니다. 여전히 어셈블리 A의 인터페이스에 따라 다릅니다.

IoC 컨테이너를 사용하여 종속성을 해결하면 훨씬 더 유연 해집니다. 클래스의 종속성을 변경할 때마다 생성자에 대한 각 호출을 업데이트 할 필요가 없습니다.

인터페이스 분리 원리와 의존성 역전 원리를 따르면 매우 유연하고 분리 된 애플리케이션을 구축 할 수 있습니다. 이러한 유형의 응용 프로그램 중 하나에서 작업 한 후에는 다시 new키워드 사용으로 돌아 가기를 원하지 않을 것 입니다.

마찬가지로 whatsisname가 말했다, 나는 이것이의 경우가 생각 화물 숭배의 소프트웨어 설계. 팩토리, 특히 추상 유형은 모듈이 클래스의 여러 인스턴스를 작성하고이 모듈의 사용자에게 작성할 유형을 지정할 수있는 기능을 제공하려는 경우에만 사용할 수 있습니다. 대부분의 경우 하나의 인스턴스 만 필요하고 명시 적 팩토리를 작성하는 대신 해당 인스턴스를 직접 전달할 수 있기 때문에이 요구 사항은 실제로 매우 드 rare니다.

문제는 팩토리 (및 싱글 톤)가 구현하기가 매우 쉬워 사람들이 필요하지 않은 곳에서도 많이 사용한다는 것입니다. 프로그래머가 "이 코드에서 어떤 디자인 패턴을 사용해야합니까?"라고 생각할 때 공장이 먼저 떠 오릅니다.

"어쩌면 언젠가는 클래스를 다르게 만들어야 할 것"을 염두에두고 많은 공장이 만들어졌습니다. 이것은 YAGNI 의 명백한 위반입니다 .

IoC는 일종의 공장이기 때문에 IoC 프레임 워크를 도입하면 공장이 더 이상 사용되지 않습니다. 그리고 많은 IoC 프레임 워크는 특정 팩토리의 구현을 만들 수 있습니다.

또한 CreateXXX생성자 만 호출하는 메서드 를 사용하여 거대한 정적 클래스를 만들라는 디자인 패턴이 없습니다 . 특히 팩토리 (또는 추상 팩토리)라고하지 않습니다.

팩토리 패턴 유행은 "새로운"키워드의 사용이 나쁘고 모든 비용을 피하거나 피해야한다는 "C 스타일"언어 (C / C ++, C #, Java)의 코더들 사이의 거의 독단적 인 믿음에서 비롯됩니다 중앙 집중식). 이는 단일 책임 원칙 (SOLID의 "S")과 종속성 반전 원칙 ( "D")에 대한 매우 엄격한 해석에서 비롯됩니다. 간단히 말해서, SRP는 코드 객체에는 "변경 사유"가 하나만 있어야하며 하나만 있어야합니다. "변경 이유"는 해당 객체의 중심적인 목적, 코드베이스에서의 "책임"및 코드 변경이 필요한 다른 것들은 해당 클래스 파일을 열지 않아도됩니다. DIP는 훨씬 더 단순합니다. 코드 객체는 다른 구체적인 객체에 의존해서는 안됩니다.

예를 들어, "new"및 public 생성자를 사용하여 호출 코드를 특정 구체적 클래스의 특정 생성 방법에 연결합니다. 이제 코드에서 MyFooObject 클래스가 존재하고 문자열과 int를 취하는 생성자가 있음을 알아야합니다. 생성자가 더 많은 정보를 필요로하는 경우, 현재 작성중인 정보를 포함하여 해당 정보를 전달하도록 생성자의 모든 사용법을 업데이트해야하므로 전달할 수있는 무언가가 있어야합니다. 그것을 얻기 위해 변경되거나 소비됩니다 (소비 객체에 더 많은 책임 추가). 또한 MyFooObject가 코드베이스에서 BetterFooObject로 바뀐 경우 이전 클래스 대신 새 오브젝트를 생성하도록 이전 클래스의 모든 사용법을 변경해야합니다.

따라서, MyFooObject의 모든 소비자는 MyFooObject를 포함한 클래스 구현 동작을 정의하는 "IFooObject"에 직접 의존해야합니다. 이제 IFooObjects 소비자는 IFooObject를 구성 할 수 없으며 (특정 구체적인 클래스가 필요하지 않은 IFooObject라는 지식이 없어도) IFooObject 구현 클래스 또는 메서드의 인스턴스를 제공 받아야합니다. 환경에서 올바른 IFooObject를 작성하는 방법을 아는 책임이있는 다른 오브젝트에 의해 외부에서, 일반적으로 팩토리라고합니다.

여기 이론이 현실과 만나는 곳이 있습니다. 항상 모든 유형의 변경에 개체를 닫을 수는 없습니다 . 예를 들어, IFooObject는 이제 코드베이스의 추가 코드 개체로, 소비자 또는 IFooObjects 구현에 필요한 인터페이스가 변경 될 때마다 변경되어야합니다. 이는이 추상화에서 객체가 서로 상호 작용하는 방식을 변경하는 것과 관련된 새로운 수준의 복잡성을 소개합니다. 또한 인터페이스 자체가 새로운 인터페이스로 교체되는 경우 소비자는 여전히 더 심층적으로 변화해야합니다.

좋은 코더는 설계를 분석하고 특정 방식으로 변경해야 할 장소를 찾아서 더 견딜 수 있도록 리팩토링하여 YAGNI ( "You Ai n't Gonna Need It")와 SOLID의 균형을 맞추는 방법을 알고 있습니다. 변화의 유형, 그 경우에 때문에 "당신이 있는 거 필요".

생성자는 짧고 간단한 코드를 포함하면 좋습니다.

초기화가 필드에 몇 가지 변수를 할당하는 것 이상이되면 팩토리가 적합합니다. 다음과 같은 이점이 있습니다.

• 길고 복잡한 코드는 전용 클래스 (공장)에서 더 의미가 있습니다. 많은 정적 메소드를 호출하는 생성자에 동일한 코드를 넣으면 기본 클래스가 오염됩니다.

• 일부 언어 및 경우 에 따라 생성자에서 예외를 발생시키는 것은 버그를 유발할 수 있기 때문에 정말 나쁜 생각 입니다.

• 생성자를 호출 할 때 호출자는 생성하려는 인스턴스의 정확한 유형을 알아야합니다. 이것은 항상 그런 것은 아닙니다 (로서 Feeder, 나는 Animal그것을 먹이기 위해 단지 구성해야 합니다. 나는 a Dog인지 a 인지 상관하지 않습니다 Cat).

인터페이스를 사용하는 경우 실제 구현과 독립적으로 유지할 수 있습니다. 팩토리는 (속성, 매개 변수 또는 다른 방법을 통해) 여러 가지 다른 구현 중 하나를 인스턴스화하도록 구성 할 수 있습니다.

간단한 예 : 장치와 통신하고 싶지만 이더넷, COM 또는 USB를 통한 장치인지는 모릅니다. 하나의 인터페이스와 3 개의 구현을 정의합니다. 런타임에 원하는 메소드를 선택하면 팩토리가 적절한 구현을 제공합니다.

자주 사용하십시오 ...

Java / C #의 모듈 시스템에서 제한 사항의 증상입니다.

원칙적으로 동일한 생성자와 메소드 서명을 사용하여 클래스의 구현을 다른 구현으로 교체 할 수없는 이유는 없습니다. 가 있습니다 이 허용 언어. 그러나 Java와 C #은 모든 클래스에 고유 식별자 (정규화 된 이름)가 있으며 클라이언트 코드는 하드 코딩 된 종속성으로 끝납니다.

당신은 할 수 종류의 파일 시스템과 컴파일러 옵션 즉, 그래서 손보는에 의해이 문제를 해결받을 com.example.Foo다른 파일에 매핑, 그러나 이것은 놀랍고 직관적이다. 그렇게해도 코드는 여전히 하나의 클래스 구현에만 연결됩니다. 즉, 클래스 Foo에 의존 하는 클래스를 작성하는 경우 컴파일 타임에 MySet구현을 선택할 수 MySet있지만 Foo의 두 가지 다른 구현을 사용하여 인스턴스를 생성 할 수는 없습니다 MySet.

이 불행한 디자인 결정은 사람들 interface이 나중에 다른 구현이 필요하거나 단위 테스트를 용이하게 할 가능성에 대비하여 코드를 미래에 대비 하기 위해 불필요하게 사용하도록 강요 합니다. 이것이 항상 실현 가능한 것은 아닙니다. 클래스의 두 인스턴스의 개인 필드를 보는 메소드가 있으면 인터페이스에서 구현할 수 없습니다. 예를 들어 unionJava Set인터페이스에 표시되지 않는 이유 가 여기에 있습니다. 여전히 숫자 유형 및 컬렉션 외부에서는 이진 방법이 일반적이지 않으므로 일반적으로이 방법을 사용할 수 있습니다.

물론 호출 new Foo(...)하면 여전히 클래스 에 대한 종속성이 있으므로 클래스 가 인터페이스를 직접 인스턴스화하려면 팩토리가 필요합니다. 그러나 일반적으로 생성자에서 인스턴스를 수락하고 다른 사람이 사용할 구현을 결정하도록하는 것이 좋습니다.

인터페이스와 팩토리로 코드베이스를 부 풀릴 가치가 있는지 결정하는 것은 당신에게 달려 있습니다. 한편으로 문제의 클래스가 코드베이스 내부에있는 경우 나중에 다른 클래스 나 인터페이스를 사용하도록 코드를 리팩토링하는 것은 쉽지 않습니다. 상황이 발생하면 YAGNI를 호출 하고 나중에 리팩터링 할 수 있습니다. 그러나 클래스가 게시 한 라이브러리의 공개 API의 일부인 경우 클라이언트 코드를 수정할 수있는 옵션이 없습니다. 사용하지 않고 interface나중에 여러 구현이 필요한 경우, 바위와 어려운 장소 사이에 갇힐 것입니다.

내 생각에, 그들은 단순한 팩토리를 사용하고 있는데, 이는 적절한 디자인 패턴이 아니며 Abstract Factory 또는 Factory Method와 혼동해서는 안됩니다.

그리고 그들은 "수천 개의 CreateXXX 정적 메소드를 가진 거대한 패브릭 클래스"를 만들었으므로 안티 패턴 (하나님 클래스 일 수도 있습니다)으로 들립니다.

외부 팩토리가 필요없는 Simple Factory 및 정적 작성자 메소드는 경우에 따라 유용 할 수 있다고 생각합니다. 예를 들어, 물체의 구성이 다른 물체를 인스 턴싱하는 것과 같은 다양한 단계를 요구할 때 (예를 들어, 구성 선호).

나는 그것을 Factory라고 부르지 않을 것이지만 접미사 "Factory"로 임의의 클래스에 캡슐화 된 많은 메소드 만 있습니다.

라이브러리의 사용자로서 라이브러리에 팩토리 메소드가있는 경우이를 사용해야합니다. 팩토리 메소드는 라이브러리 작성자에게 코드에 영향을주지 않고 특정 변경을 수행 할 수있는 유연성을 제공한다고 가정합니다. 예를 들어 팩토리 메소드에서 일부 서브 클래스의 인스턴스를 리턴 할 수 있습니다. 이는 간단한 생성자와는 작동하지 않습니다.

라이브러리의 작성자는 유연성을 직접 사용하려면 팩토리 메소드를 사용합니다.

설명하는 경우 생성자를 팩토리 메소드로 바꾸는 것이 의미가 없다는 느낌이들 것입니다. 그것은 모든 관련자들에게 분명 고통이었다. 라이브러리는 특별한 이유없이 API에서 아무것도 제거해서는 안됩니다. 따라서 팩토리 메소드를 추가했다면 팩토리 메소드가 더 이상 해당 생성자를 호출하지 않고 일반 생성자를 사용하는 코드 가 제대로 작동하지 않을 때까지 기존 생성자를 사용할 수 있습니다 . 당신의 인상은 아주 옳을 것입니다.

이것은 스칼라 시대와 함수형 프로그래밍 시대에는 쓸모없는 것으로 보입니다. 기능의 탄탄한 기초는 gazillion 클래스를 대체합니다.

또한 {{팩토리를 사용할 때 Java의 double 이 더 이상 작동하지 않습니다.

someFunction(new someObject() {{
    setSomeParam(...);
    etc..
}})

익명 클래스를 만들고 사용자 지정할 수 있습니다.

시공간 딜레마에서 시공간의 축소를 가능하게하는 기능적 프로그래밍, 즉 코드 크기가 이제는 실용적 프로그래밍 인 고속 CPU 덕분에시 간이 훨씬 줄어 듭니다.