欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 文旅 > 美景 > 设计模式——建造者模式(生成器模式)

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

2024/10/24 5:20:08 来源:https://blog.csdn.net/weixin_42903300/article/details/139634296  浏览:    关键词:设计模式——建造者模式(生成器模式)

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

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示的意图
用了建造者模式,那么用户就只需要指定需要构建的类型就可以得到它们,而具体构造的细节和过程不需要知道
在这里插入图片描述

概括地说,Builder是为创建一个Product对象的各个部件指定的抽象接口
而ConcreteBuilder是具体的建造者,实现Builder接口,构造和装配各个部件,Product是具体的产品
Director是指挥者,是构建一个使用Builder接口的对象。

  • 什么时候需要用到建造者模式?
    当我们需要创建一些复杂的对象,这些对象内部构建间的顺序通常是稳定的,但是对象内部的构建通常面临着复杂的变化

  • 实现方法

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

基本代码如下

#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: PartA1Standard full featured product:
Product parts: PartA1, PartB1, PartC1Custom product:
Product parts: PartA1, PartC1

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com