디자인 패턴 | 추상 공장 패턴

1 | 추상 팩토리 패턴 개요

1.1 기본 아이디어

팩토리 메소드 패턴은 팩토리 계층 구조를 도입하여 단순한 팩토리 패턴에서 팩토리 클래스의 너무 무거운 책임 문제를 해결합니다. 그러나 팩토리 메소드 패턴의 각 특정 팩토리에는 오버로드 된 팩토리 메소드 세트가 하나만 있기 때문에 이러한 종류의 제품은 시스템에 많은 공장을 만들 수 있으며, 이는 불가피하게 시스템의 오버 헤드를 증가시킬 것입니다. 때로는 공장에서 단일 제품 객체 대신 여러 제품 객체를 제공해야 할 수 있습니다. 예를 들어, 전기 제품 공장은 한 가지 유형의 전기 제품이 아닌 텔레비전, 냉장고, 에어컨과 같은 여러 전기 제품을 생산할 수 있습니다. . 이 시점에서 일부 관련 제품을 동일한 공장에서 생산하는 "제품군"으로 결합하는 것을 고려할 수 있습니다. 이것이 이번 장에서 배우게 될 추상 공장 모델의 기본 아이디어입니다.

1.2 명사 설명

추상 팩토리 패턴은 일반적으로 사용되는 창조 디자인 패턴 중 하나로서 팩토리 (메소드) 패턴보다 추상화 수준이 높습니다. 공장 (방법) 모드에서는 각 특정 공장이 특정 제품 만 생산하면되지만 추상 공장 모드에서는 특정 공장이 관련 특정 제품 그룹을 생산할 수 있습니다. 이러한 제품 그룹을 제품군이라고합니다. 제품군의 제품은 특정 제품 상속 계층에 속합니다.

 추상 팩토리 패턴을 이해하기 전에 먼저 다음 두 가지 명사 개념을 이해합니다.

  • (1) 제품 계층 구조 : 제품 계층 구조는 제품의 상속 구조입니다. 예를 들어 추상 범주는 TV이고 하위 범주에는 Haier TV, Hisense TV, TCL TV, 추상 TV 및 특정 브랜드 TV A가 있습니다. 제품 수준 구조는 그들 사이에 형성되며, 추상 TV 세트는 상위 카테고리이고 특정 브랜드 TV 세트는 하위 카테고리입니다.
  • (2) 제품군 : 추상 공장 모델에서 제품군은 동일한 공장에서 생산되고 서로 다른 제품 계층 구조에있는 제품 그룹을 의미합니다. 예를 들어, Haier Electric Appliances Factory에서 생산하는 Haier TV 및 Haier 냉장고, Haier TV는 TV 제품 계층에 있으며, Haier 냉장고는 냉장고 제품 계층에 있으며, Haier TV와 Haier 냉장고는 제품군을 구성합니다.

1.3 추상 공장 패턴의 정의

추상 팩토리 패턴은 개체 집합을 만들기위한 솔루션을 제공합니다. 공장 모델과 비교할 때 추상 공장 모델의 특정 감독은 제품을 만드는 것뿐만 아니라 제품군을 만드는 것입니다.

  • 추상 팩토리 패턴 : 특정 클래스를 지정하지 않고 일련의 관련되거나 상호 의존적 인 객체를 만들기위한 인터페이스를 제공합니다.
  • 추상 팩토리 패턴 : 구체적인 클래스를 지정하지 않고 관련되거나 종속 된 객체의 패밀리를 생성하기위한 인터페이스를 제공합니다.

추상 팩토리 패턴은 객체 생성 패턴 인 도구 (Ki) 패턴 이라고도합니다 .


2 | 추상 공장 구조 및 구현

2.1
추상 팩토리 패턴 의 구조 추상 팩토리 패턴에서 각 콘크리트 팩토리는 다양한 유형의 제품을 생산하기 위해 여러 팩토리 방법을 제공하며 이러한 제품은 제품군을 구성합니다. 
추상 팩토리 패턴에는 다음 4 가지 역할이 포함됩니다.

  • (1) AbstractFactory : 제품군을 생성하기위한 일련의 메소드를 선언하며, 각 메소드는 제품에 해당합니다.
  • (2) ConcreteFactory (콘크리트 팩토리) : 추상 팩토리에서 제품을 선언하고 생성하는 방식을 구현하고 구체적인 제품 집합을 생성합니다. 이러한 제품들은 제품군을 구성하며 각 제품은 특정 제품 계층에 위치합니다.
  • (3) AbstractProduct (추상 제품) : 제품 별 인터페이스를 선언하고, 제품의 사업 방식을 추상 제품에 선언한다.
  • (4) ConcreteProduct (콘크리트 제품) : 콘크리트 공장에서 생산되는 구체적인 제품 객체를 정의하고 추상적 인 제품 인터페이스에 선언 된 비즈니스 방식을 구현합니다.

