Є одна річ у С ++, яка змушує мене відчувати себе незручно досить довго, тому що я, чесно кажучи, не знаю, як це зробити, хоча це звучить просто:

Як правильно реалізувати заводський метод у C ++?

Мета: зробити можливим дозволити клієнтові інстанціювати який-небудь об’єкт за допомогою заводських методів замість конструкторів об'єкта без неприпустимих наслідків та досягнень ефективності.

Під "Заводським методом" я маю на увазі як статичні заводські методи всередині об'єкта, або методи, визначені в іншому класі, або глобальні функції. Просто загалом "концепція перенаправлення нормального способу інстанції класу X на інше місце, ніж конструктор".

Дозвольте мені проглянути кілька можливих відповідей, які я придумав.

0) Не робіть фабрик, не робіть конструкторів.

Це звучить приємно (і дійсно часто найкраще рішення), але не є загальним засобом. Перш за все, бувають випадки, коли побудова об'єкта є завданням досить складним, щоб виправдати його вилучення до іншого класу. Але навіть відкладати цей факт убік, навіть для простих об'єктів, що використовують лише конструктори, часто не обійдеться.

Найпростіший приклад, який я знаю, - це 2-D клас вектора. Так просто, але все ж хитро. Я хочу мати можливість побудувати це як з декартових, так і з полярних координат. Очевидно, я не можу:

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

Мій природний спосіб мислення тоді:

struct Vec2 {
    static Vec2 fromLinear(float x, float y);
    static Vec2 fromPolar(float angle, float magnitude);
    // ...
};

Що замість конструкторів призводить мене до використання статичних заводських методів ... що по суті означає, що я певним чином реалізую заводський зразок ("клас стає власною фабрикою"). Це виглядає добре (і підходить саме для цього конкретного випадку), але в деяких випадках не вдається, що я збираюся описати у пункті 2. Читай далі.

інший випадок: намагаючись перевантажити двома непрозорими typedefs деякого API (наприклад, GUID непов'язаних доменів або GUID та бітфілд), типи семантично абсолютно різні (так - теоретично - дійсні перевантаження), але які фактично виявляються те саме - як неподписані вставки або недійсні покажчики.

1) Шлях Яви

У Java це просто, оскільки у нас є лише динамічно виділені об'єкти. Зробити фабрику так само тривіально, як:

class FooFactory {
    public Foo createFooInSomeWay() {
        // can be a static method as well,
        //  if we don't need the factory to provide its own object semantics
        //  and just serve as a group of methods
        return new Foo(some, args);
    }
}

У програмі C ++ це означає:

class FooFactory {
public:
    Foo* createFooInSomeWay() {
        return new Foo(some, args);
    }
};

Класно? Часто, справді. Але потім - це змушує користувача використовувати тільки динамічне розподілення. Статичний розподіл - це те, що робить С ++ складним, але також є тим, що часто робить його потужним. Також я вважаю, що існують деякі цілі (ключове слово: вбудовані), які не дозволяють динамічно розподіляти. І це не означає, що користувачі цих платформ люблять писати чистий OOP.

У будь-якому випадку, філософія вбік: У загальному випадку я не хочу змушувати користувачів фабрики стримуватися до динамічного розподілу.

2) Повернення за вартістю

Гаразд, тому ми знаємо, що 1) круто, коли ми хочемо динамічного розподілу. Чому ми не додамо статичного розподілу поверх цього?

class FooFactory {
public:
    Foo* createFooInSomeWay() {
        return new Foo(some, args);
    }
    Foo createFooInSomeWay() {
        return Foo(some, args);
    }
};

Що? Ми не можемо перевантажити тип повернення? О, звичайно, ми не можемо. Тож давайте змінимо назви методів, щоб це відобразити. І так, я написав приклад невірного коду вище, щоб лише підкреслити, наскільки мені не подобається необхідність зміни назви методу, наприклад, тому що ми не можемо правильно реалізувати мовно-агностичний заводський дизайн, оскільки ми маємо змінити назви - і кожен користувач цього коду повинен пам’ятати про відмінність реалізації від специфікації.

class FooFactory {
public:
    Foo* createDynamicFooInSomeWay() {
        return new Foo(some, args);
    }
    Foo createFooObjectInSomeWay() {
        return Foo(some, args);
    }
};

Гаразд ... там у нас це є. Це некрасиво, оскільки нам потрібно змінити назву методу. Це недосконало, оскільки нам потрібно написати один і той же код двічі. Але як тільки зроблено, це працює. Правильно?

Ну зазвичай. Але іноді цього немає. Створюючи Foo, ми фактично залежаємо від компілятора, щоб зробити для нас оптимізацію повернутого значення, оскільки стандарт C ++ є доброзичливим, щоб постачальники компілятора не вказували, коли буде створений об'єкт на місці і коли він буде скопійований при поверненні тимчасовий об'єкт за значенням у C ++. Отже, якщо Foo копіювати дорого, такий підхід ризикований.

А що робити, якщо Foo взагалі не піддається контролю? Ну, а. ( Зауважте, що в C ++ 17 із гарантованим зменшенням копіювання копія, яка не підлягає копіюванню, вже не є проблемою для коду вище )

Висновок: Створення фабрики шляхом повернення об'єкта справді є рішенням для деяких випадків (наприклад, 2-D вектора, який вже згадувався), але все ще не є загальною заміною для конструкторів.

3) Двофазна конструкція

