Scott Meyers建议偏爱非成员非朋友方法是否适用于对象构建？

Question

假设我有一节课：

class C{
  int x_;
  int y_;
public:
  C(int x, int y): x_(x), y_(y){}
};

然后我想从一个字符串添加构造，它只会解析x和y 。 在阅读迈耶斯的书之前，我通常会将它作为C另一个构造函数。 但是，它也可以使其成为非会员非朋友：

C CFromString(const std::string& s){
  int x, y;
  //...parse them somehow, throw exception if needed...
  return C(x,y);
}

对我来说，这是许多“值类”的标准情况，当有一个“主”构造函数将私有成员设置为提供的值（可能检查正确性）。 这些类的其他构造函数通常只是从其他一些参数计算这些值。

在我的例子中，使这样的构造函数成为非成员非朋友有什么缺点吗？

UPD。 我理解Meyers的建议，以及NMNF功能的优点。 在他的书中没有关于NMNF对象构造的例子，所以我想确保他的建议也适用于建筑。

Answer 1

如果您开始为每个可能的方式添加构造函数，可以序列化类，那么您将该类与这些序列化方法紧密耦合。

您最好将类和序列化程序分开以分离关注点。 让课程专注于课程的作用和序列化器的作用（阅读json或其他）

您必须考虑您的类可能是从文件，套接字，json，xml，数据库......来自任意数量的序列化。

这就是为什么在现代编程中我们使用接口。 我们还使用了Factory模式。

Answer 2

一个缺点是有点不一致，这是一个美学问题。

您正在调用CFromString构造函数而不是调用名为C构造函数。 它们之间的关系是任意的，只需通过名称中的C前缀即可。

如果你使它成为一个static成员函数，那么你可以将其称为C::FromString以便它属于该类。

如果在大型项目中的所有地方都这样做，那么某种约定会有所帮助。 比如说，每当我们有一个C类和一个非成员构造函数来制作C -s时，让我们总是把它CCons ，然后总是使用重载来处理不同的类型。 因此，如果我们有一个Widget类，那么我们调用我们的重载族WidgetCons ：

Widget WidgetCons(const std::string &s) { /* make it from string */ }
Widget WidgetCons(int i) { /* make it from int */ }

等等。 如果这在我们的250,000行代码库中是一致的，那么只要有人看到任何FooCons或BarCons ，他们就会确切地知道它是什么。