2.2 추상 팩토리 패턴의 구현 추상 팩토리
에서는 다양한 유형의 제품을 생성하기 위해 여러 팩토리 메소드가 선언되며, 추상 팩토리는 인터페이스, 추상 클래스 또는 구체적인 클래스가 될 수 있습니다. 일반적인 코드는 다음과 같습니다.
응용 프로그램의 예, 회사에서 인터페이스를 아름답게하기 위해 .NET 플랫폼을 기반으로하는 스킨 라이브러리 세트, 데스크톱 소프트웨어를 개발하려고합니다.

코드 디자인 :

  • 인터페이스 ISkinFactory는 추상 팩토리로 작동하고 하위 클래스 SpringSkinFactory 및 SummerSkinFactory는 콘크리트 팩토리로 작동합니다.
  • 인터페이스 IButton, IComboBox 및 ITextFiled는 추상 제품으로 작동하고 하위 클래스 SpringButton, SpringComboBox, SpringTextFiled 및 SummerButton, SummerComboBox 및 SummerTextFiled는 구체적인 제품으로 작동합니다.

ISkinFactory

/// <summary>
/// 界面皮肤工厂接口,充当抽象工厂
/// </summary>
interface ISkinFactory
{
    IButton CreateButton();
    ITextFiled CreateTextFiled();
    IComboBox CreateComboBox();
}

SpringSkinFactory

/// <summary>
/// Spring 皮肤工厂,充当具体工厂
/// </summary>
class SpringSkinFactory : ISkinFactory
{
    public IButton CreateButton()
    {
        return new SpringButton();
    }

    public IComboBox CreateComboBox()
    {
        return new SpringComboBox();
    }

    public ITextFiled CreateTextFiled()
    {
        return new SpringTextFiled();
    }
}

IButton

/// <summary>
/// 按钮接口,充当抽象产品
/// </summary>
interface IButton
{
    void Display();
}

SpringButton 

/// <summary>
/// Spring 按钮类,充当具体产品
/// </summary>
class SpringButton : IButton
{
    public void Display()
    {
        Console.WriteLine("显示浅绿色的按钮。");
    }
}

클라이언트 프로그램의 주요 호출

//xml配置文件与反射方式扩展
// 1.读取【App.config】配置文件
string factoryString = ConfigurationManager.AppSettings["spring"];
ISkinFactory skinFactory = (ISkinFactory)Assembly.Load("AbstractFactoryPattern").CreateInstance(factoryString);
IButton ibtn = skinFactory.CreateButton();
IComboBox iComBox = skinFactory.CreateComboBox();
ITextFiled iTextFiled = skinFactory.CreateTextFiled();

ibtn.Display();
iComBox.Display();
iTextFiled.Display();

다른 구현은 유사하며 여기에서 생략되었습니다. 전체 코드 데모 참조 =》https://gitee.com/dolayout/DesignPatternOfCSharp/tree/master/DesignPatternOfCSharp/AbstractFactoryPattern

3 | 추상 공장 모델에서 개폐 원리의 성향

위의 인터페이스 스킨 라이브러리는 새로운 유형의 스킨 라이브러리를 쉽게 추가 할 수 있지만이 디자인 체계에는 매우 심각한 문제가 있습니다. 디자인 초기에 디자인이 포괄적이지 않은 경우 특정 유형의 인터페이스 구성 요소 (예 : 라디오 버튼) 각기 다른 스킨 아래에 스타일 디스플레이를 제공하면 시스템에 라디오 버튼을 추가하는 것이 매우 번거로울 것입니다. 개폐 원칙을 만족한다는 전제하에 라디오 버튼을 추가하는 것은 불가능합니다. 이유는 초록이기 때문입니다. 팩토리 ISkinFactory는 라디오 버튼 생성을 전혀 제공하지 않습니다.이 버튼을 추가해야하는 경우 먼저 추상 팩토리 인터페이스 ISkinFactory를 수정하고 그 안에 라디오 버튼을 생성하는 메소드를 추가 한 다음, 특정 팩토리 클래스를 수정해야합니다. 클래스를 하나씩 파생하고 해당 메서드를 추가하여 다른 스킨 라이브러리에서 사용할 수 있습니다. 라디오 버튼을 만들려면 클라이언트도 수정해야합니다. 그렇지 않으면 기존 시스템에서 라디오 버튼을 사용할 수 없습니다.

