Шаблон построителя: убедитесь, что объект полностью построен

Отказ от ответственности: это всего лишь быстрый снимок, но я надеюсь, что он даст вам представление о том, что вам нужно.

Если вы хотите, чтобы это была ошибка времени компилятора, компилятор должен знать о текущих установленных параметрах на каждом этапе построения. Этого можно добиться, имея отдельный тип для каждой комбинации установленных в данный момент параметров.

template <unsigned CurrentSet>
class NodeBuilderTemplate

Это делает установленные параметры частью типа NodeBuilder; CurrentSet используется как битовое поле. Теперь вам нужно немного для каждого доступного параметра:

enum
{
    Description = (1 << 0),
    Name = (1 << 1),
    Value = (1 << 2)
};

Вы начинаете с NodeBuilder, для которого не заданы параметры:

typedef NodeBuilderTemplate<0> NodeBuilder;

И каждый установщик должен возвращать новый NodeBuilder с соответствующим битом, добавленным в битовое поле:

NodeBuilderTemplate<CurrentSet | BuildBits::Description> withDescription(std::string description)
{
    NodeBuilderTemplate nextBuilder = *this;
    nextBuilder.m_description = std::move(description);
    return nextBuilder;
}

Теперь вы можете использовать static_assert в своей функции build, чтобы убедиться, что CurrentSet показывает правильную комбинацию установленных параметров:

Node build()
{
    static_assert(
        ((CurrentSet & (BuildBits::Description | BuildBits::Name)) == (BuildBits::Description | BuildBits::Name)) ||
        (CurrentSet & BuildBits::Value),
        "build is not allowed yet"
    );

    // build a node
}

Это вызовет ошибку времени компиляции всякий раз, когда кто-то попытается вызвать build() для NodeBuilder, в котором отсутствуют некоторые параметры.

Пример выполнения: http://coliru.stacked-crooked.com/a/8ea8eeb7c359afc5.

В итоге я использовал шаблоны для возврата разных типов и имел метод сборки только для окончательного типа. Однако он делает копии каждый раз, когда вы устанавливаете параметр:

(используя код от Horstling, но модифицированный так, как я это сделал)

template<int flags = 0>
class NodeBuilder {

  template<int anyflags>
  friend class NodeBuilder;
  enum Flags {
    Description,
    Name,
    Value,
    TotalFlags
  };

 public:
  template<int anyflags>
  NodeBuilder(const NodeBuilder<anyflags>& cpy) : m_buildingNode(cpy.m_buildingNode) {};

  template<int pos>
  using NextBuilder = NodeBuilder<flags | (1 << pos)>;

  //The && at the end is import so you can't do b.withDescription() where b is a lvalue.
  NextBuilder<Description> withDescription( string desc ) && {
    m_buildingNode.description = desc;
    return *this;
  }
  //other with* functions etc...

  //needed so that if you store an incomplete builder in a variable,
  //you can easily create a copy of it. This isn't really a problem
  //unless you have optional values
  NodeBuilder<flags> operator()() & {
    return NodeBuilder<flags>(*this);
  }

  //Implicit cast from node builder to node, but only when building is complete
  operator typename std::conditional<flags == (1 << TotalFlags) - 1, Node, void>::type() {
    return m_buildingNode;
  }
 private:
  Node m_buildingNode;
};

Так, например:

NodeBuilder BaseNodeBuilder = NodeBuilder().withDescription(" hello world");

Node n1 = BaseNodeBuilder().withName("Foo"); //won't compile
Node n2 = BaseNodeBuilder().withValue("Bar").withName("Bob"); //will compile

_{Отказ от ответственности: это идея. Я даже не уверен, что это работает. Просто поделился.}

Вы можете попробовать:

• удалить build() метод из NodeBuilder
• перегруппируйте свои обязательные поля в единый метод построения NodeBuilder, скажем, NodeBuilder::withFieldData(bla, bli, blu) и/или NodeBuilder::withFieldData(structBliBlaBLU).
• make withFieldData(), чтобы вернуть строитель другого типа, скажем, NodeBuilderFinal. Только этот тип строителя имеет метод build(). Вы можете наследовать необязательные методы от NodeBuilder. (Строго говоря, NodeBuilderFinal — это «прокси-объект»)

Это заставит пользователя вызывать withFieldData() перед build(), позволяя вызывать другие методы компоновщика в произвольном порядке. Любая попытка вызвать build() для нефинального компоновщика вызовет ошибку компилятора. build() метод не будет отображаться в автодополнении, пока не будет сделан окончательный билдер ;).

Если вам не нужен монолитный метод withFieldData, вы можете вернуть разные прокси из каждого "полевого" метода, например NodeBuilderWithName, NodeBuilderWithFile, и из них вы можете вернуть NodeBuilderWithNameAndFile и т. д., пока не будет построен окончательный билдер. Это довольно сложно и потребует введения множества классов для покрытия различных порядков "полевых" вызовов. Подобно тому, что @ClaasBontus предложил в комментариях, вы, вероятно, можете обобщить и упростить это с помощью шаблонов.

Теоретически вы можете попытаться применить более сложные ограничения, введя в цепочку больше прокси-объектов.

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

Это позволит проверять время компиляции, но за счет гораздо более сложного API, поэтому я настоятельно рекомендую вам не использовать его, если у вас действительно нет веских причин для этого.

Этот вопрос не может быть устаревшим. Поделюсь своим решением этой проблемы.

class Car; //object of this class should be constructed

struct CarParams{
protected:
    std::string name_;
    std::string model_;
    int numWheels_;
    int color_;

    struct Setter_model;
    struct Setter_numWheels;
    struct Setter_color;

public:    
    class Builder;
};

struct CarBuilder : CarParams{ //starts the construction
    Setter_model& set_name(const std::string& name){
        name_ = name;
        return reinterpret_cast<Setter_model&>(*this);
    }
};

struct CarParams::Setter_model : CarParams{
    Setter_numWheels& set_model(const std::string& model){
        model_ = model;
        return reinterpret_cast<Setter_numWheels&>(*this);
    }
};

struct CarParams::Setter_numWheels : CarParams{
    Setter_color& set_numWheels(int numWheels){
        numWheels_ = numWheels;
        return reinterpret_cast<Setter_color&>(*this);
    }
};

struct CarParams::Setter_color : CarParams{
    Builder& set_color(int color){
        color_ = color;
        return reinterpret_cast<Builder&>(*this);
    }
};

class CarParams::Builder : CarParams{
private:
    //private functions
public:
    Car* build();
    // optional parameters

};

class Car определяется ниже:

class Car{
private:
    std::string name_;
    std::string model_;
    int numWheels_;
    int color_;

public:
    friend class CarParams::Builder;
    //other functions
};

И функция build в .cpp:

Car* CarParams::Builder::build(){
    Car* obj = new Car;
    obj->name_ = std::move(name_);
    obj->model_ = std::move(model_);
    obj->numWheels_ = numWheels_;
    obj->color_ = color_;
    return obj;
}

Может быть, это немного сложно, но выглядит красиво на стороне клиента:

  std::string name = "Name";
  std::string model = "Model";

  Car* newCar = CarBuilder()
                .set_name(name)
                .set_model(model)
                .set_numWheels(3)
                .set_color(0x00ffffff)
                .build();

Ошибка возникнет во время компиляции, если вы пропустите что-то до build(). Еще одним недостатком является строгий порядок аргументов. Его можно комбинировать с необязательными параметрами.