提供执行相同操作的不同功能签名是一个好主意吗？

这是一个用三个值构造的C ++类。

class Foo{

    //Constructor
    Foo(std::string, int, char);

private:
    std::string foo;
    char bar;
    int baz;
};

所有参数类型都不同。
我可以重载构造函数，因此顺序无关紧要。

class Foo{

    //Constructors
    Foo(std::string, char, int);
    Foo(std::string, int, char);
    Foo(char, int, std::string);
    Foo(char, std::string, int);
    Foo(int, std::string, char);
    Foo(int, char, std::string);


private:
    std::string foo;
    char bar;
    int baz;
};

但这是个好主意吗？
我开始这样做是因为我知道一个类/函数需要什么东西。
我并不总是记得他们接受了什么命令。

我一直假设编译器会像调用同一个构造函数那样对其进行优化。

//compiler will implement this with the same code? 
//maybe not.. I could call a function to get a parameter, 
//and that function could change the state of the program, before calling
//a function to get another parameter and the compiler would have to
//implement both
Foo foo1("hello",1,'a');
Foo foo2('z',0,"world");

您对重载函数有什么看法，以便顺序无关紧要？

另外，如果我正在编写一些实用程序函数，
提供执行相同操作的不同函数名是否是一个好主意？

例如。

void Do_Foo();
void DoFoo();
void do_foo();
//etc..

我很少看到这两个但相似的约定。
我应该打破还是接受这个习惯？

— 特雷弗·希基（Trevor Hickey）
source

如果在某些情况下每种明确提供的方式明显优于其他任何一种方式，则仅应花费精力提供多种表达方式。这并不意味着人们通常应该花费很多精力来确保只能以一种规范的形式编写某些东西，但是做出允许以某种不是最好的方式指定某些东西的努力是没有意义的。

— 2013年

有点重复我的问题（我现在同意这是一个坏主意）。

— 左右左转

Answers:

我可以重载构造函数，以便[参数的顺序]无关紧要...但这是个好主意吗？

没有。

具有不同的构造函数重载将与您打算的相反。紧随其后的程序员期望不同的重载具有不同的行为，并会问：“ 这些重载中的每一个都表现出什么样的不同行为？

大多数程序员都希望按预定的顺序拥有方法参数，因此诸如IntelliSense之类的工具会在输入参数时告诉他们参数的预期顺序。

具有多个执行相同功能的函数名称是相同的问题。程序员希望这些变体具有不同的行为。请为每种行为提供一个功能或方法，并采用一致的命名模式。

— 罗伯特·哈维
source

很多投票。我将立即停止。谢谢。

— Trevor Hickey

另外，您不能用不同的名称来解释构造函数，以说明您的用途，读者必须从参数中推断出来。以这种方式重载构造函数将使其更难理解。

— Zachary Yates

“具有多个功能名称，它们可以完成相同的工作...”-暂时，看看Ruby的类String Hash Array File。

+1。您正在与开发人员/程序员打交道。Microsoft的“用户就是猴子”的想法在这里不起作用。

— Manoj R

@ZacharyYates可以通过公开静态构造方法来解决缺少“构造函数名称”的问题。这是Java的标准做法，尽管在C ++中不是很多。

— Xion

有时需要支持参数之间的转换。例如：

double operator *(int, double);
double operator *(double, int);

如果操作数取反，我们不希望an int与和相乘double来计算不同的值。我们也不想强迫程序员记住将ints与乘时doubles，double左边的数！

这是一个运算符并不重要，因为同样适用于：

footype plus(const footype &, const bartype &);
footype plus(const bartype &, const footype &);

它实际上取决于功能的种类。尽管大多数程序员可能希望在算术库中支持可交换性，但他们并不一定想要I / O库函数来支持所有可能的参数顺序。

关注可能围绕预期的嵌套，其中涉及函数调用。算术运算符的灵活性使我们可以更改语法树的整体结构以阐明整体表达方式：将相似的术语等归为一组。

— 卡兹
source