추상 팩토리 패턴은 이러한 문제를 잘 해결할 수없고, 이것이 추상 팩토리 패턴의 가장 큰 단점이기도합니다. 추상 공장에서는 신제품 군을 추가하는 것이 편리하지만 새로운 제품의 계층 구조를 추가하는 것이 번거롭고, 추상 공장 모델의 이러한 특징을 개폐 원리의 경향이라고한다. 개방 및 폐쇄 원칙은 시스템을 확장을 위해 개방하고 수정을 위해 폐쇄해야합니다. 확장을 통해 기능을 강화하는 목적은 기능을 향상시키는 목적을 달성하는 것입니다. 여러 제품군 및 여러 제품 계층 구조를 포함하는 시스템의 경우 기능 향상에는 다음 두 가지 사항이 포함됩니다.

  • (1) 제품군 추가 : 새로 추가 된 제품군에 해당하는 추상 공장 모델은 개폐 원칙을 잘 지원합니다. 특정 제품을 추가하고 이에 따라 새로운 특정 공장을 추가하면됩니다. 기존 코드가 필요하지 않습니다. . 모든 수정.
  • (2) 신규 상품 레벨 구조 추가 : 신규 상품 레벨 구조 추가에 대응하여 추상 팩토리 클래스를 포함한 모든 팩토리 역할을 수정하고, 개봉 원칙을 위반하는 모든 팩토리 클래스에 신제품 메소드를 추가해야합니다. 닫습니다.

추상적 인 공장 모델은 개방 및 폐쇄 원칙을 충족하는 경 사진 방식이므로 설계자는 설계 초기에 포괄적으로 고려해야합니다. 그렇지 않으면 시스템에 큰 변화를 일으키고 후속 유지 보수에 많은 문제와 위험을 초래합니다. 작업.

4 | 추상 팩토리 패턴의 장단점 및 적용 가능한 시나리오

추상 팩토리 패턴은 팩토리 (메소드) 패턴의 추가 확장입니다.보다 강력한 팩토리 클래스를 제공하고 더 나은 확장 성을 제공하기 때문에 소프트웨어 개발, 특히 일부 프레임 워크 및 API 라이브러리에서 널리 사용됩니다. 추상 팩토리 패턴은 소프트웨어 개발에서 가장 일반적으로 사용되는 디자인 패턴 중 하나입니다.
4.1 추상 팩토리 패턴의 주요 장점

  • (1) 추상 팩토리 패턴은 구체적인 클래스 생성을 분리하므로 클라이언트는 생성 된 내용을 알 필요가 없습니다. 이러한 격리로 인해 콘크리트 공장의 교체가 상대적으로 쉬워진다. 모든 콘크리트 공장은 추상 공장에서 정의 된 공용 인터페이스를 구현하므로 콘크리트 공장의 인스턴스를 변경해야만 전체 소프트웨어 시스템을 어느 정도 변경할 수있다. .의 행동.
  • (2) 제품군의 여러 개체가 함께 작동하도록 설계된 경우 클라이언트는 항상 동일한 제품군의 개체 만 사용하도록 할 수 있습니다.
  • (3) 추상 공장 모델은 기존 시스템을 수정하지 않고 새로운 제품군을 추가하는 것이 매우 편리하며 개폐 원칙을 준수합니다.

4.2 추상 팩토리 모델의 주요 단점
새로운 제품 레벨 구조를 추가하는 것이 번거롭고, 원래 시스템에 대대적 인 수정이 필요하며, 추상 레이어 코드를 수정해야 할 필요도있어 더 큰 불편을 초래하고 원칙을 위반합니다. 개폐.

4.3 추상 공장 패턴의 적용 가능한 환경

  • (1) 시스템은 제품 클래스 인스턴스의 생성, 결합 및 표현 방법에 대한 세부 사항에 의존해서는 안됩니다. 이것은 모든 유형의 공장 모델에서 중요합니다. 사용자는 객체 생성 프로세스에 신경 쓸 필요가 없으며 문제를 해결할 필요가 없습니다. 개체의 생성 및 사용 결합.
  • (2) 시스템에 하나 이상의 제품군이 있지만 매번 하나의 제품군 만 사용되며 사용자는 구성 파일 및 기타 방법을 통해 제품군을 동적으로 변경할 수 있으며 새로운 제품군을 쉽게 추가 할 수도 있습니다.
  • (3) 동일한 제품군에 속하는 제품은 함께 사용되며 이러한 제약은 시스템 설계에 반영되어야합니다. 동일한 제품군의 제품은 관련없는 개체 일 수 있지만 모두 동일한 운영 체제에서 단추 및 텍스트 상자와 같은 몇 가지 공통적 인 제약 조건이 있습니다. 단추와 텍스트 상자간에 직접적인 관계는 없지만 모두 특정 개체에 속합니다. 운영 체제에는 현재 공통적 인 제약이 있습니다. 바로 운영 체제 유형입니다.
  • (4) 제품 등급 구조가 안정적이며 설계가 완료된 후 새로운 제품 등급 구조가 시스템에 추가되지 않거나 기존 제품 등급 구조가 삭제되지 않습니다.

추천

출처blog.csdn.net/ChaITSimpleLove/article/details/114496161