C++如何使用建造者模式构建复杂对象-C++-PHP中文网

建造者模式解决C++中因可选参数多导致构造函数冗长难维护的问题，通过分离构建过程与表示，提升代码可读性和扩展性。

c++如何使用建造者模式构建复杂对象

在C++中，使用建造者模式来构建复杂对象，本质上是为了解决那些拥有众多可选参数、构造函数签名冗长且难以维护的问题。它将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建出不同的表示。这意味着，当你的对象有太多配置选项，或者构建步骤本身就很复杂时，建造者模式提供了一种更清晰、更可控的方式来组装它们，避免了“伸缩构造器”的噩梦。

解决方案

建造者模式的核心思想是：不直接实例化一个复杂对象，而是通过一个专门的“建造者”对象，一步步地设置对象的各个部分，最后由建造者返回最终构建好的对象。这让对象的创建过程变得更加模块化和可读。

我们以构建一台电脑为例。一台电脑可以有不同的CPU、内存、硬盘、显卡、操作系统等等。如果用传统构造函数，你可能需要一个接受十几个参数的构造函数，或者写一堆重载的构造函数，这很快就会失控。

核心组件：

立即学习“C++免费学习笔记（深入）”；

产品（Product）： 最终要构建的复杂对象，比如
```
Computer
```
登录后复制
。它通常包含许多成员变量，这些变量在构建过程中会被填充。
抽象建造者（Builder）： 定义一个接口，用于创建产品各个部分的抽象方法。例如，
```
buildCPU()
```
登录后复制
,
```
buildRAM()
```
登录后复制
,
```
buildStorage()
```
登录后复制
等。它也通常包含一个获取最终产品的方法。
具体建造者（Concrete Builder）： 实现抽象建造者接口，负责具体产品的构建。它知道如何组装产品的各个部分，并维护一个正在构建的产品实例。
指挥者（Director，可选）： 负责使用建造者接口来构建产品。它定义了构建特定类型产品的步骤序列。客户端代码可以与指挥者交互，而无需了解建造者内部的复杂性。

C++代码示例：

#include <iostream>
#include <string>
#include <vector>
#include <memory> // For std::unique_ptr

// 1. 产品 (Product)
class Computer {
public:
    void setCPU(const std::string& cpu) { this->cpu_ = cpu; }
    void setRAM(const std::string& ram) { this->ram_ = ram; }
    void setStorage(const std::string& storage) { this->storage_ = storage; }
    void setGPU(const std::string& gpu) { this->gpu_ = gpu; }
    void setOS(const std::string& os) { this->os_ = os; }

    void showConfiguration() const {
        std::cout << "--- Computer Configuration ---" << std::endl;
        std::cout << "CPU: " << cpu_ << std::endl;
        std::cout << "RAM: " << ram_ << std::endl;
        std::cout << "Storage: " << storage_ << std::endl;
        if (!gpu_.empty()) {
            std::cout << "GPU: " << gpu_ << std::endl;
        }
        if (!os_.empty()) {
            std::cout << "OS: " << os_ << std::endl;
        }
        std::cout << "-----------------------------" << std::endl;
    }

private:
    std::string cpu_;
    std::string ram_;
    std::string storage_;
    std::string gpu_;
    std::string os_;
};

// 2. 抽象建造者 (Builder)
class ComputerBuilder {
public:
    virtual ~ComputerBuilder() = default;
    virtual ComputerBuilder* buildCPU(const std::string& cpu) = 0;
    virtual ComputerBuilder* buildRAM(const std::string& ram) = 0;
    virtual ComputerBuilder* buildStorage(const std::string& storage) = 0;
    virtual ComputerBuilder* buildGPU(const std::string& gpu) = 0;
    virtual ComputerBuilder* buildOS(const std::string& os) = 0;
    virtual std::unique_ptr<Computer> getResult() = 0;
};

// 3. 具体建造者 (Concrete Builder)
class GamingComputerBuilder : public ComputerBuilder {
public:
    GamingComputerBuilder() {
        computer_ = std::make_unique<Computer>();
    }

