建造者模式在C++怎么实现 分步构建复杂对象的技巧

· 日常编程 · 258565

建造者模式的核心价值在于解耦复杂对象的构建过程与表示，从而提高代码灵活性和可维护性。1. 它通过将构建步骤封装到具体建造者中，实现对构建过程的细粒度控制；2. 允许使用相同的构建流程创建不同表示的产品，如跑车和城市车；3. 避免构造函数参数爆炸问题，提升可读性和健壮性；4. 支持不可变对象的设计，确保对象一旦创建状态即固定；5. 适用于对象构造复杂多变、需要分步进行、希望避免构造函数臃肿及需创建多种产品变体的场景。

在C++中，建造者模式（Builder Pattern）的核心在于将一个复杂对象的构建过程与其表示分离，这样通过相同的构建过程可以创建不同的表示。它允许你分步构建一个复杂对象，而不是在构造函数中一次性完成所有操作，这对于那些拥有大量可选参数或构建步骤复杂的对象来说，简直是救星。

解决方案

建造者模式通常涉及几个关键角色：产品（Product）、抽象建造者（Builder）、具体建造者（ConcreteBuilder）和指挥者（Director）。

我们以构建一辆“汽车”为例。一辆汽车可以有不同的发动机、车轮和颜色。

#include 
#include 
#include 
#include  // For std::unique_ptr

// 1. 产品 (Product)
// 这是我们要构建的复杂对象
class Car {
public:
    void addPart(const std::string& part) {
        parts_.push_back(part);
    }

    void show() const {
        std::cout << "Car Parts:" << std::endl;
        for (const auto& part : parts_) {
            std::cout << "- " << part << std::endl;
        }
    }
private:
    std::vector parts_;
};

// 2. 抽象建造者 (Builder)
// 定义创建产品各个部件的接口
class CarBuilder {
public:
    virtual ~CarBuilder() = default;
    virtual void buildEngine() = 0;
    virtual void buildWheels() = 0;
    virtual void buildColor() = 0;
    virtual std::unique_ptr getResult() = 0;
};

// 3. 具体建造者 (ConcreteBuilder)
// 实现抽象建造者接口，构建和装配产品的各个部件
class SportsCarBuilder : public CarBuilder {
public:
    SportsCarBuilder() : car_(std::make_unique()) {}

    void buildEngine() override {
        car_->addPart("Powerful V8 Engine");
    }

    void buildWheels() override {
        car_->addPart("Sport Alloy Wheels");
    }

    void buildColor() override {
        car_->addPart("Racing Red Color");
    }

    std::unique_ptr getResult() override {
        return std::move(car_); // 转移所有权
    }
private:
    std::unique_ptr car_;
};

class CityCarBuilder : public CarBuilder {
public:
    CityCarBuilder() : car_(std::make_unique()) {}

    void buildEngine() override {
        car_->addPart("Economical 4-Cylinder Engine");
    }

    void buildWheels() override {
        car_->addPart("Standard Steel Wheels");
    }

    void buildColor() override {
        car_->addPart("Urban Gray Color");
    }

    std::unique_ptr getResult() override {
        return std::move(car_);
    }
private:
    std::unique_ptr car_;
};

// 4. 指挥者 (Director)
// 负责安排构建过程，它知道如何使用建造者接口来构建产品
class CarDirector {
public:
    void setBuilder(CarBuilder* builder) {
        builder_ = builder;
    }

    // 构造一个完整的汽车
    void construct() {
        if (builder_) {
            builder_->buildEngine();
            builder_->buildWheels();
            builder_->buildColor();
        }
    }
private:
    CarBuilder* builder_ = nullptr; // 不拥有所有权
};

// 客户端代码示例
/*
int main() {
    CarDirector director;

    SportsCarBuilder sportsBuilder;
    director.setBuilder(&sportsBuilder);
    director.construct();
    std::unique_ptr sportsCar = sportsBuilder.getResult();
    std::cout << "--- Sports Car ---" <show();

    std::cout << std::endl;

    CityCarBuilder cityBuilder;
    director.setBuilder(&cityBuilder);
    director.construct();
    std::unique_ptr cityCar = cityBuilder.getResult();
    std::cout << "--- City Car ---" <show();

    return 0;
}
*/

