Во-первых, бывают случаи, когда построение объекта - задача достаточно сложная, чтобы оправдать его извлечение в другой класс.

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

Vec2(float x, float y);
Vec2(float angle, float magnitude); // not a valid overload!

Для этого есть простой способ:

struct Cartesian {
  inline Cartesian(float x, float y): x(x), y(y) {}
  float x, y;
};
struct Polar {
  inline Polar(float angle, float magnitude): angle(angle), magnitude(magnitude) {}
  float angle, magnitude;
};
Vec2(const Cartesian &cartesian);
Vec2(const Polar &polar);

Единственный минус в том, что это выглядит многословно:

Vec2 v2(Vec2::Cartesian(3.0f, 4.0f));

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

Что касается типа распределения, основной причиной использования фабричного шаблона обычно является полиморфизм. Конструкторы не могут быть виртуальными, и даже если бы они могли, в этом не было бы особого смысла. При использовании статического или стекового распределения вы не можете создавать объекты полиморфным способом, потому что компилятор должен знать точный размер. Так что он работает только с указателями и ссылками. И возврат ссылки из фабрики тоже не работает, потому что, хотя объект технически можно удалить по ссылке, это может быть довольно запутанным и подверженным ошибкам, см. Является ли практика возврата ссылочной переменной C ++ злом?, например, . Таким образом, указатели - это единственное, что осталось, включая интеллектуальные указатели. Другими словами, фабрики наиболее полезны при использовании с динамическим распределением, поэтому вы можете делать такие вещи, как это:

class Abstract {
  public:
    virtual void do() = 0;
};

class Factory {
  public:
    Abstract *create();
};

Factory f;
Abstract *a = f.create();
a->do();

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

Простой заводской пример:

// Factory returns object and ownership
// Caller responsible for deletion.
#include <memory>
class FactoryReleaseOwnership{
  public:
    std::unique_ptr<Foo> createFooInSomeWay(){
      return std::unique_ptr<Foo>(new Foo(some, args));
    }
};

// Factory retains object ownership
// Thus returning a reference.
#include <boost/ptr_container/ptr_vector.hpp>
class FactoryRetainOwnership{
  boost::ptr_vector<Foo>  myFoo;
  public:
    Foo& createFooInSomeWay(){
      // Must take care that factory last longer than all references.
      // Could make myFoo static so it last as long as the application.
      myFoo.push_back(new Foo(some, args));
      return myFoo.back();
    }
};

Вы думали о том, чтобы вообще не использовать фабрику, а вместо этого хорошо использовать систему типов? Я могу придумать два разных подхода, которые делают такие вещи:

Вариант 1:

struct linear {
    linear(float x, float y) : x_(x), y_(y){}
    float x_;
    float y_;
};

struct polar {
    polar(float angle, float magnitude) : angle_(angle),  magnitude_(magnitude) {}
    float angle_;
    float magnitude_;
};


struct Vec2 {
    explicit Vec2(const linear &l) { /* ... */ }
    explicit Vec2(const polar &p) { /* ... */ }
};

Что позволяет писать такие вещи, как:

Vec2 v(linear(1.0, 2.0));

Вариант 2:

вы можете использовать «теги», как это делает STL с итераторами и т.п. Например:

struct linear_coord_tag linear_coord {}; // declare type and a global
struct polar_coord_tag polar_coord {};

struct Vec2 {
    Vec2(float x, float y, const linear_coord_tag &) { /* ... */ }
    Vec2(float angle, float magnitude, const polar_coord_tag &) { /* ... */ }
};

Этот второй подход позволяет писать код, который выглядит следующим образом:

Vec2 v(1.0, 2.0, linear_coord);

что также приятно и выразительно, позволяя создавать уникальные прототипы для каждого конструктора.

Вы можете прочитать очень хорошее решение в: http://www.codeproject.com/Articles/363338/Factory-Pattern-in-Cplusplus

Лучшее решение - в «комментариях и обсуждениях», см. «Нет необходимости в статических методах создания».

Из этой идеи я сделал фабрику. Обратите внимание, что я использую Qt, но вы можете изменить QMap и QString для эквивалентов std.

#ifndef FACTORY_H
#define FACTORY_H

#include <QMap>
#include <QString>

template <typename T>
class Factory
{
public:
    template <typename TDerived>
    void registerType(QString name)
    {
        static_assert(std::is_base_of<T, TDerived>::value, "Factory::registerType doesn't accept this type because doesn't derive from base class");
        _createFuncs[name] = &createFunc<TDerived>;
    }

    T* create(QString name) {
        typename QMap<QString,PCreateFunc>::const_iterator it = _createFuncs.find(name);
        if (it != _createFuncs.end()) {
            return it.value()();
        }
        return nullptr;
    }

private:
    template <typename TDerived>
    static T* createFunc()
    {
        return new TDerived();
    }

    typedef T* (*PCreateFunc)();
    QMap<QString,PCreateFunc> _createFuncs;
};

#endif // FACTORY_H

Пример использования:

Factory<BaseClass> f;
f.registerType<Descendant1>("Descendant1");
f.registerType<Descendant2>("Descendant2");
Descendant1* d1 = static_cast<Descendant1*>(f.create("Descendant1"));
Descendant2* d2 = static_cast<Descendant2*>(f.create("Descendant2"));
BaseClass *b1 = f.create("Descendant1");
BaseClass *b2 = f.create("Descendant2");

Я в основном согласен с принятым ответом, но есть вариант C ++ 11, который не был рассмотрен в существующих ответах:

• Возвращает результаты фабричного метода по значению и
• Предоставьте дешевый конструктор перемещения.

Пример:

struct sandwich {
  // Factory methods.
  static sandwich ham();
  static sandwich spam();
  // Move constructor.
  sandwich(sandwich &&);
  // etc.
};

Затем вы можете создавать объекты в стеке:

sandwich mine{sandwich::ham()};

В качестве подобъектов прочего:

auto lunch = std::make_pair(sandwich::spam(), apple{});

Или динамически выделяется:

auto ptr = std::make_shared<sandwich>(sandwich::ham());

Когда я могу это использовать?

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

Я говорю «может», потому что это зависит от того, какой подход дает наиболее четкий код, не будучи излишне неэффективным.

У Локи есть как Factory Method, так и Абстрактная фабрика. Оба они подробно описаны в книге Modern C ++ Design Андея Александреску. Фабричный метод, вероятно, ближе к тому, что вам кажется после, хотя он все же немного отличается (по крайней мере, если память обслуживает, он требует, чтобы вы зарегистрировали тип, прежде чем фабрика сможет создавать объекты этого типа).

Я не пытаюсь отвечать на все свои вопросы, поскольку считаю, что они слишком общие. Пара замечаний:

бывают случаи, когда построение объекта - задача достаточно сложная, чтобы оправдать его выделение в другой класс.

Фактически, этот класс является Builder, а не Factory.

В общем случае я не хочу заставлять пользователей фабрики ограничиваться динамическим распределением.

Затем вы можете заставить фабрику инкапсулировать его в интеллектуальный указатель. Я считаю, что таким образом ты можешь съесть свой торт и съесть его.

Это также устраняет проблемы, связанные с возвратом по стоимости.

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

Действительно. Все шаблоны проектирования имеют свои (зависящие от языка) ограничения и недостатки. Их рекомендуется использовать только тогда, когда они помогают решить вашу проблему, а не ради них самих.

Если вам нужна «идеальная» реализация фабрики, удачи.

Это мое решение в стиле С ++ 11. параметр base предназначен для базового класса всех подклассов. Создатели, являются объектами std :: function для создания экземпляров подкласса, могут быть привязкой к вашему подклассу 'static member function' create (some args) '. Возможно, это не идеально, но для меня работает. И это своего рода «общее» решение.

template <class base, class... params> class factory {
public:
  factory() {}
  factory(const factory &) = delete;
  factory &operator=(const factory &) = delete;

  auto create(const std::string name, params... args) {
    auto key = your_hash_func(name.c_str(), name.size());
    return std::move(create(key, args...));
  }

  auto create(key_t key, params... args) {
    std::unique_ptr<base> obj{creators_[key](args...)};
    return obj;
  }

  void register_creator(const std::string name,
                        std::function<base *(params...)> &&creator) {
    auto key = your_hash_func(name.c_str(), name.size());
    creators_[key] = std::move(creator);
  }

protected:
  std::unordered_map<key_t, std::function<base *(params...)>> creators_;
};

Пример по использованию.

class base {
public:
  base(int val) : val_(val) {}

  virtual ~base() { std::cout << "base destroyed\n"; }

protected:
  int val_ = 0;
};

class foo : public base {
public:
  foo(int val) : base(val) { std::cout << "foo " << val << " \n"; }

  static foo *create(int val) { return new foo(val); }

  virtual ~foo() { std::cout << "foo destroyed\n"; }
};

class bar : public base {
public:
  bar(int val) : base(val) { std::cout << "bar " << val << "\n"; }

  static bar *create(int val) { return new bar(val); }

  virtual ~bar() { std::cout << "bar destroyed\n"; }
};

int main() {
  common::factory<base, int> factory;

  auto foo_creator = std::bind(&foo::create, std::placeholders::_1);
  auto bar_creator = std::bind(&bar::create, std::placeholders::_1);

  factory.register_creator("foo", foo_creator);
  factory.register_creator("bar", bar_creator);

  {
    auto foo_obj = std::move(factory.create("foo", 80));
    foo_obj.reset();
  }

  {
    auto bar_obj = std::move(factory.create("bar", 90));
    bar_obj.reset();
  }
}

Заводской узор

class Point
{
public:
  static Point Cartesian(double x, double y);
private:
};

И если ваш компилятор не поддерживает оптимизацию возвращаемого значения, откажитесь от нее, вероятно, он вообще не содержит большой оптимизации ...

Я знаю, что на этот вопрос был дан ответ 3 года назад, но, возможно, это именно то, что вы искали.

Пару недель назад Google выпустил библиотеку, позволяющую легко и гибко размещать динамические объекты. Вот он: http://google-opensource.blogspot.fr/2014/01/introduction-infact-library.html