    ComputerBuilder* buildCPU(const std::string& cpu) override {
        computer_->setCPU(cpu);
        return this;
    }
    ComputerBuilder* buildRAM(const std::string& ram) override {
        computer_->setRAM(ram);
        return this;
    }
    ComputerBuilder* buildStorage(const std::string& storage) override {
        computer_->setStorage(storage);
        return this;
    }
    ComputerBuilder* buildGPU(const std::string& gpu) override {
        computer_->setGPU(gpu);
        return this;
    }
    ComputerBuilder* buildOS(const std::string& os) override {
        computer_->setOS(os);
        return this;
    }

    std::unique_ptr<Computer> getResult() override {
        // 在这里可以添加构建前的验证逻辑
        if (computer_->getCPU().empty() || computer_->getRAM().empty()) {
            std::cerr << "Error: CPU and RAM are mandatory for a gaming computer!" << std::endl;
            return nullptr; // 或者抛出异常
        }
        return std::move(computer_);
    }

private:
    std::unique_ptr<Computer> computer_;
    // 为了示例，Computer类中添加了get方法
    // 实际项目中，通常会通过friend class或者在builder内部直接访问私有成员
    // 为了编译通过，这里假设Computer有这些get方法
    // 更好的做法是让Builder成为Computer的友元，或者Computer提供内部设置接口
};

// 为了示例编译通过，在Computer类中添加get方法
// 实际生产代码中，可能通过友元类或者其他方式访问
namespace { // 匿名命名空间，避免链接冲突
    std::string getCPU(const Computer& c) { return c.cpu_; }
    std::string getRAM(const Computer& c) { return c.ram_; }
}

// 4. 指挥者 (Director, 可选)
class ComputerAssembler {
public:
    void setBuilder(ComputerBuilder* builder) {
        builder_ = builder;
    }

    std::unique_ptr<Computer> assembleBasicGamingPC() {
        if (!builder_) {
            std::cerr << "Builder not set!" << std::endl;
            return nullptr;
        }
        return builder_->buildCPU("Intel i7-13700K")
                        ->buildRAM("32GB DDR5")
                        ->buildStorage("1TB NVMe SSD")
                        ->buildGPU("NVIDIA RTX 4070")
                        ->buildOS("Windows 11 Pro")
                        ->getResult();
    }

    std::unique_ptr<Computer> assembleHighEndGamingPC() {
        if (!builder_) {
            std::cerr << "Builder not set!" << std::endl;
            return nullptr;
        }
        return builder_->buildCPU("Intel i9-14900K")
                        ->buildRAM("64GB DDR5")
                        ->buildStorage("2TB NVMe SSD")
                        ->buildGPU("NVIDIA RTX 4090")
                        ->buildOS("Windows 11 Pro")
                        ->getResult();
    }

private:
    ComputerBuilder* builder_ = nullptr;
};

// 客户端代码
int main() {
    // 不使用Director，直接用Builder
    std::cout << "Building a custom gaming PC directly:" << std::endl;
    GamingComputerBuilder customBuilder;
    std::unique_ptr<Computer> myCustomPC = customBuilder.buildCPU("AMD Ryzen 7 7800X3D")
                                                     ->buildRAM("32GB DDR5")
                                                     ->buildStorage("2TB NVMe SSD")
                                                     ->buildGPU("AMD Radeon RX 7900 XTX")
                                                     ->buildOS("Ubuntu Linux")
                                                     ->getResult();
    if (myCustomPC) {
        myCustomPC->showConfiguration();
    }
    std::cout << std::endl;

    // 使用Director
    std::cout << "Building PCs using Director:" << std::endl;
    GamingComputerBuilder gamingBuilder;
    ComputerAssembler assembler;
    assembler.setBuilder(&gamingBuilder);

    std::unique_ptr<Computer> basicGamingPC = assembler.assembleBasicGamingPC();
    if (basicGamingPC) {
        basicGamingPC->showConfiguration();
    }
    std::cout << std::endl;

    std::unique_ptr<Computer> highEndGamingPC = assembler.assembleHighEndGamingPC();
    if (highEndGamingPC) {
        highEndGamingPC->showConfiguration();
    }
    std::cout << std::endl;

    return 0;
}

登录后复制

（注：为了代码示例的简洁性，

Computer

登录后复制

类中

getCPU()

登录后复制

和

getRAM()

登录后复制