这段代码展示了如何通过不同的 

ConcreteBuilder

（

SportsCarBuilder

和 

CityCarBuilder

）以及一个 

Director

来构建不同类型的 

Car

对象。

Director

负责定义构建的顺序，而具体部件的实现则由 

Builder

负责。这样，如果你想添加一种新的汽车类型，只需要创建一个新的 

ConcreteBuilder

，而无需修改 

Director

或现有的 

Car

类。

为什么选择建造者模式？它的核心价值到底在哪？

说实话，刚开始接触建造者模式的时候，我常常会觉得它有点“大材小用”，特别是对于那些参数不多的简单对象。但当你的对象开始变得复杂，拥有十几个甚至几十个可选参数，或者构建过程本身就涉及多个步骤、条件判断时，建造者模式的价值就凸显出来了。

它的核心价值在于：

  1. 解耦构建与表示：这是最重要的。产品（

    Car

    ）只关心它有哪些部件，不关心这些部件是如何被创建和组装的。同样，构建者（

    CarBuilder

    ）只关心如何创建部件，不关心最终产品的结构。这种分离让代码更清晰，也更容易维护和扩展。

  2. 细粒度控制构建过程：你可以一步一步地构建对象，甚至可以跳过某些可选部件的构建，或者改变构建的顺序。这比一个巨大的构造函数或者一堆重载的构造函数要灵活得多。想象一下，如果一个构造函数有20个参数，其中15个是可选的，你得写多少个重载？那简直是噩梦。
  3. 创建不同表现形式：通过不同的具体建造者，你可以用相同的构建过程（比如“先装发动机，再装轮子”）来生成完全不同的产品。比如，一个建造者生成跑车，另一个生成城市通勤车，但它们都遵循“建造汽车”的基本流程。
  4. 提高可读性和健壮性：当一个对象有大量参数时，使用建造者模式可以避免“构造函数参数列表过长”的问题。每个 

    buildXxx

    方法都有清晰的命名，一看就知道它在做什么，减少了传错参数的风险。这比一堆 

    bool

    类型参数的构造函数好多了，那些 

    true, false, true, false

    简直是调试的灾难。

对我个人而言，它更像是一种“有序组装”的思维方式。你不是一次性把所有零件扔进一个黑箱子，而是有条不紊地、一步步地完成组装，每一步都清晰可见。

什么时候该用建造者模式？判断它适用场景的几个关键点

选择一个设计模式，从来不是因为它“酷”或者“流行”，而是因为它能解决你当前面临的实际问题。建造者模式也不例外。以下是我在实践中总结的一些判断点：

  1. 对象构造复杂且多变：这是最核心的判断依据。如果你的对象有大量的属性，并且这些属性的组合方式非常多，或者某些属性是可选的，那么建造者模式就非常适合。比如，一个复杂的报表生成器，可以有不同的标题、页眉、页脚、内容布局、图表类型等等，这些都可以通过建造者来灵活配置。
  2. 构造过程需要分步进行：如果构建一个对象需要一系列的步骤，并且这些步骤的顺序可能有所不同，或者某些步骤是条件性的，建造者模式就能很好地管理这种流程。例如，一个安装向导，每一步都可能根据用户的选择来决定下一步的操作。
  3. 希望避免“构造函数参数爆炸”：当一个类的构造函数参数过多，导致难以维护和理解时，建造者模式提供了一种优雅的替代方案。它将参数设置分散到多个方法中，每个方法都负责设置一部分属性，使得代码更加清晰。
  4. 需要创建不同“风味”的产品：如果你的系统需要创建同一类产品的不同变体（例如，前面提到的跑车和城市车），而这些变体在构建过程上有一些共同点，但具体实现细节不同，那么建造者模式可以帮助你抽象出共同的构建流程，同时允许不同的具体建造者实现各自的细节。
  5. 希望产品是不可变的（Immutable）：在某些场景下，你可能希望一旦对象被创建后，其状态就不能再改变。建造者模式非常适合这种需求，因为所有的配置都在构建阶段完成，一旦 

    getResult()

    被调用，返回的对象就是最终的、不可变的。

