Builder: пошаговое создание сложных объектов

Введение

Конструкторы класса хорошо работают для относительно простых объектов с небольшим, фиксированным набором обязательных параметров — Builder решает задачу создания СЛОЖНЫХ объектов с большим количеством опциональных параметров, избегая проблемы «телескопических конструкторов» (множества перегруженных конструкторов с разным количеством параметров) и давая более читаемый, явный синтаксис создания такого объекта.

Концепция

Builder представляет процесс создания сложного объекта как последовательность отдельных, явно именованных шагов (обычно — вызовов методов, каждый устанавливающий конкретный, отдельный аспект конфигурации создаваемого объекта), завершаемую финальным вызовом, реально создающим итоговый объект из накопленной конфигурации — это особенно полезно, когда объект имеет много опциональных параметров, не все комбинации которых имеют смысл одновременно, и явное, поименованное указание только реально нужных в конкретном случае параметров значительно читаемее, чем длинный список позиционных аргументов конструктора, среди которых легко перепутать порядок или забыть передать нужное значение для конкретного, не самого очевидного параметра.

Пример кода

#include <iostream>
#include <string>
#include <optional>

class HttpRequest
{
public:
    void execute() const
    {
        std::cout << "Запрос " << m_method << " " << m_url;
        if (m_timeout) std::cout << " (timeout=" << *m_timeout << "мс)";
        std::cout << std::endl;
    }

    // Builder объявлен как friend или вложенный класс 
    friend class HttpRequestBuilder;

private:
    std::string m_method = "GET";
    std::string m_url;
    std::optional<int> m_timeout; // статья 550 цикла синтаксиса — опциональный параметр
};

class HttpRequestBuilder
{
public:
    HttpRequestBuilder &setUrl(const std::string &url) { m_request.m_url = url; return *this; } // ЦЕПОЧКА вызовов
    HttpRequestBuilder &setMethod(const std::string &method) { m_request.m_method = method; return *this; }
    HttpRequestBuilder &setTimeout(int ms) { m_request.m_timeout = ms; return *this; }

    HttpRequest build() const { return m_request; } // финальный шаг — РЕАЛЬНОЕ получение готового объекта

private:
    HttpRequest m_request;
};

int main()
{
    HttpRequest request = HttpRequestBuilder()
                               .setUrl("https://api.example.com/data")
                               .setMethod("POST")
                               .setTimeout(5000)
                               .build(); // читаемая, ЯВНАЯ цепочка — без позиционных, легко перепутываемых аргументов
    request.execute();
    return 0;
}

// Qt-идиоматичная альтернатива Builder через цепочку setter-вызовов на самом объекте
QPushButton *button = new QPushButton("Сохранить");
button->setFixedSize(120, 40);     // каждый setter — ОТДЕЛЬНЫЙ, явно именованный шаг конфигурации,
button->setEnabled(true);           // концептуально РОДСТВЕННЫЙ идее Builder, хотя без отдельного класса
button->setToolTip("Сохранить документ");

Пояснения к коду

HttpRequestBuilder показывает классическую реализацию через «fluent interface» — каждый метод (setUrl, setMethod, setTimeout) возвращает ссылку на сам builder (*this), что позволяет соединять вызовы в цепочку без необходимости каждый раз сохранять промежуточный результат в отдельной переменной, и финальный build() возвращает реально готовый, полностью сконфигурированный объект HttpRequest. Использование std::optional<int> для m_timeout показывает практичное сочетание Builder с современными возможностями C++ — опциональность параметра тайм-аута явно отражена в самом типе, а не через «магическое» значение (как -1 для «тайм-аут не указан»). Пример с обычными setter-методами Qt-виджета показывает, что идея пошаговой, явно именованной конфигурации объекта концептуально знакома и широко используется в Qt-коде даже без формального, отдельного класса Builder — хотя это не полная, классическая реализация паттерна (отсутствует финальный build(), и объект существует с самого начала, а не собирается отдельным объектом-строителем), сама идея явного, понятного конфигурирования через отдельные именованные вызовы — общая для обоих подходов.

Подводные камни

Применение Builder для объектов с небольшим, фиксированным количеством обязательных параметров, для которых обычный конструктор уже достаточно ясен и читаем — Builder оправдан именно для случаев с большим количеством ОПЦИОНАЛЬНЫХ параметров (где не каждый вызов нуждается во всех возможных настройках), и для простых объектов с 2-3 обязательными параметрами введение отдельного класса Builder добавляет код и сложность без реальной выгоды по сравнению с прямым вызовом конструктора.
Забытый вызов финального метода build(), оставляющий незавершённый, потенциально не полностью сконфигурированный объект — поскольку промежуточные вызовы методов builder’а лишь накапливают конфигурацию, не создавая итоговый, «настоящий» объект до явного финального вызова, забытый build() означает, что код просто не получит реально нужный, итоговый объект вовсе, что для языков со строгой типизацией C++ обычно обнаруживается на этапе компиляции (отсутствующая переменная нужного типа), но требует понимания этой обязательной завершающей операции.
Отсутствие валидации обязательных параметров перед финальным build(), позволяющее создать некорректно, неполно сконфигурированный объект (например, HttpRequest без установленного URL) — качественная реализация Builder должна явно проверять наличие всех действительно необходимых параметров в момент вызова build() (например, выбрасывая исключение, при попытке создать объект без обязательного URL), а не молчаливо допускать создание заведомо некорректного, неполного объекта.
Изменяемость (mutable) состояния самого Builder-объекта после вызова build(), позволяющая случайно «переиспользовать» уже использованный builder для создания второго, отличного объекта без полного, явного сброса всей предыдущей конфигурации — без явного решения о том, должен ли builder быть переиспользуемым (с методом сброса конфигурации) или одноразовым (требующим создания нового экземпляра builder для каждого нового объекта), код, неявно предполагающий одно из этих двух поведений, может неожиданно столкнуться с остатками конфигурации от предыдущего использования того же экземпляра builder.