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

이미 간단한 팩토리 패턴과 팩토리 메소드 패턴을 소개했습니다. 여기서는 계속해서 세 번째 팩토리 패턴인 추상 팩토리 패턴을 소개하겠습니다. 예.

사례 배경:

고객 요구 사항이 점점 더 높아짐에 따라 BMW 자동차에는 에어컨, 엔진 및 기타 액세서리의 다양한 구성이 필요합니다. 그래서 공장에서는 에어컨과 자동차 조립용 엔진을 생산하기 시작했습니다. 현재 공장에는 에어컨과 엔진이라는 두 가지 제품 시리즈가 있습니다. BMW 320 시리즈에는 모델 A 에어컨과 모델 A 엔진이 탑재되고, BMW 230 시리즈에는 모델 B 에어컨과 모델 B 엔진이 탑재된다.

개념:

추상 팩토리 패턴은 팩토리 메소드 패턴의 업그레이드 버전으로, 관련되거나 상호 의존적인 객체 집합을 만드는 데 사용됩니다. 예를 들어 BMW 320 시리즈는 에어컨 모델 A와 엔진 모델 A를 사용하고, BMW 230 시리즈는 에어컨 모델 B와 엔진 모델 B를 사용한다. 그러면 추상 팩토리 패턴을 이용하여 320 시리즈 관련 액세서리를 제작할 때, 액세서리 모델을 지정할 필요가 없습니다. 자동차 모델에 따라 해당 액세서리 모델 A가 자동으로 생성됩니다.

Baidu Encyclopedia의 추상 팩토리 패턴에 대한 소개를 기반으로 다음 예와 결합합니다.

각 추상 제품에 하나 이상의 구체적인 하위 클래스가 있는 경우(에어컨에는 모델 A가 있고 두 개가 있습니다) 유형은 B이고 엔진에는 A와 B라는 두 가지 유형이 있습니다. 팩토리 역할은 인스턴스화할 하위 클래스를 어떻게 알 수 있습니까? 예를 들어, 각 추상 제품 역할에는 두 개의 특정 제품이 있습니다(제품 에어컨에는 에어컨 A와 에어컨 B라는 두 개의 특정 제품이 있습니다). 추상 팩토리 패턴은 두 가지 특정 제품 역할에 각각 해당하는 두 가지 특정 팩토리 역할(BMW 320 시리즈 팩토리 및 BMW 230 시리즈 팩토리)을 제공합니다. 각 특정 팩토리 역할은 특정 제품 역할의 인스턴스화에만 책임이 있습니다. 각 구체적인 팩토리 클래스는 추상 제품의 특정 하위 클래스 인스턴스를 생성하는 역할만 담당합니다.

추상 팩토리 패턴 코드

제품 카테고리:

//发动机以及型号    
public interface Engine {    
  
}    
public class EngineA extends Engine{    
    public EngineA(){    
        System.out.println("制造-->EngineA");    
    }    
}    
public class EngineBextends Engine{    
    public EngineB(){    
        System.out.println("制造-->EngineB");    
    }    
}    
  
//空调以及型号    
public interface Aircondition {    
  
}    
public class AirconditionA extends Aircondition{    
    public AirconditionA(){    
        System.out.println("制造-->AirconditionA");    
    }    
}    
public class AirconditionB extends Aircondition{    
    public AirconditionB(){    
        System.out.println("制造-->AirconditionB");    
    }    
}

팩토리 클래스 생성:

//创建工厂的接口    
public interface AbstractFactory {    
    //制造发动机  
    public Engine createEngine();  
    //制造空调   
    public Aircondition createAircondition();   
}    
  
  
//为宝马320系列生产配件    
public class FactoryBMW320 implements AbstractFactory{    
        
    @Override    
    public Engine createEngine() {      
        return new EngineA();    
    }    
    @Override    
    public Aircondition createAircondition() {    
        return new AirconditionA();    
    }    
}    
//宝马523系列  
public class FactoryBMW523 implements AbstractFactory {    
    
     @Override    
    public Engine createEngine() {      
        return new EngineB();    
    }    
    @Override    
    public Aircondition createAircondition() {    
        return new AirconditionB();    
    }    
  
  
}

고객:

public class Customer {    
    public static void main(String[] args){    
        //生产宝马320系列配件  
        FactoryBMW320 factoryBMW320 = new FactoryBMW320();    
        factoryBMW320.createEngine();  
        factoryBMW320.createAircondition();  
            
        //生产宝马523系列配件    
        FactoryBMW523 factoryBMW523 = new FactoryBMW523();    
        factoryBMW320.createEngine();  
        factoryBMW320.createAircondition();  
    }    
}

