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

Как правильно реализовать фабричный метод в C ++?

Цель: дать возможность клиенту создавать экземпляры какого-либо объекта с использованием фабричных методов вместо конструкторов объекта без неприемлемых последствий и снижения производительности.

Под «шаблоном фабричного метода» я подразумеваю как статические фабричные методы внутри объекта, так и методы, определенные в другом классе, или глобальные функции. Просто в целом «концепция перенаправления обычного способа создания экземпляра класса X куда-нибудь еще, кроме конструктора».

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

---

0) Не создавайте фабрики, make конструкторы.

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

Самый простой пример, который я знаю, - это класс 2-D Vector. Так просто, но сложно. Я хочу иметь возможность построить его как из декартовых, так и полярных координат. Очевидно, я не могу:

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. Продолжайте читать.

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

---

1) Путь Java

В 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);
    }
};

Круто? Действительно, часто. Но затем - это заставляет пользователя использовать только динамическое размещение. Статическое распределение - это то, что делает C ++ сложным, но также часто делает его мощным. Кроме того, я считаю, что существуют некоторые цели (ключевое слово: embedded), которые не позволяют динамическое размещение. И это не означает, что пользователям этих платформ нравится писать чистое ООП.

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

---

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

Хорошо ... вот и все. Это некрасиво, так как нам нужно изменить имя метода. Это' s несовершенный, поскольку нам нужно писать один и тот же код дважды. Но однажды это работает. Так?

Ну, обычно. Но иногда это не так. При создании Foo мы на самом деле зависим от компилятора, который сделает оптимизацию возвращаемого значения для нас, потому что стандарт C ++ достаточно великодушен для поставщиков компилятора, чтобы не указывать, когда объект будет создан на месте и когда он будет скопирован при возврате временный объект по значению в C ++. Так что, если копировать Foo дорого, этот подход рискован.

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

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

---

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 или ссылочные переменные-члены,
• передавать аргументы конструкторам базового класса и конструкторам объектов-членов.

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

Итак: даже близко к хорошему общему решению для реализации фабрики.

---

Выводы:

Мы хотим иметь способ создания экземпляра объекта, который:

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

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

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