【发布时间】：2011-07-04 11:52:05
【问题描述】：
在 C++ 中有一件事情让我很长时间以来都感到不舒服，因为我真的不知道该怎么做，尽管这听起来很简单：
如何在 C++ 中正确实现工厂方法？
目标：允许客户端使用工厂方法而不是对象的构造函数来实例化某些对象，而不会产生不可接受的后果和性能损失。
“工厂方法模式”是指对象内部的静态工厂方法或在另一个类中定义的方法，或全局函数。只是一般“将类 X 的常规实例化方式重定向到构造函数以外的任何地方的概念”。
让我浏览一下我想到的一些可能的答案。
0) 不要制造工厂，要制造构造器。
这听起来不错（实际上通常是最好的解决方案），但不是一般的补救措施。首先，在某些情况下，对象构造是一项复杂到足以证明将其提取到另一个类的任务。但是即使把这个事实放在一边，即使对于简单的对象来说，只使用构造函数通常也行不通。
我知道的最简单的例子是二维向量类。如此简单，却又很棘手。我希望能够从笛卡尔坐标和极坐标中构建它。显然，我做不到：
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 的两个不透明 typedef（例如不相关域的 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++ 变得复杂，但也常常使它变得强大。另外，我相信存在一些不允许动态分配的目标（关键字：嵌入式）。这并不意味着这些平台的用户喜欢编写干净的 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 中，对于上面的代码，不可复制不再是问题）
结论：通过返回对象来制造工厂确实是某些情况下的解决方案（例如前面提到的二维向量），但仍然不是构造函数的一般替代品。
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或引用成员变量， - 将参数传递给基类构造函数和成员对象构造函数。
可能还有一些我现在想不出的缺点，而且我什至不觉得特别有义务，因为上面的要点已经说服了我。
所以：甚至还没有一个很好的实现工厂的通用解决方案。
结论：
我们希望有一种对象实例化方式：
- 无论分配如何，都允许统一实例化，
- 为构造方法提供不同的、有意义的名称（因此不依赖于参数重载），
- 不会引入显着的性能损失，最好是显着的代码膨胀损失，尤其是在客户端，
- 笼统，如：可以为任何类引入。
我相信我已经证明我提到的方法不能满足这些要求。
有什么提示吗？请给我一个解决方案，我不想认为这种语言不允许我正确实现这样一个微不足道的概念。
【问题讨论】：
-
@Zac，虽然标题很相似，但实际问题恕我直言不同。
-
很好的副本，但 this 问题的文字本身就很有价值。
-
问这个问题两年后，我有几点要补充：1) 这个问题与几种设计模式（[抽象]工厂，建造者，你说出来，我不喜欢深入研究他们的分类）。 2) 这里讨论的实际问题是“如何将对象存储分配与对象构造完全分离？”。
-
@Dennis：除非你不
delete它。这些方法非常好，只要它是“记录的”（源代码是文档;-)）调用者拥有指针的所有权（阅读：负责在适当的时候删除它）。 -
@Boris @Dennis 你也可以通过返回
unique_ptr<T>而不是T*来使其非常明确。
标签： c++ design-patterns idioms factory-method