方法在匿名命名空间中以自由函数形式模拟，实际项目中应作为

Computer

登录后复制

类的成员方法或通过友元访问。）

为什么在C++中构建复杂对象时，传统方法会变得难以维护？

在C++里，当你面对一个拥有大量配置选项或组件的对象时，我个人觉得，传统构造函数的方式很快就会让你陷入泥潭。最常见的问题就是所谓的“伸缩构造器”（telescoping constructor anti-pattern）。设想一下，一个

Car

登录后复制

对象可能有颜色、引擎类型、座椅材质、轮毂样式、导航系统、天窗等等。如果你想提供所有可能的组合，你会写出这样的构造函数：

Car(Color c, EngineType et)

登录后复制

Car(Color c, EngineType et, SeatMaterial sm)

登录后复制

Car(Color c, EngineType et, SeatMaterial sm, WheelStyle ws)

登录后复制

...

这简直是灾难。构造函数列表会变得异常庞大，而且随着可选参数的增加，你必须为每个参数组合创建新的构造函数。这不仅让代码量激增，更关键的是，它使得客户端代码变得难以阅读和理解。当你看到

new Car(RED, V8, LEATHER, SPORTY, true, false)

登录后复制

时，你真的能一眼看出

true

登录后复制

和

false

登录后复制

代表什么吗？这简直是“魔法值”的温床。

此外，这种方式还容易导致错误。如果你不小心调换了两个相同类型的参数的顺序，编译器可能不会报错，但你的对象就会被错误地初始化。而且，如果对象在构造后是不可变的（immutable），那么这种一次性传入所有参数的构造方式，在参数过多时，其复杂性是指数级上升的。我曾为此头疼不已，每次要添加一个新功能或新配置，都得去修改一堆构造函数，那感觉就像是在拆一个随时可能爆炸的炸弹。

j2me3D游戏开发简单教程中文WORD版

本文档主要讲述的是j2me3D游戏开发简单教程；　如今，3D图形几乎是任何一部游戏的关键部分，甚至一些应用程序也通过用3D形式来描述信息而获得了成功。如前文中所述，以立即模式和手工编码建立所有的3D对象的方式进行开发速度很慢且很复杂。应用程序中多边形的所有角点必须在数组中独立编码。在JSR 184中，这称为立即模式。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看

查看详情

建造者模式如何提升C++代码的可读性和可扩展性？

建造者模式在可读性和可扩展性方面带来的提升，在我看来是实实在在的。它改变了我们思考对象创建的方式，从“一次性全部塞进去”变成了“一步步精雕细琢”。

可读性方面：

链式调用（Fluent Interface）： 通过让建造者方法的返回值为
```
*this
```
登录后复制
，我们可以实现方法链式调用，如
```
builder->buildCPU()->buildRAM()->getResult()
```
登录后复制
。这种链式调用模式非常直观，就像在读一个句子，清晰地描述了对象的构建过程。每一个方法调用都明确指明了正在设置哪个属性，避免了传统构造函数中参数含义模糊的问题。
分步构建： 对象的创建过程被分解成一系列独立、有意义的步骤。这使得客户端代码更容易理解，因为每个步骤都有明确的语义。你不需要一次性消化所有参数，而是可以按需、按逻辑顺序来添加部件。这对于那些具有复杂依赖关系或特定构建顺序的对象来说，尤其有用。

可扩展性方面：

开闭原则的体现： 当你需要添加新的产品类型时（比如，除了
```
GamingComputer
```
登录后复制
，还需要
```
OfficeComputer
```
登录后复制
），你只需要创建新的具体建造者，而无需修改现有的
```
Computer
```
登录后复制
类或抽象建造者接口。同样，如果你需要添加新的部件（比如，增加一个
```
SoundCard
```
登录后复制
），你可以在抽象建造者中添加
```
buildSoundCard()
```
登录后复制
方法，然后所有具体建造者去实现它，或者只在需要的新建造者中实现。这种设计完美符合开闭原则，即对扩展开放，对修改关闭。
隔离构建逻辑： 建造者模式将产品的构建逻辑从产品类本身中分离出来。产品类只需要关注其内部状态和行为，而不需要知道它是如何被创建的。这种职责分离使得每个组件都更加内聚，更容易维护和测试。
灵活的产品表示： 不同的具体建造者可以以不同的方式实现相同的构建过程，从而创建出具有不同内部表示的产品。例如，一个建造者可以构建一个完整配置的电脑，另一个建造者可以构建一个只有基本配置的电脑，甚至可以构建一个模拟对象用于测试。这种灵活性是传统构造函数难以提供的。

