그리고 어쩌면 내일 우리는 인스턴트화하기 위해 “노트북”이라고 말합시다의 또 다른 가족을 해야합니다. 따라서 UI는 사용자가 “서버”, “PC” 또는 “랩톱”을 원하는지 알 수 있는 “경우”를 갖지만, 공장 클래스는 정확히 어떤 서버, PC 또는 랩톱을 빌드할지 결정합니다(그리고 이를 조정하는 방법 – 매개 변수로 설정하거나 계약자에게 보낼 값). UI가 인식하지 못하는 많은 매개 변수입니다. 이 모든 것이 단일 팩토리 클래스에 너무 많이 있습니다. 실제 공장은 쉽게 생각할 수 있습니다 – 공장은 자동차, 컴퓨터 또는 TV와 같은 품목이 생산되는 어딘가에 있습니다. : 추상 팩터리 인터페이스는 클라이언트 코드가 다양한 유형의 UI 요소를 생성하는 데 사용할 수 있는 생성 메서드 집합을 선언합니다. 콘크리트 팩터리특정 운영 체제에 대응하고 특정 OS와 일치하는 UI 요소를 만듭니다. 콘크리트 공장은 콘크리트 제품을 인스턴스화하지만, 그들의 창조 방법의 서명은 해당 추상 제품을 반환해야합니다. 이렇게 하면 팩터리를 사용하는 클라이언트 코드가 팩터리에서 얻는 제품의 특정 변형에 결합되지 않습니다. 클라이언트는 추상 적 인터페이스를 통해 개체와 통신하는 한 모든 콘크리트 팩터리 /제품 변형으로 작업 할 수 있습니다. 기본 책임을 흐리게 하는 팩터리 메서드 집합이 있는 클래스가 있는 경우 추상 팩터리 구현을 고려 합니다. 잘 설계된 프로그램에서 각 클래스는 한 가지에 대한 책임이 있습니다.
클래스가 여러 제품 형식을 처리하는 경우 팩터리 메서드를 독립 실행형 팩터리 클래스 또는 본격적인 추상 팩터리 구현으로 추출하는 것이 좋습니다. 이 게시물은 간단한 예제와 함께 GOF 패턴 중 하나인 추상 팩터리 메서드의 요약 된 형식에 대해 이야기했습니다. 위에 제시된 모든 예제의 소스 코드는 GitHub에서 사용할 수 있습니다. 책 디자인 패턴: 재사용 가능한 개체 지향 소프트웨어의 요소는 추상 팩터리는 “구체적인 클래스를 지정하지 않고 관련 또는 종속 개체의 패밀리를 만들기 위한 인터페이스를 제공한다”고 명시합니다. 즉, 이 모델을 사용하면 일반적인 패턴을 따르는 개체를 만들 수 있습니다. Pankaj sir는 “추상 팩토리 패턴에서 if-else 블록을 제거하고 각 하위 클래스에 대한 팩터리 클래스를 가지고 입력 팩터리 클래스에 따라 하위 클래스를 반환하는 추상 팩터리 클래스가 있습니다.” 감마 등의 디자인 패턴에 따라 이 패턴의 의도는 다음과 같습니다: 이 구현이 추상 팩토리 패턴과 어떻게 관련되는지 에 대한 명확한 아이디어를 제공하기 위해, 여기에 방금 수행한 작업을 나타내는 클래스 다이어그램이 있습니다: 추상 공장 디자인에 오신 것을 환영합니다. 자바 예제의 패턴입니다. 추상 공장 디자인 패턴은 창조 패턴 중 하나입니다. 추상 공장 패턴은 공장의 공장과 더 유사하다는 사실을 제외하고는 공장 패턴과 거의 유사합니다. 예를 들어 여러 제품(예: createLetter() 및 createResume())를 만드는 인터페이스를 제공하는 추상적인 팩터리 클래스 DocumentCreator가 있습니다. 시스템에는 팬시문서 작성자 또는 ModernDocumentCreator와 같은 문서 작성기 클래스의 파생 된 구체적인 버전이 몇 개나 있으며, 각 버전마다 createLetter() 및 createResume()가 서로 다른 구현으로 해당 개체를 생성합니다. 팬시 레터 또는 현대 이력서처럼.
이러한 각 제품은 클라이언트가 알고 있는 Letter 또는 Resume와 같은 간단한 추상 클래스에서 파생됩니다. 클라이언트 코드는 DocumentCreator의 적절한 인스턴스를 얻고 공장 메서드를 호출합니다. 결과 개체의 각각은 동일한 DocumentCreator 구현에서 만들어지고 공통 테마를 공유합니다 (모두 멋진 또는 현대적인 개체일 것입니다).