[design-patterns] 추상 공장 디자인 패턴이 필요한 이유는 무엇입니까?

대부분의 정의는 다음과 같이 말합니다.

추상 팩토리는 구체적인 클래스를 지정하지 않고 관련 객체의 패밀리를 생성하기위한 인터페이스를 제공합니다.

구체적인 클래스 자체의 객체를 생성하여 작업을 수행 할 수 있으므로 Abstract Factory Pattern의 용도는 무엇입니까? Concrete 클래스의 객체를 생성하는 팩토리 메소드가있는 이유는 무엇입니까?

abstractFactory 패턴을 구현해야하는 실제 예제를 제공 해주세요.



답변


답변

Abstract Factory 패턴 사용에 대한 실제 사례는 두 가지 다른 데이터 소스에 대한 데이터 액세스를 제공하는 것입니다. 애플리케이션이 다른 데이터 저장소를 지원한다고 가정합니다. (예 : SQL 데이터베이스 및 XML 파일). 당신은 두 개의 서로 다른 데이터 액세스 인터페이스가를 예 가지고 IReadableStoreIWritableStore관계없이 사용되는 데이터 소스 유형의 응용 프로그램에서 예상되는 일반적인 방법을 정의.

어떤 유형의 데이터 소스를 사용하더라도 클라이언트 코드가 데이터 액세스 클래스를 검색하는 방식을 변경해서는 안됩니다. 귀하는 AbstractDataAccessFactory데이터 소스의 종류가 구성된 알고 및 제공 콘크리트 공장을 클라이언트 코드, 즉 SqlDataAccessFactoryXmlDataAccessFactory. 이러한 콘크리트 팩토리는 구체적인 구현을 만들 수 있습니다 (예 : SqlReadableStoreSqlWriteableStore.

.NET Framework 의 DbProviderFactory 가이 패턴의 예입니다.


답변

내가 당신을 옳게 이해한다면-질문은 왜 우리가 Factory 메서드와 추상 팩토리 패턴을 모두 가지고 있는가입니다. 다른 다형성 클래스가 다른 인스턴스화 절차를 가질 때 추상 팩토리가 필요합니다. 그리고 어떤 모듈이 객체 초기화의 세부 사항을 알지 못해도 인스턴스를 만들고 사용하기를 원합니다. 예를 들어, 일부 계산을 수행하는 Java 객체를 생성하려고합니다. 그러나 그들 중 일부는 응용 프로그램의 일부이며 다른 바이트 코드는 DB에서 읽어야합니다. 다른 한편, 왜 우리는 공장 방법이 필요한가? 그 추상적 인 공장이 그것과 겹치는 것에 동의하십시오. 그러나 어떤 경우에는 작성하는 코드가 훨씬 적고 클래스와 인터페이스가 적 으면 시스템을 더 쉽게 이해할 수 있습니다.


답변

구체적인 클래스 자체의 객체를 생성하여 작업을 수행 할 수 있으므로 Abstract Factory Pattern의 용도는 무엇입니까? Concrete 클래스의 객체를 생성하는 팩토리 메소드가있는 이유는 무엇입니까?

Abstract Factory가 없는 경우 Client는 구체적인 클래스의 세부 사항을 알아야합니다. 이 긴밀한 결합은 Abstract Factory 에서 제거되었습니다 .

이제 Factory Method 는 클라이언트가 사용해야하는 계약을 노출합니다. Factory Method에 의해 노출 된 인터페이스를 구현하는 신제품을 추가하여 공장에 더 많은 제품을 추가 할 수 있습니다.

더 나은 이해를 위해 다음과 같은 관련 SE 질문을 참조하십시오.

팩토리 패턴과 추상 팩토리 패턴의 기본적인 차이점은 무엇입니까?

의지:

구체적인 클래스를 지정하지 않고 관련되거나 종속 된 개체의 패밀리를 만들기위한 인터페이스를 제공합니다.

당신은 이해할 수있다 소스 작성 기사에서 Abstract Factory 패턴의 의도, 구조, 체크리스트 및 경험 규칙을.

체크리스트 :

  1. 플랫폼 독립성 및 생성 서비스가 현재 고통의 원인 인지 결정합니다 .
  2. 매트릭스를 매핑 플랫폼제품 .
  3. 제품 별 팩토리 메소드로 구성된 팩토리 인터페이스 를 정의하십시오 .
  4. 새 연산자에 대한 모든 참조를 캡슐화하는 각 플랫폼에 대한 팩토리 파생 클래스를 정의합니다 .
  5. 클라이언트는 새에 대한 모든 참조를 은퇴하고 사용해야 팩토리 메소드를 작성하기 위해 제품 객체.

답변

Abstract Factory는 코드 기반을 통합하면서 여러 플랫폼을 지원하는 데 적합합니다. Windows, Linux 및 OSX에서 실행하려는 대형 Qt 또는 GTK + 또는 .NET / Mono 프로그램이 있다고 가정합니다. 그러나 각 플랫폼에서 다른 방식으로 구현되는 기능이 있습니다 (아마도 kernel32 API 또는 POSIX 기능을 통해).

public abstract class Feature
{
    public abstract int PlatformSpecificValue { get; }

    public static Feature PlatformFeature
    {
        get
        {
            string platform;
            // do platform detection here
            if (platform == "Win32")
                return new Win32Feature();
            if (platform == "POSIX")
                return new POSIXFeature();
        }
    }

    // platform overrides omitted
}

이 Abstract Factory를 사용하면 UI가 현재 플랫폼에 대해 알 필요가 없습니다.

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);


답변

디자인 패턴을 보면 거의 모든 패턴이 중복 될 수 있습니다. 그러나 어떤 패턴이 유사한 유형의 문제에 대한 솔루션을 위해 일반적으로 사용되는 접근 방식을 의미하는지. 디자인 패턴은 유사한 유형의 디자인 문제에 대한 디자인 수준 접근 방식 또는 솔루션을 제공합니다. 디자인 패턴을 사용하면 문제를 해결하고 더 빨리 제공 할 수 있습니다.


답변

추상화와 함께 작동하는 코드가 있다는 것을 쉽게 이미징 할 수 있으므로 구체적인 클래스가 아닌 추상화를 만들어야합니다.

코드를 더 잘 수정할 수 있으므로 항상 추상화에 대해 작업해야합니다.

이것은 좋은 예입니다 :
http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.23