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 ，他們就會確切地知道它是什么。