它和工厂模式的区别也值得一提。工厂模式主要是解决“创建什么”的问题，它返回的是一个特定类型的对象实例。而建造者模式解决的是“如何创建”的问题，它关注的是复杂对象的构建过程，以及如何通过这个过程来生成不同表示的对象。它们关注点不同，但有时也会配合使用。

建造者模式可能遇到的坑与局限性

任何设计模式都有它的双刃剑效应，建造者模式也不例外。我在实际项目中也踩过一些坑，或者看到别人滥用它导致代码变得更复杂。

  1. 引入额外的类和复杂度：这是最直观的缺点。为了实现建造者模式，你至少需要引入 

    Builder

    接口、一个或多个 

    ConcreteBuilder

    类，以及可选的 

    Director

    类。对于一个本身就不复杂的对象，这无疑增加了大量的样板代码和类的数量，反而让系统显得臃肿。如果你的对象只有两三个参数，直接用构造函数或者一个简单的工厂方法会更简洁。

  2. 过度设计（Over-engineering）：有时候，开发者可能过于追求“模式化”，而忽略了问题的实际复杂程度。我见过有人为只有几个字段的简单数据对象也实现了建造者模式，结果是写了更多的代码，但并没有带来任何实际的好处，反而增加了理解和维护的成本。设计模式是工具，不是目标。
  3. Director 可能会变得过于复杂：如果你的产品类型非常多，并且每种产品的构建流程差异很大，那么 

    Director

    类可能会变得非常庞大和复杂，因为它需要根据不同的 

    Builder

    来调用不同的构建方法。这可能违背了单一职责原则。在这种情况下，可能需要重新审视是否应该将 

    Director

    的职责拆分，或者考虑其他模式。

  4. 构建步骤的强耦合：虽然建造者模式旨在解耦构建过程，但如果 

    Director

    对 

    Builder

    的具体构建方法调用顺序过于依赖，或者 

    Builder

    的方法之间存在强烈的调用顺序依赖，那么修改任何一个部分都可能影响到其他部分。理想情况下，

    Builder

    的每个构建方法应该是相对独立的。

  5. 内存管理问题（在C++中）：在C++中，如果不对 

    std::unique_ptr

    或 

    std::shared_ptr

    等智能指针进行正确管理，或者不注意对象的生命周期，可能会导致内存泄漏或悬挂指针。例如，在 

    Director

    中持有原始指针 

    CarBuilder* builder_

    ，就需要确保在 

    Director

    的生命周期内，

    builder_

    指向的对象是有效的，并且其内存由外部管理。这要求开发者对C++的内存模型有清晰的理解。

我的经验是，在决定使用建造者模式之前，先问自己几个问题：这个对象真的足够复杂吗？它的构建过程真的需要分步吗？将来会有很多不同“风味”的产品出现吗？如果答案是肯定的，那么建造者模式会是你的好帮手；否则，也许更简单的方案才是最佳选择。不要为了用模式而用模式。

以上就是建造者模式在C++怎么实现 分步构建复杂对象的技巧的详细内容，更多请关注骃骐网【www.myinqi.com】。

相关推荐：

Pandas 中基于条件将数据填充到空矩阵：构建地理流动流量的二维汇总表

本文介绍如何使用 pandas 的 pivot_table 和 categorical 配合 fill_value 参数，将原始流动数据（含 origin-destination 地理编码和流量值）高效转换为指定地理单元集合的 n×n 流量矩阵，缺失组合自动补零。 本文介绍如何使用 pandas 的 pivot_table 和 categorical 配合 fill_value 参数，将原始流动数...

文本分类在Python里怎么应对新词与未登录词_使用Subword与BPE算法构建分词器