可以说，建造者模式将复杂的对象创建逻辑封装起来，让客户端代码变得更加简洁、富有表达力。我个人非常喜欢这种模式，因为它能把一堆混乱的参数列表，整理成清晰、有条理的构建流程。

C++实现建造者模式时有哪些常见的陷阱和最佳实践？

在我实际使用建造者模式的过程中，确实遇到过一些坑，也总结了一些经验。要让这个模式发挥最大效用，同时避免引入新的复杂性，你需要注意以下几点：

常见陷阱：

过度工程化： 这大概是所有设计模式的通病。如果你的对象很简单，只有两三个参数，并且它们都是必需的，那么直接使用构造函数可能更简单明了。为简单对象引入建造者模式，反而会增加不必要的代码量和理解成本。我见过有人给一个只有
```
name
```
登录后复制
和
```
id
```
登录后复制
的类也写了建造者，这简直是杀鸡用牛刀。
建造者方法返回
void
登录后复制
或其他类型：如果你希望实现链式调用（fluent interface），那么每个
```
buildXxx
```
登录后复制
方法都必须返回
```
*this
```
登录后复制
（即建造者自身的引用或指针）。如果返回
```
void
```
登录后复制
，你就无法连续调用，失去了建造者模式的一大优势。
产品构造函数的可访问性问题： 有时为了强制客户端只能通过建造者来创建产品，我们会将产品类的构造函数设为
```
private
```
登录后复制
或
```
protected
```
登录后复制
。但这样一来，建造者就无法直接调用它了。解决方案通常是让建造者成为产品类的友元（
```
friend class
```
登录后复制
），或者产品类提供一个内部的、受保护的设置方法供建造者调用。
资源管理不当： 如果你的产品内部包含动态分配的资源（比如原始指针），那么建造者在创建这些资源时，需要确保正确的生命周期管理。在现代C++中，强烈推荐使用智能指针（如
```
std::unique_ptr
```
登录后复制
或
```
std::shared_ptr
```
登录后复制
）来管理产品实例及其内部资源，以避免内存泄漏。
遗漏
getResult()
登录后复制
调用：有时在链式调用后，会忘记调用最终的
```
getResult()
```
登录后复制
方法来获取构建好的产品对象。这会导致你拿到的是建造者本身，而不是你想要的产品。

最佳实践：

智能指针管理产品： 在建造者内部，使用
```
std::unique_ptr<Product>
```
登录后复制
来持有正在构建的产品实例。当
```
getResult()
```
登录后复制
被调用时，使用
```
std::move
```
登录后复制
将所有权转移给调用者。这确保了内存安全，并清晰地表明了产品的所有权转移。
提供默认值： 建造者方法可以提供默认参数值，或者在
```
getResult()
```
登录后复制
方法中检查未设置的必要属性并抛出异常，或提供默认配置。这让构建过程更加健壮和用户友好。
验证逻辑： 在
```
getResult()
```
登录后复制
方法中加入最终的产品验证逻辑。例如，确保所有必需的部件都已设置，或者部件之间的组合是有效的。如果验证失败，可以抛出异常或返回空指针，告知客户端构建失败。
私有化产品构造函数（可选）： 如果你真的想强制用户只能通过建造者来创建对象，可以将产品类的所有构造函数声明为
```
private
```
登录后复制
或
```
protected
```
登录后复制
，然后将建造者声明为产品类的友元。但这会增加耦合，需要权衡。
抽象建造者与具体建造者的分离： 确保抽象建造者定义了所有通用的构建步骤，而具体建造者则负责实现这些步骤的具体细节。这样可以保持良好的层次结构和职责分离。
考虑模板化建造者： 对于某些场景，如果你的产品类型有相似的构建流程，但具体部件类型不同，可以考虑使用C++模板来创建更通用的建造者，减少代码重复。