デザインモード-ビルダーモードの概要

前書き

ソフトウェア開発では、一連のメンバー属性を持つ複雑なオブジェクトが多数あり、その一部は参照タイプのメンバーオブジェクトです。また、これらの複雑なオブジェクトには、いくつかの制限がある場合があります。たとえば、一部の属性が割り当てられていない場合、複雑なオブジェクトを完全な製品として使用することはできません。一部の属性の割り当ては特定の順序である必要があります。1つの属性を割り当てる前に、別の属性値等の割り当てができない場合があります。

パーツを組み立てるプロセスは非常に複雑であるため、これらのパーツを組み立てるプロセスは、多くの場合、ビルダーと呼ばれるオブジェクトに「外部化」されます。ビルダーがクライアントに返すのは、ビルドされた完全な製品オブジェクトであり、ユーザーはこれを行う必要はありません。オブジェクトに含まれる属性とそれらがどのように組み立てられるかを気にすることは、ビルダーパターンのパターン動機です。

Builderパターンは、ステップによって、複雑なオブジェクトのステップを構築するために、複数の単純なオブジェクトを使用しています。このタイプのデザインパターンは作成パターンであり、オブジェクトを作成するための最良の方法を提供します。

インスタンス

ビルダーモードには、次の役割が含まれます。

  1. Builder:抽象ビルダー
  2. ConcreteBuilder:具体建造者
  3. Director:司令官
  4. Product:製品

コンピューターはすべてのプログラマーの標準構成です。主なアクセサリは、CPU、マザーボード、メモリ、グラフィックカード、および電源です。現在、2つの主要なプラットフォームがあります:AMDIntel。ただし、2つのプラットフォームの一部は異なります。したがって、2つのプラットフォームを組み立てるときに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);

    }

}

クラス図

利点

  1. ビルダーモードのカプセル化は非常に優れています。ビルダーモードを使用すると、変更を効果的にカプセル化できます。ビルダーモードを使用するシナリオでは、一般的な製品カテゴリとビルダーカテゴリは比較的安定しているため、ディレクターカテゴリに主要なビジネスロジックをカプセル化することを全体として比較できます。良好な安定性。
  2. ビルダーモードでは、クライアントは製品の内部構成の詳細を知る必要がなく、製品自体を製品作成プロセスから切り離して、同じ作成プロセスで異なる製品オブジェクトを作成できるようにします。
  3. 製品作成プロセスをより細かく制御できます。複雑な製品の作成ステップをさまざまな方法に分解すると、作成プロセスがより明確になり、プログラムを使用して作成プロセスを制御するのがより便利になります。
  4. ビルダーモードは簡単に拡張できます。新しい要件がある場合は、新しいビルダークラスを実装することで完了できます。基本的に、以前にテストしたコードを変更する必要がないため、元の関数にリスクが生じることはありません。開閉の原則を遵守してください。

不利益

  1. ビルダーモードで作成された製品は、一般的に共通点が多く、コンポーネントも類似しています。製品が大きく異なる場合、ビルダーモードは使用に適さないため、使用範囲が限定されます。
  2. 製品の内部変更が複雑な場合、この変更を実現するために多くの具体的なビルダークラスを定義する必要が生じ、システムが非常に大きくなる可能性があります。

該当シーン

ビルダーモードは、次の状況で使用できます。

  1. 生成する必要のある製品オブジェクトは複雑な内部構造を持っており、これらの製品オブジェクトには通常、複数のメンバー属性が含まれています。
  2. 生成される製品オブジェクトの属性は相互に依存しており、生成の順序を指定する必要があります。
  3. オブジェクトの作成プロセスは、オブジェクトを作成したクラスから独立しています。ビルダーモードでは、リーダークラスが導入され、作成プロセスはビルダークラスではなくリーダークラスにカプセル化されます。
  4. 複雑なオブジェクトの作成と使用を分離し、同じ作成プロセスで異なる製品を作成できるようにします。

総括する

ビルダーモードはファクトリーモードに似ており、適用可能なシナリオも非常に似ています。ビルダーモードには、ファクトリーモードよりも「コマンダー」の役割が1つだけあります。ビルダーパターンのクラス図では、ディレクタークラスが最終的に呼び出されるクライアントと見なされる場合、図の残りの部分は単純なファクトリパターンと見なすことができます。

オブジェクト作成プロセスはより複雑であるため、ビルダーモードは通常、より複雑なオブジェクトを作成するために使用されます。そのため、オブジェクト作成プロセスは新しいクラスディレクタークラスに分離されます。言い換えると、ファクトリモデルはファクトリクラスのオブジェクトの作成プロセス全体をカプセル化し、ファクトリクラスはクライアントに最終製品を提供します。ビルダーモードでは、ビルダークラスは通常、製品クラスの各コンポーネントの構築のみを提供します。特定の建設プロセスは、ディレクタークラスに配信されます。ディレクタークラスは、特定のルールに従って各コンポーネントを製品に成形し、組み立てられた製品をクライアントに提供する責任があります。ビルダーモードでは、パーツの組み立て順序にさらに注意が払われます。

一般的に、製品の構造が複雑な場合はファクトリーモデルを使用してください。製品の構造がより複雑な場合はビルダーモデルを使用してください。

おすすめ

転載: blog.csdn.net/doubututou/article/details/109210290