Інша річ, яку хтось, мабуть, придумає - це розділити питання розподілу об'єктів та його ініціалізацію. Зазвичай це призводить до такого коду:

class Foo {
public:
    Foo() {
        // empty or almost empty
    }
    // ...
};

class FooFactory {
public:
    void createFooInSomeWay(Foo& foo, some, args);
};

void clientCode() {
    Foo staticFoo;
    auto_ptr<Foo> dynamicFoo = new Foo();
    FooFactory factory;
    factory.createFooInSomeWay(&staticFoo);
    factory.createFooInSomeWay(&dynamicFoo.get());
    // ...
}

Можна подумати, що це працює як шарм. Єдина ціна, яку ми платимо в нашому коді ...

Оскільки я все це написав і залишив це як останнє, я теж мушу не любити це. :) Чому?

Перш за все ... я щиро не люблю концепцію двофазної конструкції і відчуваю провину, коли її використовую. Якщо я проектую свої об’єкти із твердженням, що "якщо він існує, він знаходиться у дійсному стані", я вважаю, що мій код безпечніший і менш схильний до помилок. Мені це подобається.

Домогтися відмови від цієї конвенції І зміни дизайну мого об'єкта лише для того, щоб зробити з нього фабрику - це, ну, непросто.

Я знаю, що вищесказане не переконає багатьох людей, тому дозвольмо навести ще більш ґрунтовні аргументи. Використовуючи двофазну конструкцію, ви не можете:

• ініціалізація constабо довідкові змінні члена,
• передавати аргументи конструкторам базового класу та конструкторам об'єктів-членів.

І, ймовірно, можуть бути ще деякі недоліки, про які я зараз не можу подумати, і я навіть не відчуваю особливого зобов’язання, оскільки перераховані вище пункти кулі вже мене переконують.

Отже: навіть близько до хорошого загального рішення щодо впровадження фабрики.

Висновки:

Ми хочемо створити спосіб об'єкта, який би:

• допускати рівномірне встановлення даних незалежно від розподілу,
• давати різні, значущі назви методам побудови (таким чином, не покладаючись на перевантаження аргументами),
• не вводити значне звернення до продуктивності та, бажано, значне звернення до коду, особливо на стороні клієнта,
• бути загальним, як і в: можливо ввести для будь-якого класу.

Я вважаю, що я довів, що вказані нами способи не відповідають цим вимогам.

Якісь підказки? Будь ласка, надайте мені рішення, я не хочу думати, що ця мова не дозволить мені належним чином реалізувати таку банальну концепцію.

Перш за все, бувають випадки, коли побудова об'єкта є завданням досить складним, щоб виправдати його вилучення до іншого класу.

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

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 щоб уникнути копіювання накладних даних.

Що стосується типу виділення, то основною причиною використання заводської схеми зазвичай є поліморфізм. Конструктори не можуть бути віртуальними, і навіть якби вони могли, це не мало б сенсу. Під час використання статичного або розподілу стеків ви не можете створювати об'єкти в поліморфному вигляді, оскільки компілятору необхідно знати точний розмір. Так це працює лише з покажчиками та посиланнями. І повернення посилання з фабрики теж не працює, оскільки хоча об'єкт технічно можна видалити за допомогою посилання, він може бути досить заплутаним і схильним до помилок, див .наприклад. Отже, покажчики - це єдине, що залишилося, і це включає також і розумні вказівники. Іншими словами, фабрики найкорисніші при використанні з динамічним розподілом, тому ви можете робити такі дії:

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");

Я в основному погоджуюся з прийнятою відповіддю, але є варіант С ++ 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());

Коли я можу це використати?

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

Я кажу: " може ", оскільки це залежить від того, який підхід дає найясніший код, не будучи зайвим неефективним.

У Локі є і заводський метод, і абстрактний завод . Обидва вони задокументовані (в значній мірі) в сучасному дизайні C ++ , Андєєм Александреску. Фабричний метод, ймовірно, ближчий до того, що вам здається після, хоча він все-таки дещо інший (принаймні, якщо пам'ять служить, вона вимагає, щоб ви зареєстрували тип, перш ніж фабрика зможе створити об'єкти цього типу).

Я не намагаюся відповісти на всі мої запитання, оскільки вважаю це занадто широким. Всього кілька приміток:

бувають випадки, коли побудова об'єкта є завданням досить складним, щоб обґрунтувати його вилучення до іншого класу.

Цей клас насправді є будівельником , а не фабрикою.

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

Тоді ви могли б фабрику інкапсулювати в розумний покажчик. Я вірю, що таким чином ви можете мати свій торт і з'їсти його теж.

Це також усуває проблеми, пов'язані з рентабельністю.

Висновок: Створення фабрики шляхом повернення об'єкта справді є рішенням для деяких випадків (наприклад, 2-D вектора, який вже згадувався), але все ще не є загальною заміною для конструкторів.

Справді. Усі шаблони дизайну мають свої (мовні) обмеження та недоліки. Використовувати їх рекомендується лише тоді, коли вони допоможуть вам вирішити вашу проблему, а не заради них самих.

Якщо ви після «ідеальної» фабричної реалізації, добре, удачі.

Це моє рішення у стилі c ++ 11. Параметр 'base' призначений для базового класу всіх підкласів. творці, об'єкти функції std :: для створення екземплярів підкласу можуть бути прив'язкою до вашого підкласу 'статична функція члена' створити (деякі аргументи) '. Це, можливо, не ідеально, але працює для мене. І це якесь «загальне» рішення.

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/introducing-infact-library.html