추상 팩토리 패턴과 팩토리 메소드 패턴의 차이점에 대해서는 여기서는 다루지 않겠습니다. 예제를 몇 번 읽으면 이해할 수 있을 것 같습니다. 제품군과 계층 구조에 대해 이야기하는 것이 더 흥미로울 것입니다.

추상 팩토리 패턴의 유래

다음은 추상 팩토리 패턴의 유래를 인용한 것입니다.

추상 팩토리 패턴의 유래 또는 최초 적용은 다음과 같습니다. 다른 작업에 속하는 객체를 생성합니다. 시스템 창 구성. 예를 들어, 명령 버튼(Button)과 텍스트 상자(Text)는 모두 UNIX 운영 체제의 창 환경과 Windows 운영 체제의 창 환경에서 서로 다른 로컬 구현을 가지며, 그 구조는 서로 다릅니다. 세부 사항이 다릅니다.

모든 운영 체제에는 창 빌드로 구성된 빌드 패밀리가 있습니다. Button과 Text로 구성된 제품군은 다음과 같습니다. 각 창 구성 요소는 추상적인 기능 설명을 제공하는 추상 역할과 다양한 운영 체제에서 특정 구현을 제공하는 구체적인 하위 클래스를 통해 고유한 계층 구조를 형성합니다.

위의 제품 카테고리 다이어그램에는 두 가지 제품 계층 구조, 즉 버튼 계층 구조와 텍스트 계층 구조가 있음을 확인할 수 있습니다. UNIX 제품군과 Windows 제품군이라는 두 가지 제품군이 동시에 있습니다. UNIX 제품군은 UNIX Button 및 UNIX Text 제품으로 구성됩니다. Windows 제품군은 Windows Button 및 Windows Text 제품으로 구성됩니다.

제품 개체에 대한 시스템 생성 요구 사항은 UnixFactory와 WindowsFactory라는 두 가지 특정 프로젝트 역할이 있는 프로젝트의 계층 구조에 의해 충족됩니다. UnixFactory 개체는 Unix 제품군의 제품 생성을 담당하고 WindowsFactory 개체는 Windows 제품군의 제품 생성을 담당합니다. 이것이 추상 팩토리 패턴의 적용이다. 추상 팩토리 패턴의 해결 방법은 다음과 같다.

분명히 시스템은 특정 윈도우 환경에서만 실행될 수 있다. 운영 체제이며 동시에 다른 운영 체제에서 실행할 수 없습니다. 따라서 시스템은 실제로 동일한 제품군에 속하는 제품만 소비할 수 있습니다.

현대 애플리케이션에서는 추상 팩토리 패턴의 사용 범위가 크게 확장되었으며 시스템은 더 이상 특정 제품군만 소비할 필요가 없습니다.

요약:

간단한 팩토리 패턴이든, 팩토리 메소드 패턴이든, 추상 팩토리 패턴이든 모두 팩토리 패턴에 속하며 형태와 특성이 매우 유사합니다. 궁극적인 목표는 디커플링(decoupling)을 위한 것입니다. 이를 사용할 때 이 패턴이 팩토리 메서드 패턴인지 추상 팩토리 패턴인지 걱정할 필요가 없습니다. 왜냐하면 둘 사이의 진화가 종종 혼란스럽기 때문입니다. 종종 새로운 요구사항이 발생하면 사용 중인 팩토리 메소드 패턴이 약간 수정되고 새 메소드가 추가되는 것을 발견할 수 있습니다. 클래스의 제품은 서로 다른 계층 구조의 제품군을 구성하므로 추상 팩토리가 됩니다. 추상적인 팩토리 패턴의 경우, 하나의 메소드가 축소되어 제공된 제품이 더 이상 제품군을 구성하지 못하게 되면 팩토리 메소드 패턴으로 진화합니다.

따라서 팩토리 패턴을 사용할 때는 커플링을 줄이는 목적이 달성되었는지 여부만 신경 쓰면 됩니다.

JAVA 디자인 패턴 중 Abstract Factory Pattern과 관련된 더 많은 글은 PHP 중국어 홈페이지를 주목해주세요!

관련글 :

Java에서 추상 팩토리 패턴을 구현하는 구체적인 코드에 대한 자세한 설명

PHP 단순 팩토리 패턴, 팩토리 메소드 패턴과 추상 팩토리 패턴 비교

PHP 객체지향 개발 - 추상 팩토리 패턴