结论：subword/BPE并非解决未登录词，而是让模型无需认识整词——靠子词拼合；关键在训练与下游任务的tokenization逻辑对齐。 直接说结论：用 subword 或 BPE 不是“解决”未登录词，而是让模型根本不需要“认识”整词——它靠子词拼出来。关键不在分词器本身多聪明，而在训练时是否对齐了 subword 切分与下游任务的 tokenization 逻辑。 为什么 jieba / ...

如何在Python中实现异步定时任务_使用asyncio.sleep构建高精度循环调度

asyncio.sleep比time.sleep更适合异步定时循环，因为前者是协程，只挂起当前任务并让出控制权，后者是同步阻塞函数，会卡死整个事件循环；实操中必须用await asyncio.sleep(n)，且需用绝对时间锚点避免调度漂移。 asyncio.sleep 为什么比 time.sleep 更适合异步定时循环 因为 time.sleep 是同步阻塞的，会直接卡住整个事件循环；而 asy...

Python中Scikit-learn如何构建机器学习流水线_使用Pipeline简化流程

Pipeline的核心作用是防止数据泄露、避免训练/预测不一致、减少重复代码；其fit()在每次交叉验证fold内仅用当前fold训练子集拟合scaler，杜绝跨fold信息泄露。 直接说结论：用 Pipeline 不是为了“看起来更专业”，而是为了堵住数据泄露、避免训练/预测不一致、减少重复代码这三类高频生产事故。 为什么 Pipeline 调用 fit() 时不会提前泄露测试集信息 关键在执行...

Python怎么实现优先级队列_利用heapq模块构建最小堆逻辑

直接用heapq不能当优先级队列用，因其仅提供堆操作原语，不支持更新优先级、按值删除或最大堆；常见错误是直接插入(priority, item)元组而item不可比较，导致TypeError。 为什么直接用 heapq 不能当优先级队列用 因为 heapq 只提供堆操作原语（如 heappush、heappop），不封装成带优先级的队列类；它本身不支持「按优先级自动排序 + 支持重复元素 + 允许...

Python如何实现广度优先搜索BFS_基于collections.deque构建队列

为什么不用list而要用deque实现BFS队列 因为list.pop(0)是O(n)操作，每次从头部弹出都会移动后面所有元素；而deque.popleft()是O(1)，BFS频繁出入队时性能差距会指数级放大。实测10万节点图上，list版本可能卡顿数秒，deque几乎瞬时完成。 常见错误是写成queue = []; queue.pop(0)，尤其新手从循环队列概念直接套用列表索引，结果在稍大规...

如何在Python中实现自编码器进行数据去噪_构建Keras编码解码结构

根本原因是输入尺度与激活函数不匹配：未归一化的0–255像素输入与sigmoid（0–1输出）或relu（截断负值）搭配，导致梯度消失、动态范围失真；需归一化输入、合理选择末层激活与损失函数，并避免隐层用softmax破坏特征解耦。 为什么用 tf.keras.layers.Dense 搭自编码器容易出错 直接堆叠全连接层做去噪自编码器，常出现重建模糊、噪声残留严重，甚至输出全为均值——根本原因是...

CSS怎么制作框架_CSS框架设计与布局系统构建教程

答案是自定义CSS框架通过量身定制、模块化设计提升开发效率与性能。它以原子化设计为理念，包含重置样式、布局系统、组件库、工具类等核心部分，采用BEM等规范确保可维护性，结合Flexbox与Grid实现灵活响应式布局，并需规避过度设计、命名混乱、缺乏文档等常见问题，最终实现轻量化、高内聚、易扩展的样式解决方案。 制作CSS框架，本质上是为你的项目量身定制一套可复用、模块化的样式和组件集合，它能极大地...

构建基于 FastAPI 的三层架构：多服务协同处理复杂端点

在 FastAPI 中实现三层架构，特别是处理需要多个服务协同的复杂端点时，如何有效地组织代码至关重要。本文将深入探讨两种方案，并提供选择合适方案的指导，以实现更好的可维护性和可扩展性。 三层架构概述 三层架构是一种常见的软件设计模式，它将应用程序分为三个逻辑层： 表示层（Presentation Layer）： 负责用户交互，例如 FastAPI 中的端点定义。 应用层（Application ...