设计模式——建造者模式(生成器模式)

建造者模式(生成器模式)

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示的意图

用了建造者模式,那么用户就只需要指定需要构建的类型就可以得到它们,而具体构造的细节和过程不需要知道

概括地说,Builder是为创建一个Product对象的各个部件指定的抽象接口

而ConcreteBuilder是具体的建造者,实现Builder接口,构造和装配各个部件,Product是具体的产品

Director是指挥者,是构建一个使用Builder接口的对象。

  • 什么时候需要用到建造者模式?

    当我们需要创建一些复杂的对象,这些对象内部构建间的顺序通常是稳定的,但是对象内部的构建通常面临着复杂的变化

  • 实现方法

    1. 清晰地定义通用步骤, 确保它们可以制造所有形式的产品。 否则你将无法进一步实施该模式。
    2. 在基本生成器接口中声明这些步骤。
    3. 为每个形式的产品创建具体生成器类, 并实现其构造步骤。
    4. 考虑创建主管类。 它可以使用同一生成器对象来封装多种构造产品的方式。
    5. 客户端代码会同时创建生成器和主管对象。 构造开始前, 客户端必须将生成器对象传递给主管对象。 通常情况下, 客户端只需调用主管类构造函数一次即可。 主管类使用生成器对象完成后续所有制造任务。 还有另一种方式, 那就是客户端可以将生成器对象直接传递给主管类的制造方法。
    6. 只有在所有产品都遵循相同接口的情况下, 构造结果可以直接通过主管类获取。 否则, 客户端应当通过生成器获取构造结果。

基本代码如下

c++ 复制代码
#include <iostream>
#include <vector>
#include <string>

using std::cout;

// 当产品非常复杂并且需要大量配置的时候,使用生成器模式非常有意义
// 各种构造器的结果可能并不总是遵循相同的接口

class Product1
{
public:
    std::vector<std::string> parts_;

    void ListParts() const
    {
        cout << "Product parts: ";
        for (size_t i = 0; i < parts_.size(); i++)
        {
            if (parts_[i] == parts_.back())
            {
                cout << parts_[i];
            }
            else
            {
                cout << parts_[i] << ", ";
            }
        }
        cout << "\n\n";
    }
};

// Builder 接口指定了创建 Product 对象不同部分的方法。
class Builder
{
public:
    virtual ~Builder(){};
    virtual void ProducePartA() const = 0;
    virtual void ProducePartB() const = 0;
    virtual void ProducePartC() const = 0;
};

// ConcreteBuilder 类遵循Builder类提供的接口,并提供建造步骤的具体实现。因此ConcreteBuilder应该有许多个,实现方法可以不同
class ConcreteBuilder1 : public Builder
{
private:
    // 一个新的构建器实例应该包含一个空白的产品对象,用于进一步的组装。
    Product1 *product;

public:
    ConcreteBuilder1()
    {
        this->Reset();
    }

    ~ConcreteBuilder1()
    {
        delete product;
    }

    void Reset()
    {
        this->product = new Product1();
    }

    // 所有生产步骤均使用同一产品实例
    void ProducePartA() const override
    {
        this->product->parts_.push_back("PartA1");
    }

    void ProducePartB() const override
    {
        this->product->parts_.push_back("PartB1");
    }

    void ProducePartC() const override
    {
        this->product->parts_.push_back("PartC1");
    }

    // 具体构建器应该提供自己的方法来检索结果。
    // 这是因为不同类型的构建器可能会创建完全不同的产品,这些产品不遵循相同的接口。
    // 因此,此类方法不能在基本构建器接口中声明(至少在静态类型编程语言中不能)

    // 通常,在将最终结果返回给客户端后,构建器实例应该准备好开始生产另一个产品。
    // 这就是为什么在 `getProduct` 方法主体末尾调用 reset 方法是一种常见做法。
    // 但是,这种行为不是强制性的,您可以让构建器等待来自客户端代码的明确 reset 调用,然后再处理之前的结果。

    // 一旦调用 GetProduct,此函数的用户就有责任释放此内存。使用智能指针来避免内存泄漏可能是一个更好的选择
    Product1 *GetProduct()
    {
        Product1 *result = this->product;
        this->Reset();
        return result;
    }
};

// Director 负责按照特定的顺序执行构建顺序,
class Director
{
private:
    Builder *builder;
    // Director 可与客户端代码传递给它的任何构建器实例配合使用。这样,客户端代码可能会改变新组装产品的最终类型。
public:
    void set_builder(Builder *builder)
    {
        this->builder = builder;
    }
    // Director 可以使用相同的构建步骤构建多个产品变体
    void BuildMinimalViableProduct()
    {
        this->builder->ProducePartA();
    }

    void BuildFullFeaturedProduct()
    {
        this->builder->ProducePartA();
        this->builder->ProducePartB();
        this->builder->ProducePartC();
    }
};

// 客户端代码创建一个构建器对象,将其传递给Director,然后启动构造过程。最终结果从构建器对象中检索。
void ClientCode(Director &director)
{
    ConcreteBuilder1 *builder = new ConcreteBuilder1();
    director.set_builder(builder);
    cout << "Standard basic product:\n";
    director.BuildMinimalViableProduct();

    Product1 *p = builder->GetProduct();
    p->ListParts();
    delete p;

    cout << "Standard full featured product:\n";
    director.BuildFullFeaturedProduct();

    p = builder->GetProduct();
    p->ListParts();
    delete p;

    // 也可以不使用Director类直接使用构造模式
    cout << "Custom product:\n";
    builder->ProducePartA();
    builder->ProducePartC();
    p = builder->GetProduct();
    p->ListParts();
    delete p;

    delete builder;
}

int main()
{
    Director *director = new Director();
    ClientCode(*director);
    delete director;
    return 0;
}

输出

Standard basic product:
Product parts: PartA1

Standard full featured product:
Product parts: PartA1, PartB1, PartC1

Custom product:
Product parts: PartA1, PartC1
相关推荐
In_life 在生活9 小时前
设计模式(四)装饰器模式与命令模式
设计模式
瞎姬霸爱.9 小时前
设计模式-七个基本原则之一-接口隔离原则 + SpringBoot案例
设计模式·接口隔离原则
鬣主任10 小时前
Spring设计模式
java·spring boot·设计模式
程序员小海绵【vincewm】12 小时前
【设计模式】结合Tomcat源码,分析外观模式/门面模式的特性和应用场景
设计模式·tomcat·源码·外观模式·1024程序员节·门面模式
丶白泽12 小时前
重修设计模式-行为型-命令模式
设计模式·命令模式
gjh120816 小时前
设计模式:工厂方法模式和策略模式
设计模式·工厂方法模式·策略模式
shinelord明17 小时前
【再谈设计模式】抽象工厂模式~对象创建的统筹者
数据结构·算法·设计模式·软件工程·抽象工厂模式
前端拾光者18 小时前
前端开发设计模式——责任链模式
设计模式·责任链模式
liang899919 小时前
设计模式之策略模式(Strategy)
设计模式·策略模式
马剑威(威哥爱编程)20 小时前
读写锁分离设计模式详解
java·设计模式·java-ee