디자인 모드-빌더 모드 소개

소개

소프트웨어 개발에는 일련의 구성원 속성이있는 복잡한 객체가 많이 있으며, 그중 일부는 참조 유형의 구성원 객체입니다. 이러한 복합 객체에는 몇 가지 제한이있을 수 있습니다. 예를 들어 일부 속성이 지정되지 않은 경우 복합 객체는 완전한 제품으로 사용할 수 없으며 일부 속성의 지정은 특정 순서로 이루어져야합니다. 하나의 속성이 지정되기 전에 다른 속성이 값 등을 할당하지 못할 수 있습니다.

부품을 조립하는 과정이 매우 복잡하기 때문에 이러한 부품을 조립하는 과정은 종종 빌더라는 객체로 "외부화"됩니다. 빌더가 클라이언트에게 반환하는 것은 빌드 된 완전한 제품 객체이므로 사용자는이를 수행 할 필요가 없습니다. 객체에 포함 된 속성과 이들이 어셈블되는 방법을 관리하는 것이 빌더 패턴의 패턴 동기입니다.

빌더 패턴 단계로 복잡한 개체 단계를 구축하기 위해 여러 간단한 객체를 사용합니다. 이러한 유형의 디자인 패턴은 개체를 만드는 가장 좋은 방법을 제공하는 생성 패턴입니다.

예

빌더 모드에는 다음 역할이 포함됩니다.

Builder: 추상 빌더
ConcreteBuilder: 구체적 건조자는
Director: 사령관
Product:생성물

컴퓨터는 모든 프로그래머의 표준 구성이며 주요 액세서리는 CPU, 마더 보드, 메모리, 그래픽 카드 및 전원 공급 장치입니다. 현재 두 가지 주요 플랫폼이 있습니다. AMD및 Intel, 그러나 두 플랫폼 중 일부는 다릅니다. 따라서 두 플랫폼을 조립할 때 Feizhai가 선택한 액세서리도 다릅니다.

제품 (컴퓨터) :

public class Computer {
    /**
     * cpu
     */
    private String cpu;
    /**
     * 主板
     */
    private String motherboar;
    /**
     * 内存
     */
    private String ram;
    /**
     * 显卡
     */
    private String graphicsCard;
    /**
     * 电源
     */
    private String power;

    //setter and getter
    // toString
}

추상 공장 :

abstract class AbstractComputerBuilder {
    /**
     * 选择CPU
     */
    abstract void buildCPU();
    /**
     * 选择主板
     */
    abstract void buildMotherboar();
    /**
     * 选择内存
     */
    abstract void buildRam();
    /**
     * 选择显卡
     */
    abstract void buildGraphicsCard();
    /**
     * 选择电源
     */
    abstract void buildPower();
    /**
     * 获取电脑
     */
    abstract Computer getComputer();
}

구체적 건조자는 :

// AMD电脑 建造者
public class AmdComputerBuilder extends AbstractComputerBuilder {
    private Computer computer = new Computer();
    @Override
    void buildCPU() {
        computer.setCpu("2700x");
    }
    @Override
    void buildMotherboar() {
        computer.setMotherboar("华硕 ROG X470");
    }
    @Override
    void buildRam() {
        computer.setRam("芝奇 DDR4 8G");
    }
    @Override
    void buildGraphicsCard() {
        computer.setGraphicsCard("vega 56");
    }
    @Override
    void buildPower() {
        computer.setPower("EVGA 750W");
    }
    @Override
    Computer getComputer() {
        return computer;
    }
}

// Intel 电脑建造者
public class IntelComputerBuilder extends AbstractComputerBuilder {
    private Computer computer = new Computer();
    @Override
    void buildCPU() {
        computer.setCpu("i7 8700");
    }
    @Override
    void buildMotherboar() {
        computer.setMotherboar("微星 Z370");
    }
    @Override
    void buildRam() {
        computer.setRam("金士顿 DDR4 8G");
    }
    @Override
    void buildGraphicsCard() {
        computer.setGraphicsCard("GTX 1080Ti");
    }
    @Override
    void buildPower() {
        computer.setPower("海韵 750W");
    }
    @Override
    Computer getComputer() {
        return computer;
    }
}

사령관:

public class ComputerDirector {
    public void construct(AbstractComputerBuilder builder) {
        builder.buildCPU();
        builder.buildMotherboar();
        builder.buildRam();
        builder.buildGraphicsCard();
        builder.buildPower();
    }
}

테스트:

public class Fz {
    @Test
    public void build() {
        ComputerDirector director = new ComputerDirector();

        AmdComputerBuilder amdComputerBuilder = new AmdComputerBuilder();
        director.construct(amdComputerBuilder);
        Computer amdComputer = amdComputerBuilder.getComputer();
        System.out.println("选择AMD平台配件：" + amdComputer);

        IntelComputerBuilder intelComputerBuilder = new IntelComputerBuilder();
        director.construct(intelComputerBuilder);
        Computer intelComputer = intelComputerBuilder.getComputer();
        System.out.println("选择Intel平台配件：" + intelComputer);

    }

}

클래스 다이어그램

이점

빌더 모드의 캡슐화는 매우 좋습니다. 빌더 모드를 사용하면 변경 사항을 효과적으로 캡슐화 할 수 있습니다. 빌더 모드를 사용하는 시나리오에서는 일반 상품 카테고리와 빌더 카테고리가 상대적으로 안정적입니다. 따라서 디렉터 카테고리에서 주요 비즈니스 로직을 캡슐화하면 전체적으로 비교할 수 있습니다. 좋은 안정성.
빌더 모드에서 클라이언트는 제품의 내부 구성에 대한 세부 정보를 알 필요가 없으며 제품 자체가 제품 생성 프로세스에서 분리되어 동일한 생성 프로세스가 다른 제품 개체를 생성 할 수 있습니다.
제품 생성 프로세스를보다 세밀하게 제어 할 수 있습니다. 복잡한 제품의 생성 단계를 다른 방법으로 분해하면 생성 프로세스가 더 명확 해지고 프로그램을 사용하여 생성 프로세스를 제어하기가 더 쉬워집니다.
빌더 모드는 쉽게 확장 할 수 있습니다. 새로운 요구 사항이있는 경우 새로운 빌더 클래스를 구현하여 완성 할 수 있으며, 기본적으로 이전에 테스트 한 코드를 수정할 필요가 없으므로 원래 기능에 위험을 초래하지 않습니다. 개폐 원칙을 준수하십시오.

불리

빌더 모드로 생성 된 제품은 일반적으로 공통점이 많고 구성 요소가 유사하며, 제품이 매우 다를 경우 빌더 모드 사용에 적합하지 않으므로 사용 범위에 제한이 있습니다.
제품의 내부 변경이 복잡하면이 변경을 달성하기 위해 많은 특정 빌더 클래스를 정의해야하므로 시스템이 매우 커질 수 있습니다.

해당 장면

빌더 모드는 다음 상황에서 사용할 수 있습니다.

생성해야하는 제품 개체에는 복잡한 내부 구조가 있으며 이러한 제품 개체에는 일반적으로 여러 구성원 속성이 포함됩니다.
생성 할 제품 개체의 속성은 서로에 따라 다르며 생성 순서를 지정해야합니다.
객체의 생성 프로세스는 객체를 생성 한 클래스와 독립적입니다. 빌더 모드에서는 리더 클래스가 도입되고 생성 프로세스는 빌더 클래스가 아닌 리더 클래스에 캡슐화됩니다.
복잡한 개체의 생성 및 사용을 분리하고 동일한 생성 프로세스를 통해 서로 다른 제품을 생성 할 수 있습니다.

요약하자면

빌더 모드는 공장 모드와 유사하며 적용 가능한 시나리오도 매우 유사합니다. 빌더 모드는 공장 모드보다 "커맨더"역할이 하나 더 있습니다. 빌더 패턴의 클래스 다이어그램에서 디렉터 클래스가 궁극적으로 호출되는 클라이언트로 간주되면 나머지 그림은 단순한 팩토리 패턴으로 간주 될 수 있습니다.

빌더 모드는 일반적으로 객체 생성 프로세스가 더 복잡하기 때문에 더 복잡한 객체를 생성하는 데 사용됩니다. 따라서 객체 생성 프로세스는 새로운 클래스 인 디렉터 클래스로 분리됩니다. 즉, 팩토리 모델은 팩토리 클래스에서 개체의 전체 생성 프로세스를 캡슐화하고 팩토리 클래스는 클라이언트에게 최종 제품을 제공합니다. 빌더 모드에서 빌더 클래스는 일반적으로 제품 클래스의 각 구성 요소의 구성 만 제공합니다. 구체적인 건설 과정은 디렉터 클래스에 전달됩니다. 디렉터 클래스는 특정 규칙에 따라 각 구성 요소를 제품으로 구성한 다음 조립 된 제품을 고객에게 제공합니다. 빌더 모드는 부품 조립 순서에 더 많은주의를 기울입니다.

일반적으로 제품의 구조가 복잡한 경우에는 공장 모델을 사용하고, 제품의 구조가 더 복잡한 경우에는 빌더 모델을 사용하십시오.